Hi,
* Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> [160212 14:10]:
> Hello,
>
> On 02/08/2016 07:54 AM, Wolfram Sang wrote:
> >On Wed, Feb 03, 2016 at 10:46:51AM -0300, Javier Martinez Canillas wrote:
> >>Hello Wolfram,
> >>
> >>I've a issue with a I2C video decoder driver (drivers/media/i2c/tvp5150.c).
> >>
> >>In v4.5-rc1, the driver gets I2C read / writes timeouts when accessing the
> >>device I2C registers:
> >>
> >>tvp5150 1-005c: i2c i/o error: rc == -110
> >>tvp5150: probe of 1-005c failed with error -110
> >>
> >>The driver used to work up to v4.4 so this is a regression in v4.5-rc1:
> >>
> >>tvp5150 1-005c: tvp5151 (1.0) chip found @ 0xb8 (OMAP I2C adapter)
> >>tvp5150 1-005c: tvp5151 detected.
> >>
> >>I tracked down to commit 9f924169c035 ("i2c: always enable RuntimePM for
> >>the adapter device") and reverting that commit makes things to work again.
> >>
> >>The tvp5150 driver doesn't have runtime PM support but the I2C controller
> >>driver does (drivers/i2c/busses/i2c-omap.c) FWIW.
> >>
> >>I tried adding runtime PM support to tvp5150 (basically calling pm_runtime
> >>enable/get on probe before the first I2C read to resume the controller) but
> >>that it did not work.
> >>
> >>Not filling the OMAP I2C driver's runtime PM callbacks does not help either.
> >>
> >>Any hints about the proper way to fix this issue?
> >
> >Asking linux-pm for help:
> >
> >The commit in question enables RuntimePM for the logical adapter device
> >which sits between the HW I2C controller and the I2C client device. This
> >adapter device has been used with pm_runtime_no_callbacks before
> >enabling RPM. Now, Alan explained to me that "suspend events will
> >propagate from the I2C clients all the way up to the adapter's parent."
> >with RPM enabled for the adapter device. Which should be a no-op if the
> >client doesn't do any PM at all? What do I miss?
>
> I'm adding Tony Lindgren to the cc list as well since he is the OMAP
> maintainer and I see that has struggled lately with runtime PM issues
> so maybe he has more ideas.
Hmm yeah I wonder if this canned solution helps here too:
1. Check if the driver(s) are using pm_runtime_use_autosuspend()
2. If so, you must use pm_runtime_dont_use_autosuspend() before
pm_runtime_put_sync() to make sure that pm_runtime_put_sync()
works.
3. Or you can use pm_runtime_put_sync_suspend() instead of
pm_runtime_put_sync() for sections of code where the clocks
need to be stopped.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
