path: root/drivers/staging
diff options
authorHelen Koike <helen.koike@collabora.com>2019-08-08 21:27:41 -0300
committerMauro Carvalho Chehab <mchehab+samsung@kernel.org>2019-08-13 11:40:38 -0300
commit09c41a23a2e2de7ed347251d7079a42de0dd230b (patch)
tree04317b6c35374a578a8df257de210c06c527d71d /drivers/staging
parent10b1aed6dac01d566b6b3c261a191546c82f0157 (diff)
media: Revert "media: vimc: propagate pixel format in the stream"
This reverts commit b6c61a6c37317efd7327199bfe24770af3d7e799. The requested pixelformat is being propagated from the capture to the tpg in the sensor. This was a bad design choice, as we start having the following issues: * We set a pixelformat in the capture; * We set matching media bus formats in the subdevices pads; * Link validate looks fine (sizes matches, media bus formats matches); * Issue: if some of the subdevice doesn't know how to generate the requested pixelformat in the capture, then stream_on fails. This is bad because capture says it supports that pixelformat, everything looks fine, but it is not, and there is no way to find it out through the links. This patch was implemented so we could request any pixelformat from the pipeline regardeless of the media bus format configured between pads. Not all pixelformat can be mapped into a media bus code (e.g. multiplanar formats), so with this patch we could request those pixelformats from the tpg. Solution: map pixelformats to media bus codes as before, and implement conversions to other pixelformats in the capture to support multiplanar. So first step to this solution is to revert this patch. Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Lucas A. M. Magalhaes <lucmaga@gmail.com> Tested-by: André Almeida <andrealmeid@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Diffstat (limited to 'drivers/staging')
0 files changed, 0 insertions, 0 deletions

Privacy Policy