netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: "Bedia\, Vaibhav" <vaibhav.bedia@ti.com>,
	"Mark A. Greer" <mgreer@animalcreek.com>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-omap\@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel\@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks
Date: Thu, 03 May 2012 14:32:16 -0700	[thread overview]
Message-ID: <87ehr1gdcv.fsf@ti.com> (raw)
In-Reply-To: <1336076542.2998.23.camel@bwh-desktop.uk.solarflarecom.com> (Ben Hutchings's message of "Thu, 3 May 2012 21:22:22 +0100")

Ben Hutchings <bhutchings@solarflare.com> writes:

> On Thu, 2012-05-03 at 19:25 +0000, Bedia, Vaibhav wrote:
>> On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
>> [...]
>> > > 
>> > > So, if I understood this correctly, it's effectively like blocking a low power
>> > > state transition (here wfi execution) when EMAC is active?
>> > 
>> > Assuming "it" is my patch, correct.
>> > 
>> 
>> Recently I was thinking about how to get certain drivers to disallow some or all
>> low power states and to me this also seems to fall in a similar category.
>> 
>> One of the suggestions that I got was to check if the 'wakeup' entry associated with
>> the device under sysfs could be leveraged for this. The PM code could maintain
>> a whitelist (or blacklist) of devices and it decides the low power state to enter
>> based on the 'wakeup' entries associated with these devices. In this particular case,
>> maybe the driver could simply set this entry to non-wakeup capable when necessary and
>> then let the PM code take care of skipping the wfi execution.
>> 
>> Thoughts/brickbats welcome :)
>
> You can maybe (ab)use the pm_qos mechanism for this.

I thought of using this too, but it doesn't actually solve the problem:

Using PM QoS, you can avoid hitting the deeper idle states by setting a
very low wakeup latency.  However, on ARM platforms, even the shallowest
idle states use the WFI instruction, and the EMAC would still not be
able to wake the system from WFI.  A possibility would be define the
shallowest idle state to be one that doesn't call WFI and just does
cpu_relax().  However, that would only work for CPUidle since PM QoS
constraints are only checked by CPUidle.  So, a non-CPUidle kernel would
still have this bug. :(

Ultimately, this is just broken HW.  This network HW was bolted onto an
existing SoC without consideration for wakeup capabilities.  The result
is that any use of this device with networking has to completely disable
SoC power management.

Kevin

  reply	other threads:[~2012-05-03 21:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 23:47 [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks Mark A. Greer
2012-05-03 10:44 ` Bedia, Vaibhav
2012-05-03 14:22   ` Kevin Hilman
2012-05-03 16:09   ` Mark A. Greer
2012-05-03 18:21     ` Bedia, Vaibhav
2012-05-03 18:46       ` Mark A. Greer
2012-05-03 19:25         ` Bedia, Vaibhav
2012-05-03 20:22           ` Ben Hutchings
2012-05-03 21:32             ` Kevin Hilman [this message]
2012-05-04 13:55               ` Bedia, Vaibhav
2012-05-04 14:31                 ` Kevin Hilman
2012-05-04 18:29                   ` Mark A. Greer
2012-05-04 21:02                     ` Kevin Hilman
2012-05-04 21:47                       ` Mark A. Greer
2012-05-04 16:35                 ` Mark A. Greer

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=87ehr1gdcv.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=bhutchings@solarflare.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mgreer@animalcreek.com \
    --cc=netdev@vger.kernel.org \
    --cc=vaibhav.bedia@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).