[U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI

[Jan Kiszka]

On 2015-02-09 12:26, Mark Rutland wrote:
> [...]
> 
>>>> The solution that was discussed internally would involve having the
>>>> secure monitor (U-Boot's PSCI implementation in this case) program the
>>>> flow controller appropriately, point the CPU reset vectors to a location
>>>> containing a WFI instruction and power up the CPUs. That way they should
>>>> immediately be powergated when they reach the WFI instruction and the
>>>> PSCI implementation would then be able to wake them up without accessing
>>>> the PMC registers once the kernel has booted.
>>>
>>> That sounds far, far better than I had hoped!
>>>
>>> I guess we need to tell the kernel that portions of the PMC are reserved
>>> by FW (in the sense that they must not be modified by the kernel rather
>>> than that FW is going to poke them), to avoid mishaps.
>>
>> I'm not sure we need even that. As I understand it the kernel can still
>> touch all the registers and none of it should influence the CPU power-
>> gating done by the secure monitor.
>>
>> Well, I guess you'd need to make sure that the PMC driver doesn't try to
>> powergate or unpowergate the CPU partitions, but since the cpuidle
>> driver is the only one doing that it should resolve itself if a generic,
>> PSCI-based cpuidle driver takes over instead of a Tegra-specific one.
> 
> This was my concern. It would be good to avoid a case where we
> accidentally rely on some subtle interactiion where both the FW and
> kernel poke some registers in a particular way.
> 
> I guess we can check for the presence of an enable-method, and if there
> is one don't register the Tegra-specific cpuidle driver; in that case we
> expect the FW to own that side of things.
> 
>>>> Adding Peter. Please correct me if I misunderstood what we discussed.
>>>> Can you also provide Ian with pointers to the registers that need to be
>>>> programmed to make this work? I suspect that a lot of it can be gleaned
>>>> from the cpuidle drivers in arch/arm/mach-tegra in the upstream Linux
>>>> kernel.
>>>>
>>>> Also adding Paul for visibility.
>>>>
>>>>> One thing to bear in mind is that PSCI is only one user of the SMC
>>>>> space. Per SMC calling convention, portions of the SMC ID space are
>>>>> there to be used for other (vendor-specific) purposes.
>>>>>
>>>>> So rather than extending PSCI, a parallel API could be implemented for
>>>>> power control of other devices, and the backend could arbitrate the two
>>>>> without the non-secure OS requiring implementation-specific mutual
>>>>> exclusion.
>>>>>
>>>>> I think this has been brought up internally previously; I'll go and poke
>>>>> around in the area to see if we managed to figure out anything useful.
>>>>>
>>>>>> Unfortunately this doesn't change on 64-bit Tegra at all.
>>>>>
>>>>> I suspected as much. :/
>>>>>
>>>>> How does this bode for the tegra132 dts [1] on LAKML at the moment? Is
>>>>> it just the "nvidia,tegra132-pmc" device that needs to be poked by both
>>>>> FW and kernel, or are other devices involved?
>>>>
>>>> As I understand it, only the flow controller is involved with CPU power
>>>> management once the above steps have been performed by the secure
>>>> monitor. And I don't think anyone in the kernel would need access to the
>>>> flow controller at that point either, so I think that problem resolved
>>>> itself nicely.
>>>>
>>>> Also note that the above should work as far back as Tegra30.
>>>
>>> It would be amazing if we could gain PSCI for all the platforms that
>>> covers!
>>
>> It should be relatively easy to support at least Tegra114 with much the
>> same code as Tegra124, and some slight changes on Tegra30. But yeah, it
>> would be great to see this work.
> 
> Nice!
> 
> I should look into getting hold of a relevant platform; I only have a
> (T20) AC100, and I guess that's a bit different at the system-level.

To avoid duplicate work: I started to implement the suggested algorithm
on the TK1. Just like Ian, I don't have access to any other platform
(nor docs at hand), so I will stick with Tegra124 support for the first
step. I suppose we can easily extend this later on.

Flow controller setup and the PSCI service CPU_ON already works. I'll
post patches once CPU_OFF is working as well.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150214/03ec12f2/attachment.sig>