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

[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]

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]
-- 
Yixun Lan (dlan)