* Re: how to trigger pcieport runtime suspend?
2014-03-24 17:19 ` Alan Stern
@ 2014-03-25 18:39 ` Rafael J. Wysocki
2014-03-25 19:18 ` Andreas Noever
1 sibling, 0 replies; 4+ messages in thread
From: Rafael J. Wysocki @ 2014-03-25 18:39 UTC (permalink / raw)
To: Alan Stern
Cc: Bjorn Helgaas, Andreas Noever, linux-pci@vger.kernel.org,
Linux PM list, Pavel Machek
On Monday, March 24, 2014 01:19:43 PM Alan Stern wrote:
> On Mon, 24 Mar 2014, Bjorn Helgaas wrote:
>
> > [+cc Rafael, Pavel, linux-pm]
> >
> > On Sun, Mar 23, 2014 at 12:16 PM, Andreas Noever
> > <andreas.noever@gmail.com> wrote:
> > > The pcieport driver defines runtime_suspend and runtime_resume methods
> > > (pcie_port_runtime_suspend/resume in portdrv_pci.c). I am trying to
> > > trigger that code. But I cannot get power/runtime_usage to drop to
> > > zero.
> > >
> > > Initially power/runtime_usage is set to 2. The 2 comes (imho) from:
> > > pci_pm_init -> pm_runtime_forbid
> > > local_pci_probe -> pm_runtime_get_sync
> > >
> > > The pm_runtime_forbid can be undone with echo auto > power/control,
> > > but the second one seems to never go away. local_pci_probe spots the
> > > following comment:
> > > "If the driver supports runtime PM, it should call
> > > pm_runtime_put_noidle() in its probe routine and
> > > pm_runtime_get_noresume() in its remove routine." I cannot find any
> > > such calls in the pcieport driver (or in the port service drivers).
> > >
> > > What am I missing?
>
> You're not missing anything, but apparently the people who added
> runtime PM support to the pcieport driver missed the comment you
> quoted.
In fact, they were removed, because it turned out that some systems broke
when we enabled runtime PM for PCIe ports. In other words, this feature
is incomplete now.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: how to trigger pcieport runtime suspend?
2014-03-24 17:19 ` Alan Stern
2014-03-25 18:39 ` Rafael J. Wysocki
@ 2014-03-25 19:18 ` Andreas Noever
1 sibling, 0 replies; 4+ messages in thread
From: Andreas Noever @ 2014-03-25 19:18 UTC (permalink / raw)
To: Alan Stern
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Rafael J. Wysocki,
Linux PM list, Pavel Machek
On Mon, Mar 24, 2014 at 6:19 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, 24 Mar 2014, Bjorn Helgaas wrote:
>
>> [+cc Rafael, Pavel, linux-pm]
>>
>> On Sun, Mar 23, 2014 at 12:16 PM, Andreas Noever
>> <andreas.noever@gmail.com> wrote:
>> > The pcieport driver defines runtime_suspend and runtime_resume methods
>> > (pcie_port_runtime_suspend/resume in portdrv_pci.c). I am trying to
>> > trigger that code. But I cannot get power/runtime_usage to drop to
>> > zero.
>> >
>> > Initially power/runtime_usage is set to 2. The 2 comes (imho) from:
>> > pci_pm_init -> pm_runtime_forbid
>> > local_pci_probe -> pm_runtime_get_sync
>> >
>> > The pm_runtime_forbid can be undone with echo auto > power/control,
>> > but the second one seems to never go away. local_pci_probe spots the
>> > following comment:
>> > "If the driver supports runtime PM, it should call
>> > pm_runtime_put_noidle() in its probe routine and
>> > pm_runtime_get_noresume() in its remove routine." I cannot find any
>> > such calls in the pcieport driver (or in the port service drivers).
>> >
>> > What am I missing?
>
> You're not missing anything, but apparently the people who added
> runtime PM support to the pcieport driver missed the comment you
> quoted.
>
> If you add those calls to the driver, does it do what you want?
If I add that call and remove the pme_poll check in
pcie_port_runtime_idle (pme_poll seems to be set for all devices) then
it seems to work. The bridge goes to D3 if no device is present or if
all devices below it are in D3. It even reacts to hotplug events while
in D3. I'm not sure that everything *really* works as I cannot see any
code that would call resume/suspend on the individual port service
drivers (as compared to the system suspend path). It probably just
works by accident.
Anyhow, the reason I was trying to do this is, is that I observed
different behavior from a device in runtime D3 as compared to system
suspend. I thought it might have something to do with the power status
of the parent bridge, but that turned out to be not the case... back
to square one.
Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread