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

[Yixun Lan]

Hi Icenowy,

On 21:56 Sat 19 Sep     , Icenowy Zheng wrote:
> 在 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.
> 
That's exactly what I said - it's not mature, not saying it's pending
patch for review, but for whole solution that involve Linux driver,
opensbi and underlying fimware (ESOS) - which not upstream-ed..

To make it clear, I'm not going to pursue the RPMI solution, but if
someone insist and willing to spend the effort, please feel free to push

-- 
Yixun Lan (dlan)