[U-Boot] [PATCH v5 00/14] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

[Thierry Reding]

On Fri, Apr 10, 2015 at 12:19:39PM +0200, Jan Kiszka wrote:
> On 2015-04-10 11:54, Thierry Reding wrote:
> > On Fri, Apr 10, 2015 at 09:07:13AM +0200, Jan Kiszka wrote:
> >> On 2015-04-10 08:59, Thierry Reding wrote:
> >>> On Wed, Apr 08, 2015 at 10:37:40AM +0200, Jan Kiszka wrote:
> >>>> On 2015-03-19 16:02, Thierry Reding wrote:
> >>>>> On Mon, Mar 09, 2015 at 08:00:10AM +0100, Jan Kiszka wrote:
> >>>>>> Changes in v4:
> >>>>>>  - rebased over master
> >>>>>>  - implemented psci_get_cpu_id as weak function
> >>>>>>  - implemented psci_disable/enable_smp as weak functions
> >>>>>>  - adjusted register interface of psci_get_cpu_stack_top
> >>>>>>
> >>>>>> This version (+ the non-cached memory init fix) can also be found at
> >>>>>> https://github.com/siemens/u-boot/tree/jetson-tk1-v5.
> >>>>>>
> >>>>>> Jan
> >>>>>>
> >>>>>> CC: Ian Campbell <ijc at hellion.org.uk>
> >>>>>> CC: Marc Zyngier <marc.zyngier at arm.com>
> >>>>>>
> >>>>>> Ian Campbell (3):
> >>>>>>   tegra124: Add more registers to struct mc_ctlr
> >>>>>>   jetson-tk1: Add PSCI configuration options and reserve secure code
> >>>>>>   tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0
> >>>>>>
> >>>>>> Jan Kiszka (11):
> >>>>>>   sun7i: Remove duplicate call to psci_arch_init
> >>>>>>   ARM: Factor out common psci_get_cpu_id
> >>>>>>   ARM: Factor out reusable psci_cpu_off_common
> >>>>>>   ARM: Factor out reusable psci_cpu_entry
> >>>>>>   ARM: Factor out reusable psci_get_cpu_stack_top
> >>>>>>   ARM: Put target PC for PSCI CPU_ON on per-CPU stack
> >>>>>>   virt-dt: Allow reservation of secure region when in a RAM carveout
> >>>>>>   tegra: Make tegra_powergate_power_on public
> >>>>>>   tegra: Add ap_pm_init hook
> >>>>>>   tegra124: Add PSCI support for Tegra124
> >>>>>>   tegra: Set CNTFRQ for secondary CPUs
> >>>>>>
> >>>>>>  arch/arm/cpu/armv7/psci.S                   | 121 ++++++++++++++++++++++++++++
> >>>>>>  arch/arm/cpu/armv7/sunxi/psci.S             | 112 ++++---------------------
> >>>>>>  arch/arm/cpu/armv7/virt-dt.c                |  29 +++++++
> >>>>>>  arch/arm/cpu/armv7/virt-v7.c                |   5 ++
> >>>>>>  arch/arm/include/asm/arch-tegra/ap.h        |   5 ++
> >>>>>>  arch/arm/include/asm/arch-tegra/powergate.h |   1 +
> >>>>>>  arch/arm/include/asm/arch-tegra124/flow.h   |   6 ++
> >>>>>>  arch/arm/include/asm/arch-tegra124/mc.h     |  35 +++++++-
> >>>>>>  arch/arm/include/asm/armv7.h                |   1 +
> >>>>>>  arch/arm/include/asm/system.h               |   1 +
> >>>>>>  arch/arm/lib/bootm-fdt.c                    |   5 ++
> >>>>>>  arch/arm/mach-tegra/Makefile                |   4 +
> >>>>>>  arch/arm/mach-tegra/ap.c                    |  15 ++++
> >>>>>>  arch/arm/mach-tegra/powergate.c             |   2 +-
> >>>>>>  arch/arm/mach-tegra/psci.S                  | 114 ++++++++++++++++++++++++++
> >>>>>>  arch/arm/mach-tegra/tegra124/Kconfig        |   2 +
> >>>>>>  arch/arm/mach-tegra/tegra124/Makefile       |   4 +
> >>>>>>  arch/arm/mach-tegra/tegra124/ap.c           |  55 +++++++++++++
> >>>>>>  board/nvidia/common/board.c                 |   4 +
> >>>>>>  include/configs/jetson-tk1.h                |   5 ++
> >>>>>>  20 files changed, 428 insertions(+), 98 deletions(-)
> >>>>>>  create mode 100644 arch/arm/mach-tegra/psci.S
> >>>>>>  create mode 100644 arch/arm/mach-tegra/tegra124/ap.c
> >>>>>
> >>>>> For the series:
> >>>>>
> >>>>> Reviewed-by: Thierry Reding <treding at nvidia.com>
> >>>>> Tested-by: Thierry Reding <treding at nvidia.com>
> >>>>
> >>>> Thanks for all feedback - what's next? Anything missing? Should I rebase
> >>>> (didn't check yet if that is necessary) and resend?
> >>>
> >>> One of the things that I'm unsure about is that we need a couple of
> >>> patches in the kernel to keep systems working with these U-Boot patches
> >>> applied. The cpuidle driver needs to be disabled if PSCI is enabled (I
> >>> have a patch to do that). And there are a couple of other things that
> >>> U-Boot needs to do before switching to non-secure mode (enabling the
> >>> SMMU because that can't be done in non-secure mode).
> >>>
> >>> So unconditionally enabling this is going to cause breakage in current
> >>> kernels. Perhaps a solution would be to get all the code in place but
> >>> not update the configuration just yet.
> >>
> >> Isn't there ARMV7_VIRT, "Enable support for hardware virtualization", to
> >> control this already?
> > 
> > Well yeah, but I think that currently gets enabled by default.
> 
> No problem, will flip the default. I'll also finally give your SMMU
> patch a try, provided I find a proper test case Linux-wise.

Display uses the SMMU when present, so if you manage to get some content
out of HDMI it should work.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150410/36d50281/attachment.sig>