public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjanv@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Pavel Machek <pavel@ucw.cz>,
	greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: Resume enhancement: restore pci config space
Date: Tue, 1 Jun 2004 17:38:00 +0200	[thread overview]
Message-ID: <20040601153800.GA22986@devserv.devel.redhat.com> (raw)
In-Reply-To: <s5hbrk3qoxw.wl@alsa2.suse.de>

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Tue, Jun 01, 2004 at 05:26:51PM +0200, Takashi Iwai wrote:
> At Tue, 01 Jun 2004 17:06:38 +0200,
> Arjan van de Ven wrote:
> > 
> > [1  <text/plain (quoted-printable)>]
> > 
> > > int xxx_resume(struct pci_dev *dev)
> > > {
> > > 	int err;
> > > 	if ((err = pci_default_resume(dev)) < 0)
> > > 		return err;
> > > 	// ... do h/w specific
> > > }
> > 
> > well define "h/w specific", just give me an example of a real (alsa?)
> > driver that would use it (or point me to one) so that I can see if this
> > is the best API, what the return value should be etc etc 
> 
> I'm afraid the ALSA drivers aren't be the best examples :)
> It doesn't handle the error in suspend/resume at all.

hm it looks like all this would gain is that instead of 2 or 3 function calls
you need to do one which then calls those 3. The *driver* already knows if
it needs busmaster or not etc, so when I wrote this code I felt that the
driver could do a better job really. But well if you think it's worth it to
save those 3 lines into 1 ?


> Hmm, looking at them right now, and i found most of them don't have
> pci_suspend_state() because it worked without saving/restoring the pci
> state _casually_, and missing pci_set_power_state(), etc...

I made the PCI layer save PCI config space always, and the generic resume callback
conditional, so saving PCI config state is not something that explicitly
needs to be done in the suspend hook. I don't know what else a suspend
standard function needs to do.


Gretings,
   Arjan van de Ven

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-06-01 15:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-26 20:35 Resume enhancement: restore pci config space Arjan van de Ven
2004-05-26 22:39 ` Greg KH
2004-05-27  9:44 ` Takashi Iwai
2004-05-30 18:40 ` Pavel Machek
2004-05-31 13:38   ` Arjan van de Ven
2004-06-01 13:54     ` Takashi Iwai
2004-06-01 15:06       ` Arjan van de Ven
2004-06-01 15:26         ` Takashi Iwai
2004-06-01 15:38           ` Arjan van de Ven [this message]
2004-06-01 15:58             ` Takashi Iwai
2004-06-01 16:02             ` Pavel Machek
2004-06-01 16:18               ` Takashi Iwai
2004-05-31 16:38   ` Jan-Benedict Glaw
  -- strict thread matches above, loose matches on Subject: below --
2004-05-26 21:44 Nakajima, Jun

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=20040601153800.GA22986@devserv.devel.redhat.com \
    --to=arjanv@redhat.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tiwai@suse.de \
    /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