* Ulf Hansson [off-list ref] [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