All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 18 Sep 2026 23:01:07 +0000	[thread overview]
Message-ID: <20260918230107-GKC297024@kernel.org> (raw)
In-Reply-To: <a4359efeee2220903a05a2383a651ec8ec7284b7.camel@icenowy.me>

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

-- 
Yixun Lan (dlan)

WARNING: multiple messages have this Message-ID (diff)
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: Fri, 18 Sep 2026 23:01:07 +0000	[thread overview]
Message-ID: <20260918230107-GKC297024@kernel.org> (raw)
In-Reply-To: <a4359efeee2220903a05a2383a651ec8ec7284b7.camel@icenowy.me>

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

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-09-18 23:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18  2:40 [PATCH 0/3] PM: spacemit: Add power domain support Yixun Lan
2026-09-18  2:40 ` Yixun Lan
2026-09-18  2:40 ` [PATCH 1/3] dt-bindings: power: spacemit: Add power domain controller Yixun Lan
2026-09-18  2:40   ` Yixun Lan
2026-09-18  2:43   ` sashiko-bot
2026-09-28 18:30   ` Rob Herring
2026-09-28 18:30     ` Rob Herring
2026-10-08  2:42     ` Yixun Lan
2026-10-08  2:42       ` Yixun Lan
2026-09-18  2:40 ` [PATCH 2/3] pmdomain: spacemit: Add power domain driver Yixun Lan
2026-09-18  2:40   ` Yixun Lan
2026-09-18  2:52   ` sashiko-bot
2026-09-18  9:00   ` Icenowy Zheng
2026-09-18  9:00     ` Icenowy Zheng
2026-09-18 23:01     ` Yixun Lan [this message]
2026-09-18 23:01       ` Yixun Lan
2026-09-19  6:57       ` Icenowy Zheng
2026-09-19  6:57         ` Icenowy Zheng
2026-09-19  9:59         ` Yixun Lan
2026-09-19  9:59           ` Yixun Lan
2026-09-19 13:56           ` Icenowy Zheng
2026-09-19 13:56             ` Icenowy Zheng
2026-09-19 23:13             ` Yixun Lan
2026-09-19 23:13               ` Yixun Lan
2026-09-20  5:17               ` Icenowy Zheng
2026-09-20  5:17                 ` Icenowy Zheng
2026-09-20  8:00             ` Troy Mitchell
2026-09-20  8:00               ` Troy Mitchell
2026-09-20 12:56   ` Icenowy Zheng
2026-09-20 12:56     ` Icenowy Zheng
2026-09-21  3:35     ` Yixun Lan
2026-09-21  3:35       ` Yixun Lan
2026-09-21  3:39       ` Icenowy Zheng
2026-09-21  3:39         ` Icenowy Zheng
2026-09-21 12:43         ` Yixun Lan
2026-09-21 12:43           ` Yixun Lan
2026-09-21  3:41       ` Icenowy Zheng
2026-09-21  3:41         ` Icenowy Zheng
2026-09-21 12:44         ` Yixun Lan
2026-09-21 12:44           ` Yixun Lan
2026-10-02 18:54   ` Iker Pedrosa
2026-10-02 18:54     ` Iker Pedrosa
2026-10-04 13:47     ` Yixun Lan
2026-10-04 13:47       ` Yixun Lan
2026-09-18  2:40 ` [PATCH 3/3] dts: riscv: spacemit: Add power domain nodes Yixun Lan
2026-09-18  2:40   ` Yixun Lan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260918230107-GKC297024@kernel.org \
    --to=dlan@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=robh@kernel.org \
    --cc=spacemit@lists.linux.dev \
    --cc=ulfh@kernel.org \
    --cc=uwu@icenowy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.