All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ajaykumar Hotchandani <ajaykumar.hotchandani@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Set device power state to PCI_D0 for device without native PM support
Date: Tue, 18 Oct 2011 19:22:21 +0530	[thread overview]
Message-ID: <4E9D8495.4010105@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110131525320.3519@kaball-desktop>



On 10/13/2011 08:00 PM, Stefano Stabellini wrote:
> On Mon, 10 Oct 2011, Ajaykumar Hotchandani wrote:
>> On 10/06/2011 09:47 PM, Stefano Stabellini wrote:
>>> On Thu, 6 Oct 2011, Yinghai Lu wrote:
>>>> On Thu, Oct 6, 2011 at 3:39 AM, Stefano Stabellini
>>>> <stefano.stabellini@eu.citrix.com>   wrote:
>>>>> I had the same issue and sent a patch a while ago to fix it, adding
>>>>>
>>>>> current_state = PCI_D0 in acpiphp_glue.c:register_slot
>>>>>
>>>>> it is strange that this does not work for you:
>>>>>
>>>>> http://marc.info/?l=linux-kernel&m=129891002722845&w=2
>>>> So guest os has to load acpiphp instead of pciehp?
>>> maybe pciehp needs to make sure that current_state = D0 in
>>> pciehp_enable_slot, like acpiphp does
>> Here, acpi hotplugging is involved.
>> With your change in register_slot(), device will have proper power state when module is being loaded for the first time after booting.
>> However, while unload of pci module; following is in pci_device_remove():
>>           if (pci_dev->current_state == PCI_D0)
>>                   pci_dev->current_state = PCI_UNKNOWN;
>>
>> So, device power state state will remain PCI_UNKNOWN while module is loaded again. Subsequently, MSI write will do nothing.
> Does this mean that this bug would actually trigger even with devices that
> do support _EJ0 and power management?
Nope. I don't have system to verify. But, for the scenario you mentioned 
(device is hot pluggable, acpi bus power manageable and device with 
pm_cap supported; if I understand it correctly), following is what I 
think should happen:
- Inside pci_platform_power_transition(), 
platform_pci_power_manageable() will be successful. However, 
platform_pci_set_power_state() will fail (as device supports EJ0) and 
subsequently pci_update_current_state() will not get called.
- So, current power state of device will not be read and power state of 
device will remain PCI_UNKNOWN.
- Now, pci_raw_set_power_state() will get called. Here, as current power 
state is PCI_UNKNOWN, pci_write_config_word() will be called with pmcsr 
value as 0. As, last two bits of pmcsr is 0, written power state of 
device will be PCI_D0 now. And subsequently, dev->current_state will be 
assigned as PCI_D0 (by using pci_read_config_word() ).
> Because acpi_pci_set_power_state won't set current_state to PCI_D0
> because the "hotplug driver will take care of _PSx" (see
> 10b3dcae0f275e2546e55303d64ddbb58cec7599) but the hotplug driver is not
> actually invoked when loading again a driver module of an existing pci
> device (the example you mention above)?
Can you please elaborate more on this?
acpi_bus_set_power() will update state of acpi_dev (ACPI_STATE_XX) and 
not pci_dev (PCI_XX).
And here, issue lies with current_state of pci_dev.

Thanks,
Ajay


  reply	other threads:[~2011-10-18 13:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 11:34 [PATCH] PCI: Set device power state to PCI_D0 for device without native PM support Ajaykumar Hotchandani
2011-10-05 19:41 ` Rafael J. Wysocki
2011-10-06 16:10   ` Yinghai Lu
2011-10-06 17:20     ` Rafael J. Wysocki
2011-10-06 10:39 ` Stefano Stabellini
2011-10-06 16:05   ` Yinghai Lu
2011-10-06 16:17     ` Stefano Stabellini
2011-10-10 12:02       ` Ajaykumar Hotchandani
2011-10-13 14:30         ` Stefano Stabellini
2011-10-18 13:52           ` Ajaykumar Hotchandani [this message]
2011-10-27 13:14             ` Stefano Stabellini
2011-10-27 14:34               ` Ajaykumar Hotchandani
2011-10-27 15:01                 ` Stefano Stabellini
2011-10-28 12:06                   ` Ajaykumar Hotchandani
     [not found] <4EE5BAF8.4000303@oracle.com>
2011-12-13 18:53 ` Jesse Barnes

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=4E9D8495.4010105@oracle.com \
    --to=ajaykumar.hotchandani@oracle.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=yhlu.kernel@gmail.com \
    /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.