Hello Tony,
On 02/12/2016 08:46 PM, Tony Lindgren wrote:
[snip]
OK I doubt it's the GPIO driver if reverting 9f924169c035
helps.
Right, sorry. I first thought the problem was with the OMAP GPIO
driver but then found that reverting 9f924169c035 caused the issue
to go away which indicates the problem is somehow related to I2C.
I forgot that and got confused again when answering to your email.
I do see some GPIO regressions in current Linux next though,
but sounds like you're using v4.5-rc series.
Yes, I'm testing with v4.5-rc and not linux-next.
It seems that is not related but I hope that given you were
looking at the runtime PM core lately, maybe you can figure
out what we are missing.
I'm far from being familiar with the runtime PM framework
but I've looked and can't figure out why Wolfram's commit
make this driver to fail and reverting his commit make its
work again.
No idea. What kind of PM runtime use case has that one been
tested with?
Nothing special, the driver just fails to probe. What the driver
does is to toggle some pins (Power Down and Reset) in the tvp5150
chip to put it in an operational state and then attempts to read
an I2C register to detect the chip version and this is what fails.
Regards,
Tony
I'll try to find some time next week to dig deeper on this. Just
thought that may be related to the issue you found but it seems
that's not the case.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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
