public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
	kernel list <linux-kernel@vger.kernel.org>,
	Greg KH <greg@kroah.com>
Subject: Re: iommu breaks usb after resume
Date: Fri, 28 Mar 2008 14:50:38 +0100	[thread overview]
Message-ID: <20080328135038.GD4544@ucw.cz> (raw)
In-Reply-To: <200803280052.01250.rjw@sisk.pl>

Hi!

> > > > diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
> > > > index d8200ac..4e85178 100644
> > > > --- a/drivers/char/agp/amd64-agp.c
> > > > +++ b/drivers/char/agp/amd64-agp.c
> > > > @@ -594,12 +594,14 @@ static int agp_amd64_suspend(struct pci_
> > > >  
> > > >  static int agp_amd64_resume(struct pci_dev *pdev)
> > > >  {
> > > > +	printk("agp_amd64: resume\n");
> > > >  	pci_set_power_state(pdev, PCI_D0);
> > > >  	pci_restore_state(pdev);
> > > >  
> > > >  	if (pdev->vendor == PCI_VENDOR_ID_NVIDIA)
> > > >  		nforce3_agp_init(pdev);
> > > >  
> > > > +	printk("agp_amd64: 8151 configure\n");
> > > >  	return amd_8151_configure();
> > > >  }
> > > >  
> > > > @@ -733,8 +735,8 @@ static struct pci_driver agp_amd64_pci_d
> > > >  	.probe		= agp_amd64_probe,
> > > >  	.remove		= agp_amd64_remove,
> > > >  #ifdef CONFIG_PM
> > > > -	.suspend	= agp_amd64_suspend,
> > > > -	.resume		= agp_amd64_resume,
> > > > +	.suspend_late	= agp_amd64_suspend,
> > > > +	.resume_early	= agp_amd64_resume,
> > > >  #endif
> > > >  };
> > > 
> > > Okay, a couple of questions:
> > > 
> > > (1) Are you sure that the .suspend() and .resume() callbacks will just work
> > >     with interrupts disabled?
> > 
> > I have not really checked -- it turned out this is not "my" problem
> > after all. My machine (called leet) uses different setup. If they will
> > not, I guess lockdep will tell us ;-).
> 
> Lockdep need not tell us about it, I think.  OTOH, I don't really see a
> scenario in which having interrupts disabled while executing ->suspend() and
> ->resume() might hurt.

Ok.

> > > (2) Even if they work, is it sufficient to just move them to the "late" and
> > >     "early" parts?  That is, isn't there anything using the iommu in the
> > >     "early" and "late" callbacks of the other devices?
> > 
> > We definitely have iommu users in "normal" callbacks: USB.
> 
> Oh, there may be more.  You never know what appears in future systems. :-)

Well, we'll catch them during code review, right?

> > I do not think we have iommu users in early/late callbacks...
> 
> Perhaps not at the moment, but what's the guarantee there won't be any in the
> future?

That's why we review changes... ok, maybe documenting it somewhere
would be nice...?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

      reply	other threads:[~2008-03-28 13:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20 11:14 iommu breaks usb after resume Pavel Machek
2008-03-21 13:27 ` Ingo Molnar
2008-03-21 13:54 ` Andi Kleen
2008-03-26 10:21   ` Pavel Machek
2008-03-26 13:00     ` Andi Kleen
2008-03-26 22:54       ` Pavel Machek
2008-03-26 23:00         ` Ingo Molnar
2008-03-26 23:05           ` Pavel Machek
2008-03-27  5:53             ` Andi Kleen
2008-03-27  8:41               ` Pavel Machek
2008-03-27  8:42           ` Pavel Machek
2008-03-27  8:47             ` (eats disks) " Pavel Machek
2008-03-27  9:59             ` Pavel Machek
2008-03-27 11:49               ` Andi Kleen
2008-03-27 13:29                 ` Pavel Machek
2008-03-27 13:34                   ` Andi Kleen
2008-03-27 20:30         ` Rafael J. Wysocki
2008-03-27 23:40           ` Pavel Machek
2008-03-27 23:52             ` Rafael J. Wysocki
2008-03-28 13:50               ` Pavel Machek [this message]

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=20080328135038.GD4544@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=andi@firstfloor.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    /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