Thread (175 messages) 175 messages, 16 authors, 2017-03-22

[PATCH v5 00/39] i.MX Media Driver

From: slongerbeam@gmail.com (Steve Longerbeam)
Date: 2017-03-14 17:29:16
Also in: linux-devicetree, linux-media, lkml


On 03/12/2017 02:09 PM, Russell King - ARM Linux wrote:
On Sun, Mar 12, 2017 at 08:40:37PM +0000, Russell King - ARM Linux wrote:
quoted
On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote:
quoted
But hold on, if my logic is correct, then why did the CSI power-off
get reached in your case, multiple times? Yes I think there is a bug,
link_notify() is not checking if the link has already been disabled.
I will fix this. But I'm surprised media core's link_notify handling
doesn't do this.
Well, I think there's something incredibly fishy going on here.  I
turned that dev_dbg() at the top of the function into a dev_info(),
and I get:

root at hbi2ex:~# dmesg |grep -A2 imx-ipuv3-csi
[   53.370949] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.371015] ------------[ cut here ]------------
[   53.371075] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi]
--
[   53.372624] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.372637] ------------[ cut here ]------------
[   53.372663] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi]

There isn't a power on event being generated before these two power
off events.  I don't see a power on event even when I attempt to
start streaming either (which fails due to the lack of bayer
support.)
Found it - my imx219 driver returns '1' from its s_power function when
powering up, which triggers a bug in your code - when imx_media_set_power()
fails to power up, you call imx_media_set_power() telling it to power
everything off - including devices that are already powered off.
Yep, there's a bug in the error cleanup in imx_media_pipeline_set_power().
On error, it needs to backout by calling s_power(off) as it is doing, 
but not
through the whole pipeline, but needs to stop at the subdev encountered
just before the subdev that failed. This was causing the s_power() 
imbalance.
I will fix.

This is really bad news - s_power() may be called via other paths,
such as when the subdev is opened.
I don't think that is a problem, as long as power_count is working
as it should, and the caller from the other paths has not created an
imbalance.

Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help