[PATCH v2] platform: generic: spacemit: add K1

[Anup Patel]

On Mon, Sep 22, 2025 at 11:57 AM Troy Mitchell
<troy.mitchell at linux.spacemit.com> wrote:
>
> On Mon, Sep 22, 2025 at 11:49:38AM +0530, Anup Patel wrote:
> > On Mon, Sep 22, 2025 at 11:39 AM Troy Mitchell
> > <troy.mitchell at linux.spacemit.com> wrote:
> > >
> > > On Mon, Sep 22, 2025 at 11:31:35AM +0530, Anup Patel wrote:
> > > > On Mon, Sep 22, 2025 at 11:12 AM Troy Mitchell
> > > > <troy.mitchell at linux.spacemit.com> wrote:
> > > > >
> > > > > On Mon, Sep 22, 2025 at 08:55:25AM +0530, Anup Patel wrote:
> > > > > > On Mon, Sep 22, 2025 at 6:46 AM Troy Mitchell
> > > > > > <troy.mitchell at linux.spacemit.com> wrote:
> > > > > > >
> > > > > > > From: Xianbin Zhu <xianbin.zhu at linux.spacemit.com>
> > > > > > >
> > > > > > > Extend generic platform to support SpacemiT K1.
> > > > > > >
> > > > > > > On K1, the BROM only brings up the primary core and leaves the
> > > > > > > other cores in a disabled state. This prevents Linux from booting
> > > > > > > SMP and only one core is available.
> > > > > > >
> > > > > > > Add code to bring up all 8 cores during OpenSBI initialization so
> > > > > > > that the Linux kernel can detect and use all cores properly.
> > > > > > >
> > > > > > > Co-authored-by: Troy Mitchell <troy.mitchell at linux.spacemit.com>
> > > > > > > Signed-off-by: Troy Mitchell <troy.mitchell at linux.spacemit.com>
> > > > > > > Signed-off-by: Xianbin Zhu <xianbin.zhu at linux.spacemit.com>
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > - remove __sbi_hsm_hart_get_state() in spacemit_cold_boot_allowed()
> > > > > > > - plus PMU_AP_BASE in PMU_AP_CORE(0|4)_(WAKEUP|IDLE)_OFFSET
> > > > > > > - Link to v1: https://lore.kernel.org/r/20250916-smt-k1-8-cores-v1-1-5b76e06d12da@linux.spacemit.com
> > > > > >
> > > > > > It is better to have a separate fdt_hsm_spacemit driver under
> > > > > > lib/utils/hsm directory.
> > > > > We are not going to support this feature.
> > > > > Thanks for your suggestion.
> > > > >
> > > >
> > > > I don't understand.
> > > > This path already registers sbi_hsm_device so all
> > > > I am asking is to create a proper HSM driver under
> > > > lib/utils/hsm directory.
> > > Perhaps I misunderstood something. What I meant is that
> > > we do not plan to support rpmi.
> >
> > The lib/utils/hsm is not only for RPMI HSM driver. Platforms
> > can add their HSM driver under this directory as well.
> >
> > > Also, I noticed other platforms are directly registering via
> > > sbi_hsm_set_device() in their platform code:
> > >
> > > ```
> > > allwinner/sun20i-d1.c:190:      sbi_hsm_set_device(&sun20i_d1_ppu);
> > > andes/ae350.c:101:              sbi_hsm_set_device(&andes_smu);
> > > mips/p8700.c:219:               sbi_hsm_set_device(&mips_hsm);
> > > ```
> >
> > Few of these platforms were added before a dedicated
> > lib/utils/hsm directory was created for HSM drivers.
> >
> > >
> > > Could you please provide me with more information?
> >
> > Gradually, we need to move HSM drivers from platform/generic to
> > lib/utils/hsm as independent HSM drivers
> >
> > I have already suggested this for SiFive TMC0 and SMC0 drivers
> > as well.
> > (Refer "[PATCH v6 00/11] Add SiFive TMC0 and SMC0 driver")
> Thanks for your patience Anup!
> It's clean now. I'll separate this patch.

One more suggestion is that you can simply re-use
"spacemit,k1" as the compatible string for your HSM
driver.

In the future, you can provide HSM support for multiple
spacemit SoCs from the same HSM driver (assuming
they will be similar with incremental changes) and
MMIO base address of registers can be inferred from
compatible string.

Regards,
Anup