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

From: Yixun Lan <dlan@kernel.org>
To: Icenowy Zheng <uwu@icenowy.me>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Ulf Hansson <ulfh@kernel.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
	spacemit@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 2/3] pmdomain: spacemit: Add power domain driver
Date: Sat, 19 Sep 2026 09:59:36 +0000	[thread overview]
Message-ID: <20260919095936-GKA322102@kernel.org> (raw)
In-Reply-To: <33b33b2b79763d410bc2e5b4ef46c305aaf6f7c8.camel@icenowy.me>

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)