kernel/drivers/media/platform/vim2m.c, branch linux-5.1.y

media: vim2m: fix two double-free issues

2019-07-26T07:12:27Z

[ Upstream commit 20059cbbf981ca954be56f7963ae494d18e2dda1 ] vim2m_device_release() will be called by video_unregister_device() to release various objects. There are two double-free issue, 1. dev->m2m_dev will be freed twice in error_m2m path/vim2m_device_release 2. the error_v4l2 and error_free path in vim2m_probe() will release same objects, since vim2m_device_release has done. Fixes: ea6c7e34f3b2 ("media: vim2m: replace devm_kzalloc by kzalloc") Cc: Laurent Pinchart Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: vim2m: replace devm_kzalloc by kzalloc

2019-05-31T13:43:54Z

[ Upstream commit ea6c7e34f3b28e165988aa7391310752969842e8 ] It is not possible to use devm_kzalloc since that memory is freed immediately when the device instance is unbound. Various objects like the video device may still be in use since someone has the device node open, and when that is closed it expects the memory to be around. So use kzalloc and release it at the appropriate time. Signed-off-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: vim2m: Address some coding style issues

2019-03-01T16:51:23Z

As we did lots of change at vim2m driver, let's take the opportunity and make checkpatch happier, addressing the errors/warnings that makes sense. While here, increment driver's version. No functional changes. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: don't use BUG()

2019-03-01T16:48:56Z

There's no reason why this driver should use BUG(). Instead, just properly handle issue, returning an error code where pertinent. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: speedup passthrough copy

2019-03-01T16:31:07Z

When in passthrough mode, copy the entire line at once, in order to make it faster (if not HFLIP). Signed-off-by: Mauro Carvalho Chehab

media: vim2m: add an horizontal scaler

2019-03-01T16:25:05Z

Add an horizontal linear scaler using Breseham algorithm in order to speep up its calculus. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: don't accept YUYV anymore as output format

2019-03-01T16:16:48Z

Handling any Y,Cr,Cb formats require some extra logic, as it handles a group of two pixels. That's easy while we don't do horizontal scaling. However, doing horizontal scaling with such formats would require a lot more code, in order to avoid distortions, as, if it scales to two non-consecutive points, the logic would need to read 4 points in order to properly convert to RGB. As this is just a test driver, and we want fast algorithms, let's just get rid of this format as an output one. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: add vertical linear scaler

2019-03-01T16:16:21Z

When resolutions are different, the expected behavior is to scale the image. Implement a vertical scaler as the first step. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: better handle cap/out buffers with different sizes

2019-03-01T16:12:23Z

The vim2m driver doesn't enforce that the capture and output buffers would have the same size. Do the right thing if the buffers are different, zeroing the buffer before writing, ensuring that lines will be aligned and it won't write past the buffer area. This is a temporary fix. A proper fix is to either implement a simple scaler at vim2m, or to better define the behaviour of M2M transform drivers at V4L2 API with regards to its capability of scaling the image or not. In any case, such changes would deserve a separate patch anyway, as it would imply on some behavoral change. Also, as we have an actual bug of writing data at wrong places, let's fix this here, and add a mental note that we need to properly address it. Signed-off-by: Mauro Carvalho Chehab

media: vim2m: use different framesizes for bayer formats

2019-03-01T16:06:49Z

The only real restriction at vim2m is that width should be multiple of two, as the copy routine always copy two pixels each time. However, Bayer formats are defined as having a 2x2 matrix. So, odd vertical numbers would cause color distortions at the last line. So, it makes sense to use step 2 for vertical alignment on Bayer. With this patch, the reported formats for video capture will be: [0]: 'RGBP' (16-bit RGB 5-6-5) Size: Stepwise 32x32 - 640x480 with step 2/1 [1]: 'RGBR' (16-bit RGB 5-6-5 BE) Size: Stepwise 32x32 - 640x480 with step 2/1 [2]: 'RGB3' (24-bit RGB 8-8-8) Size: Stepwise 32x32 - 640x480 with step 2/1 [3]: 'BGR3' (24-bit BGR 8-8-8) Size: Stepwise 32x32 - 640x480 with step 2/1 [4]: 'YUYV' (YUYV 4:2:2) Size: Stepwise 32x32 - 640x480 with step 2/1 [5]: 'BA81' (8-bit Bayer BGBG/GRGR) Size: Stepwise 32x32 - 640x480 with step 2/2 [6]: 'GBRG' (8-bit Bayer GBGB/RGRG) Size: Stepwise 32x32 - 640x480 with step 2/2 [7]: 'GRBG' (8-bit Bayer GRGR/BGBG) Size: Stepwise 32x32 - 640x480 with step 2/2 [8]: 'RGGB' (8-bit Bayer RGRG/GBGB) Size: Stepwise 32x32 - 640x480 with step 2/2 Signed-off-by: Mauro Carvalho Chehab