summaryrefslogtreecommitdiff
path: root/drivers/sn/Makefile
diff options
context:
space:
mode:
authorBenoit Parrot <bparrot@ti.com>2016-11-19 02:20:41 +0300
committerMauro Carvalho Chehab <mchehab@s-opensource.com>2016-11-22 13:10:14 +0300
commit35be6d865c2b6c0866164fef14832ecc5def9d2b (patch)
tree1e13c8edd9f37bba774c52f98032cd8394196c6d /drivers/sn/Makefile
parentd6a617877368c73c96d9f3adce9d9c8092bbff7d (diff)
downloadlinux-35be6d865c2b6c0866164fef14832ecc5def9d2b.tar.xz
[media] media: ti-vpe: vpe: Make sure frame size dont exceed scaler capacity
When scaler is to be used we need to make sure that the input and output frame size do not exceed the maximum frame sizes that the scaler h/w can handle otherwise streaming stall as the scaler cannot proceed. The scaler buffer is limited to 2047 pixels (i.e. 11 bits) when attempting anything larger (2048 for example) the scaler stalls. Realistically in an mem2mem device we can only check for this type of issue when start_streaming is called. We can't do it during the try_fmt/s_fmt because we do not have all of the info needed at that point. So instead when start_streaming is called we need to check that the input and output frames size do not exceed the scaler's capability. The only time larger frame size are allowed is when the input frame szie is the same as the output frame size. Now in the case where we need to fail, start_streaming must return all previously queued buffer back otherwise the vb2 framework will issue kernel WARN messages. In this case we also give an error message. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'drivers/sn/Makefile')
0 files changed, 0 insertions, 0 deletions