[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73f7fc6b-d3cc-46d0-a07b-45c2a4190434@intel.com>
Date: Tue, 3 Feb 2026 17:22:38 +0100
From: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>
To: Frank Li <Frank.li@....com>, Adrian Hunter <adrian.hunter@...el.com>
CC: <alexandre.belloni@...tlin.com>, <linux-i3c@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 5/7] i3c: mipi-i3c-hci: Allow parent to manage runtime PM
On 2/3/2026 4:59 PM, Frank Li wrote:
> On Tue, Feb 03, 2026 at 02:54:44PM +0200, Adrian Hunter wrote:
>> + 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
> Controller 1/2 is child device of PCI device.
>
> So first patch "i3c: master: Allow controller drivers to select runtime PM device"
> is not necessary.
>
> You can enable controller 1 and 2 Runtime PM with dummy operation.
>
> When controller 1 run time suspend, parent PCI device will reduce ref counter
> when controller 2 run time suspend, parent PCI device will reduce ref counter
>
> Only runtime pm reference counter of PCI device is 0, PCI device's run time
> suspend will be called, you can do actual disable and save work.
This sounds to me like it should work.
Powered by blists - more mailing lists