public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux PCI <linux-pci@vger.kernel.org>,
	pm list <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH 0/2] Export platform_pci_set_power_state() and make radeonfb use it
Date: Tue, 24 Mar 2009 11:57:19 +1100	[thread overview]
Message-ID: <1237856239.25062.696.camel@pasglop> (raw)
In-Reply-To: <20090323152330.536a5a1c@hobbes.virtuouswap>

On Mon, 2009-03-23 at 15:23 -0700, Jesse Barnes wrote:
> The thing I didn't like was that it made the radeon driver use an
> internal interface; I'd really prefer a proper return value from
> pci_set_power_state, which in turn means auditing all its current
> callers. But that doesn't seem worth it unless we see other drivers
> needing something similar...
> 
> And if we did go with something like your first patch, I'd still rather
> see the timeout done in the driver, rather than having the attempts &
> delay included in the function...

So what ? The driver would call pci_set_power_state() until it stops
failing ?

I'm not too fan of that, because it will change the access pattern
to the chip:

 - write PM to 2
 - short delay
 - read PM, see 0, return error
 - driver does big delay
 - write PM to 2
 - short delay
 - read PM ....

vs. the current sequence which is

 - write PM to 2
 - long delay
 - read PM, be happy

Which -seems- to be pretty much what happens in practice, though on that chip,
I don't know for sure about others.

I'm worried of the possible side effects of the first sequence that you propose
since it would do 2 things potentially confusing to the HW:

 - read PM after a short delay... it -should- be harmless but you know
HW as well as I do ...

 - write PM to 2 a second time after the long delay. Again, it -should- be
harmless since the chip at this stage should already be in D2 state but god
knows how the HW will react.

I'm especially worried about the later in fact. Maybe we can minimize it by
having pci_set_power_state() dbl check the content of the PM reg before writing
to it...

Ben.



  reply	other threads:[~2009-03-24  1:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20 23:03 [RFC][PATCH] PCI PM: Be extra careful when changing power states of devices Rafael J. Wysocki
2009-03-22 21:08 ` [RFC][PATCH 0/2] Make radeonfb use PCI PM core for suspendig device (was: Re: [RFC][PATCH] PCI PM: Be extra careful when changing power states of devices) Rafael J. Wysocki
2009-03-22 21:11   ` [RFC][PATCH 1/2] PCI PM: Introduce __pci_set_power_state() Rafael J. Wysocki
2009-03-22 23:08     ` [linux-pm] " Nigel Cunningham
2009-03-23 18:14       ` Rafael J. Wysocki
2009-03-22 21:13   ` [RFC][PATCH 2/2] radeonfb: Avoid open coding of PCI PM operations Rafael J. Wysocki
2009-03-23  0:09   ` [RFC][PATCH 0/2] Make radeonfb use PCI PM core for suspendig device (was: Re: [RFC][PATCH] PCI PM: Be extra careful when changing power states of devices) Benjamin Herrenschmidt
2009-03-23 23:01     ` Rafael J. Wysocki
2009-03-23 21:30   ` [RFC][PATCH 0/2] Export platform_pci_set_power_state() and make radeonfb use it Rafael J. Wysocki
2009-03-23 21:31     ` [RFC][PATCH 1/2] PCI PM: Export platform_pci_set_power_state() Rafael J. Wysocki
2009-03-23 21:32     ` [RFC][PATCH 2/2] radeonfb: Use platform_pci_set_power_state() Rafael J. Wysocki
2009-03-23 22:23     ` [RFC][PATCH 0/2] Export platform_pci_set_power_state() and make radeonfb use it Jesse Barnes
2009-03-24  0:57       ` Benjamin Herrenschmidt [this message]
2009-03-24  1:14         ` Jesse Barnes
2009-03-24 11:00           ` Rafael J. Wysocki
2009-03-24 21:12             ` Benjamin Herrenschmidt
2009-03-24 22:00               ` Rafael J. Wysocki
2009-03-24 22:25               ` Rafael J. Wysocki
2009-03-24 22:04           ` Alex Deucher

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=1237856239.25062.696.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=akpm@linux-foundation.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox