On Tue, 31 Jul 2012, Huang Ying wrote:
> > What happens when you run lspci and the device is in D3cold? Then even
> > if the parent bridge is active, lspci will still fail.
> >
> > It seems that in this case you need to resume the device itself, not
> > just its parent.
>
> How about the foll
On Mon, 2012-07-30 at 10:19 -0400, Alan Stern wrote:
> On Mon, 30 Jul 2012, Huang Ying wrote:
>
> > > Yup, that worked in the quick test I just did.
> > >
> > > lspci reading the device config will still not wake the bridge, but I
> > > assume that is intentional? But loading the device driver
On Mon, 2012-07-30 at 10:19 -0400, Alan Stern wrote:
> On Mon, 30 Jul 2012, Huang Ying wrote:
>
> > > Yup, that worked in the quick test I just did.
> > >
> > > lspci reading the device config will still not wake the bridge, but I
> > > assume that is intentional? But loading the device driver
On Mon, 2012-07-30 at 18:57 +0200, Bjørn Mork wrote:
> huang ying writes:
>
> > On Mon, Jul 30, 2012 at 4:08 PM, Bjørn Mork wrote:
> >> Huang Ying writes:
> >>
> >>> Do you have time to test the following patch to fix the lspci issue?
> >>>
> >>> Subject: [BUGFIX] PCI/PM: Keep parent bridge act
huang ying writes:
> On Mon, Jul 30, 2012 at 4:08 PM, Bjørn Mork wrote:
>> Huang Ying writes:
>>
>>> Do you have time to test the following patch to fix the lspci issue?
>>>
>>> Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config
>>> reg
>>
>>
>> Sure. But keep this goi
On Mon, 30 Jul 2012, Huang Ying wrote:
> > Yup, that worked in the quick test I just did.
> >
> > lspci reading the device config will still not wake the bridge, but I
> > assume that is intentional? But loading the device driver now wakes
> > both the bridge and the device, so that works.
>
>
On Mon, Jul 30, 2012 at 4:08 PM, Bjørn Mork wrote:
> Huang Ying writes:
>
>> Do you have time to test the following patch to fix the lspci issue?
>>
>> Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config
>> reg
>
>
> Sure. But keep this going and I will file a request for
Huang Ying writes:
> Do you have time to test the following patch to fix the lspci issue?
>
> Subject: [BUGFIX] PCI/PM: Keep parent bridge active when read/write config reg
Sure. But keep this going and I will file a request for modular build
of the PCI subsystem :-)
The patch works fine for
On Fri, 2012-07-27 at 11:11 +0200, Bjørn Mork wrote:
> Huang Ying writes:
>
> > Do you have time to try the following patch?
> >
> > Best Regards,
> > Huang Ying
> >
> > ---
> > drivers/pci/pci-driver.c |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > --- a/drivers/pci/pci-driver.c
> >
On Mon, 30 Jul 2012, Jassi Brar wrote:
> On Sun, Jul 29, 2012 at 8:25 PM, Alan Stern wrote:
> >
> > For me there's also an issue of style: If you do a synchronous get then it
> > looks odd not to do a synchronous put. My feeling has always been that
> > the async routines are for use in non-proc
On Sun, Jul 29, 2012 at 8:25 PM, Alan Stern wrote:
>
> For me there's also an issue of style: If you do a synchronous get then it
> looks odd not to do a synchronous put. My feeling has always been that
> the async routines are for use in non-process contexts, where the sync
> routines can't be u
On Sunday, July 29, 2012, Alan Stern wrote:
> On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
>
> > The difference is, if you use _put_sync(), you need to wait the extra 10 ms
> > for local_pci_probe() to return (if the parent is actually suspended),
> > although you might not need to wait for it if
On Sun, 29 Jul 2012, Rafael J. Wysocki wrote:
> The difference is, if you use _put_sync(), you need to wait the extra 10 ms
> for local_pci_probe() to return (if the parent is actually suspended),
> although you might not need to wait for it if you used _put(), right?
Yes, that's the difference.
On Saturday, July 28, 2012, Alan Stern wrote:
> On Sat, 28 Jul 2012, Rafael J. Wysocki wrote:
>
> > On Saturday, July 28, 2012, Alan Stern wrote:
> > > On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
> > >
> > > > > > > > + if (parent)
> > > > > > > > + pm_runtime_put(parent);
>
On Sat, 28 Jul 2012, Rafael J. Wysocki wrote:
> On Saturday, July 28, 2012, Alan Stern wrote:
> > On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
> >
> > > > > > > + if (parent)
> > > > > > > + pm_runtime_put(parent);
> > > > > >
> > > > > > You should use pm_runtime_put_sync(), not pm_run
On Saturday, July 28, 2012, Alan Stern wrote:
> On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
>
> > > > > > + if (parent)
> > > > > > + pm_runtime_put(parent);
> > > > >
> > > > > You should use pm_runtime_put_sync(), not pm_runtime_put().
> > > >
> > > > Hmm, why exactly?
> > >
> >
On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
> > > > > + if (parent)
> > > > > + pm_runtime_put(parent);
> > > >
> > > > You should use pm_runtime_put_sync(), not pm_runtime_put().
> > >
> > > Hmm, why exactly?
> >
> > Because it's more efficient to do something directly than t
On Friday, July 27, 2012, Alan Stern wrote:
> On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
>
> > On Friday, July 27, 2012, Alan Stern wrote:
> > > On Fri, 27 Jul 2012, Huang Ying wrote:
> > >
> > > > --- a/drivers/pci/pci-driver.c
> > > > +++ b/drivers/pci/pci-driver.c
> > > > @@ -280,8 +280,12
On Fri, 27 Jul 2012, Rafael J. Wysocki wrote:
> On Friday, July 27, 2012, Alan Stern wrote:
> > On Fri, 27 Jul 2012, Huang Ying wrote:
> >
> > > --- a/drivers/pci/pci-driver.c
> > > +++ b/drivers/pci/pci-driver.c
> > > @@ -280,8 +280,12 @@ static long local_pci_probe(void *_ddi)
> > > {
> > >
On Friday, July 27, 2012, Alan Stern wrote:
> On Fri, 27 Jul 2012, Huang Ying wrote:
>
> > --- a/drivers/pci/pci-driver.c
> > +++ b/drivers/pci/pci-driver.c
> > @@ -280,8 +280,12 @@ static long local_pci_probe(void *_ddi)
> > {
> > struct drv_dev_and_id *ddi = _ddi;
> > struct device *dev
On Fri, 27 Jul 2012, Huang Ying wrote:
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -280,8 +280,12 @@ static long local_pci_probe(void *_ddi)
> {
> struct drv_dev_and_id *ddi = _ddi;
> struct device *dev = &ddi->dev->dev;
> + struct device *parent = dev->
Huang Ying writes:
> Do you have time to try the following patch?
>
> Best Regards,
> Huang Ying
>
> ---
> drivers/pci/pci-driver.c |6 ++
> 1 file changed, 6 insertions(+)
>
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -280,8 +280,12 @@ static long local_pci_pr
On Thu, 2012-07-26 at 12:35 +0200, Bjørn Mork wrote:
> Huang Ying writes:
>
> > Do you have time to try the below patch?
>
> Sure. Looks OK wrt the USB problems, but may cause problems with the
> PCIe WiFi card. Unless those are related to other changes in -next.
>
> Anyway, for I applied you
Alan Stern writes:
>> USB hotplugging seems to work fine with this.
>
> Don't be too sure. Have you tested to see if it still works after
> doing "rmmod ehci-hcd"?
>
> So far you have tested the EHCI controllers, but have you tested the
> UHCI controllers? Unloading ehci-hcd will force them t
On Thu, 26 Jul 2012, Bjørn Mork wrote:
> Huang Ying writes:
>
> > Do you have time to try the below patch?
>
> Sure. Looks OK wrt the USB problems, but may cause problems with the
> PCIe WiFi card. Unless those are related to other changes in -next.
>
> Anyway, for I applied your patch on to
Bjørn Mork writes:
> Capabilities: [c8] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>
> Capabilities: [a0] Power Management versi
Bjørn Mork writes:
>
> Jul 26 12:20:43 nemi kernel: [ 493.812266] iwlwifi :03:00.0: Refused to
> change power state, currently in D3
> Jul 26 12:20:43 nemi kernel: [ 493.812331] iwlwifi :03:00.0:
> pci_resource_len = 0x2000
> Jul 26 12:20:43 nemi kernel: [ 493.812335] iwlwifi 000
Huang Ying writes:
> Do you have time to try the below patch?
Sure. Looks OK wrt the USB problems, but may cause problems with the
PCIe WiFi card. Unless those are related to other changes in -next.
Anyway, for I applied your patch on top of next-20120724 for
consistency (still without Rafael
On Wed, 2012-07-25 at 15:58 +0200, Bjørn Mork wrote:
> huang ying writes:
>
> > Hi, Bjorn,
> >
> > Thank you very much for your detailed information.
> >
> > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
> >> Huang Ying writes:
> >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
> >
On Thu, 2012-07-26 at 00:36 +0200, Bjørn Mork wrote:
> "Rafael J. Wysocki" writes:
>
> > This is not really necessary. The problem is the change of behavior I was
> > worried about some time ago.
> >
> > Namely, the device in question apparently doesn't support ACPI D3_hot,
> > so acpi_pm_device
Hi, Rafael,
On Wed, 2012-07-25 at 22:02 +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 25, 2012, Bjørn Mork wrote:
> > huang ying writes:
> >
> > > Hi, Bjorn,
> > >
> > > Thank you very much for your detailed information.
> > >
> > > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
> >
"Rafael J. Wysocki" writes:
> This is not really necessary. The problem is the change of behavior I was
> worried about some time ago.
>
> Namely, the device in question apparently doesn't support ACPI D3_hot,
> so acpi_pm_device_sleep_state() returns D2 as the target state, where it
> would ret
On Wednesday, July 25, 2012, Bjørn Mork wrote:
> huang ying writes:
>
> > Hi, Bjorn,
> >
> > Thank you very much for your detailed information.
> >
> > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
> >> Huang Ying writes:
> >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
> En
On Wednesday, July 25, 2012, Bjørn Mork wrote:
> huang ying writes:
>
> > Hi, Bjorn,
> >
> > Thank you very much for your detailed information.
> >
> > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
> >> Huang Ying writes:
> >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
> En
huang ying writes:
> Hi, Bjorn,
>
> Thank you very much for your detailed information.
>
> On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
>> Huang Ying writes:
>>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
Enabling autosuspend for USB causes hotplug failure in the current
>>
Hi, Bjorn,
Thank you very much for your detailed information.
On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote:
> Huang Ying writes:
>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
>>> Enabling autosuspend for USB causes hotplug failure in the current
>>> linux-next. Newly plugged devi
Hi, Bjorn,
On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
> Enabling autosuspend for USB causes hotplug failure in the current
> linux-next. Newly plugged devices are not detected at all until the
> port/controller is manually powered on by writing "on" to power/control.
> Testing is pretty
Enabling autosuspend for USB causes hotplug failure in the current
linux-next. Newly plugged devices are not detected at all until the
port/controller is manually powered on by writing "on" to power/control.
Testing is pretty simple:
1) for f in /sys/bus/usb/devices/*/power/control; do echo auto
38 matches
Mail list logo
