summaryrefslogtreecommitdiffstats
path: root/drivers/media/platform/vsp1/vsp1_wpf.c
diff options
context:
space:
mode:
authorKieran Bingham2016-09-06 19:07:09 +0200
committerMauro Carvalho Chehab2016-09-19 19:50:15 +0200
commitbfb4d5be9e1d5a70d0710e815d15a4245eaaafc4 (patch)
tree875f649300c558851693b0dd0a1cd50eaf046fbe /drivers/media/platform/vsp1/vsp1_wpf.c
parent[media] v4l: vsp1: Ensure pipeline locking in resume path (diff)
downloadkernel-qcow2-linux-bfb4d5be9e1d5a70d0710e815d15a4245eaaafc4.tar.gz
kernel-qcow2-linux-bfb4d5be9e1d5a70d0710e815d15a4245eaaafc4.tar.xz
kernel-qcow2-linux-bfb4d5be9e1d5a70d0710e815d15a4245eaaafc4.zip
[media] v4l: vsp1: Repair race between frame end and qbuf handler
The frame-end function releases and completes the buffers on the input and output entities of the pipe before marking the pipe->state as 'STOPPED'. This introduces a race whereby with the pipe->state still 'RUNNING', a QBUF handler can commence processing a frame before the frame_end function has completed. In the event that this happens, a frame queued by QBUF hangs due to the incorrect pipe->state setting which prevents vsp1_pipeline_run from issuing a CMD_STRCMD. By locking the entire function we prevent this from occurring, but we also change the locking state of the buffer release code. This has been analysed visually as acceptable, but it must be considered that this now causes the video->irqlock to be taken under the pipe->irqlock context. Signed-off-by: Kieran Bingham <kieran+renesas@bingham.xyz> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'drivers/media/platform/vsp1/vsp1_wpf.c')
0 files changed, 0 insertions, 0 deletions