[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb335daa-ab6b-4cff-bea2-90160892bc8f@intel.com>
Date: Tue, 3 Feb 2026 14:54:44 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
CC: <alexandre.belloni@...tlin.com>, <linux-i3c@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>, Frank Li
<Frank.li@....com>
Subject: Re: [PATCH 5/7] i3c: mipi-i3c-hci: Allow parent to manage runtime PM
+ Rafael
Rafael, this is not at all urgent, but when you have time
please have a look at this patch set. There is also some
more explanation below. Is it acceptable? Is there a
better way?
On 02/02/2026 18:25, Frank Li wrote:
>
> Does your device Hierarchy look like
>
> PCI device
> |
> -----------------
> HCI1 HCI2
> | |
> I3C M1 I3C M2
Yes and no. There is only 1 real device : the PCI device.
It implements the MIPI I3C HCI standard which allows multiple
I3C bus controllers in one device (in our case 2 controllers).
The PCI driver mipi-i3c-hci-pci creates 2 platform devices,
one for each controller. The platform driver is mipi-i3c-hci:
Driver Device Bus
mipi-i3c-hci-pci 0000:00:11.1 PCI
/ \
mipi-i3c-hci intel-lpss-i3c.0 intel-lpss-i3c.1 Platform
LPSS I3C also supports wake-up from in-band interrupt (IBI) via
PCI PME. The PME only works when the PCI device is in a low power
state (D3hot in our case). Also the PME is effectively shared by
the 2 controllers i.e. an IBI signal (the controller's SDA line
pulled low) for either controller will cause the PME.
That means there are only 2 valid configurations:
1: Both controllers enabled to receive IBIs
PCI device D0
Controller 1 Enabled
Controller 2 Enabled
2: Both controllers disabled to enable PME wakeup
PCI device D3hot
Controller 1 Disabled
Controller 2 Disabled
However, represented as platform devices, the 2 controllers
runtime suspend and resume independently from each other.
Whereas they effectively need to runtime suspend (or resume)
at the same time.
The proposed solution is for the PCI driver mipi-i3c-hci-pci
to take over managing runtime PM for both controllers, calling
into mipi-i3c-hci when it is safe to do so, to save/restore state
and disable/enable the controllers one after the other.
Current situation (I3C next branch):
PCI device Runtime PM enabled, dependent on child devices
PCI subsystem controls PCI device power state
Controller 1 Runtime PM enabled plus auto-suspend
I3C subsystem runtime PM gets/puts the Platform device
Runtime suspend: disable and save state
Runtime resume: restore state and enable
Controller 2 Runtime PM enabled plus auto-suspend
I3C subsystem runtime PM gets/puts the Platform device
Runtime suspend: disable and save state
Runtime resume: restore state and enable
Proposed (this patch set):
PCI device Runtime PM enabled plus auto-suspend
I3C subsystem runtime PM gets/puts the PCI device
For each controller:
Call into mipi-i3c-hci (when it is safe)
Runtime suspend: disable and save state
Runtime resume: restore state and enable
Controller 1 Runtime PM disabled
Controller 2 Runtime PM disabled
>
>
> You want HCI1 and HCI2 suspened only when both HCI1 and HCI2 can enter RM
> time suspend status?
>
> Device Link can link two devices, but not sure if it can handle cyclic
> case, HCI1 and HCI2 depend each other.
>
> Or you create common power domain for HCI1 and HCI2, in power domain to
> handle suspend.
>
> It'd better ask run time pm owner to provide better suggestion.
Ok
Powered by blists - more mailing lists