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

[Icenowy Zheng]

在 2026-09-19六的 23:13 +0000，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..

Except for the MPXY part (which seems to be already mainlined), OpenSBI
is only a RPMI consumer.

ESOS is vendor-specific thing and its version from the vendor already
contains the RPMI implementation.

The Linux driver also appears earlier and received more review than
this driver.

For not reinventing the wheel, it would be better to work on the RPMI
PM driver.

Thanks,
Icenowy

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