Re: [PATCH 2/3] pmdomain: spacemit: Add power domain driver

[Icenowy Zheng]

在 2026-09-19六的 09:59 +0000，Yixun Lan写道：
> Hi Icenowy,
> 
> On 14:57 Sat 19 Sep     , Icenowy Zheng wrote:
> > 在 2026-09-18五的 23:01 +0000，Yixun Lan写道：
> > > Hi Icenowy, 
> > > 
> > > On 17:00 Fri 18 Sep     , Icenowy Zheng wrote:
> > > > 在 2026-09-18五的 02:40 +0000，Yixun Lan写道：
> > > > >   SpacemiT's PMU (Power Management Unit) consist of several
> > > > > power
> > > > > domains
> > > > > which can be managed independently, depending on different
> > > > > application
> > > > > scenario, each domain can be powered on/off for saving power.
> > > > > 
> > > > >   The driver is implemented based on Linux Generic PM Domain
> > > > > framework.
> > > > > From a hardware perspective, either of two distinct power-on
> > > > > sequences
> > > > > are supported, in software mode (SW mode), the driver is
> > > > > responsible
> > > > > for
> > > > > controlling the states of bits such as sleep1, sleep2,
> > > > > isolation
> > > > > and
> > > > > pwr_state, while in hardware mode (HW mode), the PMU hardware
> > > > > will
> > > > > complete
> > > > > the sequence automatically without requiring software
> > > > > intervention.
> > > > 
> > > > I think there also exists solutions for K3 that uses RPMI power
> > > > domains, and let their ESOS firmware to access the hardware.
> > > > 
> > > Yes, I'm aware of that
> > > 
> > > > What's the relationship of this implementation with the ESOS
> > > > implementation? Should the ESOS part be disabled to use this
> > > > implementation?
> > > > 
> > > I should say, it's a mutually exclusive solution, so yes, the
> > > ESOS
> > > part
> > > should be disabled in order to use this version
> > > 
> > > The motivation of this patch is trying to support drm/display
> > > driver's
> > > PM requirement, while avoid going with vendor's complicated RPMI
> > > solution
> > > which isn't mainline ready
> > 
> > Is this a long-term solution, or a temporary one?
> > 
> For upstream, I'd say we probably will stick to this solution for
> long time, won't say it 'forever', see comment below..
> 
> > If it's a temporary conflicting one, I don't think it's worth
> > picking
> > at all.
> > 
> Well, checked current Linux kernel status, there is no RPMI PM
> solution 
> implemented although there is documentation in riscv-rpmi spec[1]

I have seen pending patch for it with multiple revisions [1], the dt
binding is even already ACKed by Conor, so I think it's not a big
problem here.

Thanks,
Icenowy

[1] 20260903092347.620060-1-joshua.yeong@xxxxxxxxxxxxxxxx

> 
> On the other hand, I see no problem to switch to RPMI solution once
> it
> became mature, it's very similar to two solution of clock CLK_CCU vs
> CLK_RPMI.. 
> 
> Link:
> https://github.com/riscv-non-isa/riscv-rpmi/blob/main/src/srvgrp-device-power.adoc
>  [1]