Re: tvp5150 regression after commit 9f924169c035

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Tony,

On 02/12/2016 07:13 PM, Tony Lindgren wrote:
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()


By driver do you mean the OMAP GPIO driver or the tvp5150 I2C driver?
The latter does not have runtime PM support.

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.


I can check if the OMAP GPIO is following these and give a try but
don't have access to the board right now so I'll do it on Monday.

Regards,

Tony


Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux