Re: [ACPI] Re: [Alsa-devel] [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (1/2)

[Shaohua Li <shaohua.li@intel.com>]

On Thu, 2005-07-28 at 10:43 +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> On Thursday, 28 of July 2005 10:06, Takashi Iwai wrote:
> > At Wed, 27 Jul 2005 22:52:49 +0200,
> > Pavel Machek wrote:
> > > 
> > > Hi!
> > > 
> > > > > The following patch adds free_irq() and request_irq() to the suspend and
> > > > > resume, respectively, routines in the snd_intel8x0 driver.
> > > > 
> > > > The patch looks OK to me although I have some concerns.
> > > > 
> > > > - The error in resume can't be handled properly.
> > > > 
> > > >   What should we do for the error of request_irq()?
> > > > 
> > > > - Adding this to all drivers seem too much.
> > > 
> > > There's probably no other way. Talk to Len Brown.
> > > 
> > > >   We just need to stop the irq processing until resume, so something
> > > >   like suspend_irq(irq, dev_id) and resume_irq(irq, dev_id) would be
> > > >   more uesful?
> > > 
> > > Its more complex than that. Irq numbers may change during resume.
> > 
> > Hmm, then the patch looks wrong.  It assumes that the irq number is
> > as same as before suspend.
> 
> Well, that''s the theory, but frankly I don't see a practical reason.  I have never
> seen this happening.  Practically, for this to happen, you'll have to reconfigure
> the BIOS accross suspend/resume which is dangerous anyway.
>From my understanding, we should not have such assumption. Say all
device drivers with the same ioapic pin have freed irq. We might mask
the ioapic pin and even free the vector. Then after you request_irq
again, the interrupt might get different vector. If you enable MSI, then
it's broken.
In IA64, we already have such staff (mask ioapic pin and free vector).

Thanks,
Shaohua