lkml.org 
[lkml]   [2004]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
Pallipadi, Venkatesh wrote:

> The current theory I have for this issue is we resume pci_link driver
> A bit too late, which is causing this problem.
>
> Say a particular device doesn't do anything for suspend and resume.
> So, as soon as we resume this particular device can start
> generating interrupts. Once we have PIC enabled, it starts sending
> interrupts and no one handles that original IRQ. As pci_link that
> resumes later is reprogramming the device to different IRQ, where the
> driver is handling the device.
>
> That's probably the reason why it works with acpi=noirq or
> modified DSDT. Does it make sense?

Yes. Sometimes acpi=noirq is gentler than ACPI irq mode, because the
ACPI bios may not report the current active IRQ (which was assiged by
the BIOS during boot) as a "possible" IRQ, even though the south bridge
really supports just about any routing.

The result is that the kernel changes the routing when drivers are
initialized during boot, and the kernel chooses one of the IRQ's from
the possible list. However, during resume from S3, the BIOS will put the
routing back the way it was at boot and the kernel has to change the
routing again.

acpi=noirq mode doesn't change the hardware's current routing settings
if an IRQ is already enabled, so there is less opportunity for things to
get out of sync with what the device drivers are expecting.

Something else to watch out for on ICH2 and similar chipsets is that, as
long as the IRQ router is steering a PCI link onto a certain IRQ, LPC
ISA device are blocked from triggering that IRQ via the SERIRQ protocol.
But if we move the all the PCI links elsewhere, the SERIRQ is no longer
blocked, and if some ISA LPC device is holding a high level, which
normally wouldn't trigger IRQ's under ISA, then the IRQ line will get
disabled because the PIC is probably set to level-trigger because it was
PCI at one point. I've seen this happen with IRQ 12 when the BIOS
decided there was no PS/2 mouse present so it could re-use the IRQ. The
real cause is that the i850 has a register that allows IRQ1 and IRQ12
to be disabled on the LPC bus, and this register isn't restored on
resume. This probably doesn't apply to IRQ11 on Stefan's system, though...

>
> I think we have to resume pci_link device before PIC.

That's probably a good idea. If your theory is correct, then waiting
until the PCI device drivers call pci_enable_device() may be too late,
and we might have to do this early in boot. Ideally it wouldn't be a
problem, because device drivers would all disable their devices on
suspend, but there are driverless devices to worry about, and maybe also
badly-behaved hardware that doesn't shut up?

Maybe it's time to look at the suspend/resume callbacks on the ipw2100
driver, anyway.

Nathan

> We should be able to achieve this my changing the makefile orders.
>
> Thanks,
> Venki
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.035 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site