Hi, ma, 2012-10-15 kello 18:02 -0700, Tony Lindgren kirjoitti: > * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [121015 10:32]: > > Kalle Jokiniemi <kalle.jokiniemi@xxxxxxxxxxxxxxx> writes: > > > > > > Does not work for me :( > > > > > > As I said, the issue occurs for me when I enter static suspend (echo mem > > >> /sys/power/autosleep or /sys/power/state). I don't think doing this > > > just in runtime pm will fix my issue. Or do those handlers get run in > > > the normal suspend path as well? > > > > If the I2C device is still active during the suspend path, these > > handlers will get run by the PM domain code (in omap_device.) However, > > now that I think about it, the current omap_device PM domain code calls > > these at the noirq level, not the late/early level, so it does not > > address your original problem. :( > > > > I suspect we'll need this and your original patch. > > Have you checked that this is not related to flushing the posted > write? If it is, reading back any register from the i2c controller > after writing to it ensures the write actually reaches the i2c > controller. The twl4030-irq handler (handle_twl4030_pih) function just reads the PIH irq status over the i2c and calls handle_nested_irq for each set module (like USB, GPIO, etc) irq bit. This does not clear the interrupt however, that is done in the nested interrupt, once it runs (by clearing the actual interrupt inside the module). I'm thinking now that it's actually this PIH handler that should be postponed until resume_noirq has finished. I had another idea as well yesterday to mark the secondary irq handlers with IRQF_EARLY_RESUME flag. Though that did not work on the quick test I did. Anyway new patch coming soon :) - Kalle > > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
