All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Thierry Reding
	<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: Peter De Schrijver
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Jay Agarwal <jagarwal-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Joseph Lo <josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] ARM: tegra: disable LP2 cpuidle state if PCIe is enabled
Date: Tue, 07 May 2013 08:54:31 -0600	[thread overview]
Message-ID: <518915A7.1020105@wwwdotorg.org> (raw)
In-Reply-To: <20130507130850.GA11202-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>

On 05/07/2013 07:08 AM, Thierry Reding wrote:
> On Tue, May 07, 2013 at 03:48:49PM +0300, Peter De Schrijver
> wrote:
>> On Mon, May 06, 2013 at 10:39:04PM +0200, Stephen Warren wrote:
>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> 
>>> Tegra20 HW appears to have a bug such that PCIe device
>>> interrupts, whether they are legacy IRQs or MSI, are lost when
>>> LP2 is enabled. To work around this, simply disable LP2 if the
>>> PCI driver and DT node are both enabled.
>>> 
>> 
>> Wouldn't it make more sense to disable LP2 when we actually
>> detect a PCIe device?

I did consider that, but rejected the idea for the reasons Thierry
mentioned.

> I'm not sure a patch to do so would be as simple as this one. For
> one, the cpuidle framework will already have been initialized when
> PCIe enumeration completes. So some way of permanently disabling
> one state at runtime would be required and I don't think cpuidle
> provides an API to do so. I know the latter isn't really a good
> reason, but I don't think adding that kind of API just because
> Tegra20 seems to have a bug would be appropriate.

There is a way to do this, since it can be done via sysfs, but I don't
think it's exposed as an API from cpuidle. I agree it seems a little
silly to expose it just to support this HW bug though.

> Furthermore, it is quite likely that the PCIe controller will only
> be enabled in DT for devices that actually have a PCIe device
> hooked up.

But this was my main reasoning.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: tegra: disable LP2 cpuidle state if PCIe is enabled
Date: Tue, 07 May 2013 08:54:31 -0600	[thread overview]
Message-ID: <518915A7.1020105@wwwdotorg.org> (raw)
In-Reply-To: <20130507130850.GA11202@avionic-0098.adnet.avionic-design.de>

On 05/07/2013 07:08 AM, Thierry Reding wrote:
> On Tue, May 07, 2013 at 03:48:49PM +0300, Peter De Schrijver
> wrote:
>> On Mon, May 06, 2013 at 10:39:04PM +0200, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>> 
>>> Tegra20 HW appears to have a bug such that PCIe device
>>> interrupts, whether they are legacy IRQs or MSI, are lost when
>>> LP2 is enabled. To work around this, simply disable LP2 if the
>>> PCI driver and DT node are both enabled.
>>> 
>> 
>> Wouldn't it make more sense to disable LP2 when we actually
>> detect a PCIe device?

I did consider that, but rejected the idea for the reasons Thierry
mentioned.

> I'm not sure a patch to do so would be as simple as this one. For
> one, the cpuidle framework will already have been initialized when
> PCIe enumeration completes. So some way of permanently disabling
> one state at runtime would be required and I don't think cpuidle
> provides an API to do so. I know the latter isn't really a good
> reason, but I don't think adding that kind of API just because
> Tegra20 seems to have a bug would be appropriate.

There is a way to do this, since it can be done via sysfs, but I don't
think it's exposed as an API from cpuidle. I agree it seems a little
silly to expose it just to support this HW bug though.

> Furthermore, it is quite likely that the PCIe controller will only
> be enabled in DT for devices that actually have a PCIe device
> hooked up.

But this was my main reasoning.

  parent reply	other threads:[~2013-05-07 14:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 20:39 [PATCH] ARM: tegra: disable LP2 cpuidle state if PCIe is enabled Stephen Warren
2013-05-06 20:39 ` Stephen Warren
     [not found] ` <1367872744-25002-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-05-06 20:44   ` Thierry Reding
2013-05-06 20:44     ` Thierry Reding
2013-05-07 12:48   ` Peter De Schrijver
2013-05-07 12:48     ` Peter De Schrijver
     [not found]     ` <20130507124849.GM7949-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-05-07 13:08       ` Thierry Reding
2013-05-07 13:08         ` Thierry Reding
     [not found]         ` <20130507130850.GA11202-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2013-05-07 14:54           ` Stephen Warren [this message]
2013-05-07 14:54             ` Stephen Warren
     [not found]             ` <518915A7.1020105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-05-08  9:40               ` Peter De Schrijver
2013-05-08  9:40                 ` Peter De Schrijver
     [not found]                 ` <20130508094004.GL7949-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-05-08 10:56                   ` Thierry Reding
2013-05-08 10:56                     ` Thierry Reding
2013-05-08 18:41                   ` Stephen Warren
2013-05-08 18:41                     ` Stephen Warren
2013-05-08 10:53   ` Daniel Lezcano
2013-05-08 10:53     ` Daniel Lezcano
     [not found]     ` <518A2EB2.70006-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2013-05-08 18:44       ` Stephen Warren
2013-05-08 18:44         ` Stephen Warren

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=518915A7.1020105@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=jagarwal-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=josephl-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org \
    /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.