* Ulf Hansson <ulf.hansson@xxxxxxxxxx> [160203 08:25]: > Okay, so I understand that you decided to not pick up the omap hwmod > patch I posted. I just suggested a solution of patching both drivers and omap_device to make it easy for people to fix new drivers, so assuming that sounds OK to you.. > If you want some further help in fixing the omap drivers, please just > tell me I am at your service. :-) Heh me too :) It's probably worth checking the non omap_device drivers thouhg. I can check and fix up the omap_device using drivers. So roughly it's these ones: $ git grep pm_runtime_use_autosuspend drivers | cut -d: -f1 | \ sort | uniq | grep omap drivers/i2c/busses/i2c-omap.c drivers/mmc/host/omap_hsmmc.c drivers/spi/spi-omap2-mcspi.c drivers/tty/serial/8250/8250_omap.c drivers/tty/serial/omap-serial.c > Also, we must not forget to also update their runtime PM calls in > their ->remove() callbacks, as those seems to suffer from the same > problem as in the -EPROBE_DEFER case. Yes and any sections within the driver code where clocks really should be disabled we must use pm_runtime_put_sync_suspend() if pm_runtime_set_autoidle() is set. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
