[PATCH 0/3] platform: generic: spacemit: k3: follow-up fixes

[Bo Gan]

Hi Troy,

I missed this one earlier. So basically I need the latest upstream kernel
to be able to test this patchset, because all the rpmi backed devices in
vendor kernel device-tree just won't work. Perhaps this should be called
out in the cover letter, so I don't have to waste time debugging vendor
stuff. IMO, leaving the rpmi stuff out is the right approach for initial
work. I feel that path needs to be properly reviewed and make sure it
fully conforms to the standard.

Bo

On 8/31/26 22:48, Troy Mitchell wrote:
> On Mon, Aug 31, 2026 at 10:07 PM +0200, Valentin Haudiquet wrote:
>> I believe one of the issues is that the v3 HSM wakes A100 core 8 only
>> when Linux onlines CPU 8. The vendor kernel onlines all 16 CPUs
>> so ESOS starts and RPMI works. Mainline uses only the X100 complex
>> (harts 0-7), so CPU 8 is never onlined, core 8 is never woken,
>> ESOS never runs, and RPMI mailbox transactions time out.
>> Patch 3/3 wakes core 8 in OpenSBI pre_init so ESOS is available
>> regardless of which CPUs Linux uses.
>>
>> [...]
>>
>> I have adapted those patches from the Spacemit OpenSBI 1.6 vendor tree
>> logic, through a lot of trial and error. I'm not sure I deeply understand
>> the hardware-specific details at play, so any comments would be appreciated.
>>
>> Feel free to take this in as part of the patchseries and modify it if needed,
>> or send review comments and I can also improve them.
> 
> The original scope of this series is the K3 platform initialization and
> HSM support needed to bring up the X100 and A100 harts. It is not
> intended to reproduce the vendor SDK firmware ABI in the initial series.
> 
> In the mainline K3 DT, regulators are managed directly by Linux through
> the P1 PMIC driver. It contains no K3 RPMI regulator or power-domain
> interface, so this boot path does not depend on ESOS.
> 
> Your changes appear to additionally target compatibility with the vendor
> SDK stack. That may be useful, but it is outside the scope of this initial
> series. Support for the vendor SDK stack can be considered separately in
> the future if needed.
> 
>                                              - Troy