On Sat, May 30, 2009 at 3:18 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Friday 29 May 2009, Alan Stern wrote: >> On Fri, 29 May 2009, Magnus Damm wrote: >> >> > > (And by the way, the _noirq ops don't run in atomic context. They run >> > > in process context with most interrupt deliveries disabled. It's not >> > > the same thing -- they are allowed to sleep.) >> > >> > Huh, so if they are allowed to sleep then clock events are still >> > running. And probably some clocksource as well. I guess that's why you >> > say "most" interrupts disabled instead of all. Sharing the timer IRQ >> > is not allowed then? >> >> Rafael can tell you. But notice I didn't say the interrupts were >> disabled -- I said that interrupt _delivery_ was disabled. In general >> the interrupts themselves _are_ enabled; the kernel fields them but >> then does not call the drivers' interrupt handler routines. > > That's correct, except for the platforms where __disable_irq() actually masks > the IRQ. I'm not sure if SuperH is one of these. We make use of CONFIG_GENERIC_HARDIRQS so the __disable_irq() suspend logic should work for us as well. >> (Except perhaps for IRQs which are explicitly marked as wakeup sources...) > > No, they are treated just like the other ones except that we check if any of > them are pending right at the beginning of sysdev_suspend(). > >> > I wonder if the PM code assumes that the clock event is a sys device? > > Yes, it does. I note the IRQF_TIMER check in __disable_irq(). I wonder if we can make a second not bus-specific round where we disable only IRQF_TIMER interrupts. >> > We use platform drivers for clock events on SuperH... > > Argh. This is going to hurt, but I'm not sure how badly. At least on > multiprocessor. Luckily most boards around here are still UP. =) / magnus _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
