kernel.git/drivers/media/platform/davinci, branch linux-4.13.y

media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS

2017-07-26T10:14:33Z

drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons: - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Signed-off-by: Lad, Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl

2017-07-26T10:14:33Z

this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works for vpfe_capture driver with a minimal patch suitable for backporting. - This ioctl was never in public api and was only defined in kernel header. - The function set_params constantly mixes up pointers and phys_addr_t numbers. - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is described as an 'experimental ioctl that will change in future kernels'. - The code to allocate the table never gets called after we copy_from_user the user input over the kernel settings, and then compare them for inequality. - We then go on to use an address provided by user space as both the __user pointer for input and pass it through phys_to_virt to come up with a kernel pointer to copy the data to. This looks like a trivially exploitable root hole. Due to these reasons we make sure this ioctl now returns -EINVAL and backport this patch as far as possible. Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver") Signed-off-by: Lad, Prabhakar Cc: # for v3.7 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: davinci: variable 'common' set but not used

2017-07-17T14:19:41Z

Get rid of those two warnings: drivers/media/platform/davinci/vpif_capture.c: In function 'vpif_remove': drivers/media/platform/davinci/vpif_capture.c:1722:21: warning: variable 'common' set but not used [-Wunused-but-set-variable] struct common_obj *common; ^~~~~~ drivers/media/platform/davinci/vpif_display.c: In function 'vpif_remove': drivers/media/platform/davinci/vpif_display.c:1342:21: warning: variable 'common' set but not used [-Wunused-but-set-variable] struct common_obj *common; ^~~~~~ Signed-off-by: Mauro Carvalho Chehab

[media] davinci: vpif: adaptions for DT support

2017-06-20T12:05:37Z

The davinci VPIF is a single hardware block, but the existing driver is broken up into a common library (vpif.c), output (vpif_display.c) and intput (vpif_capture.c). When migrating to DT, to better model the hardware, and because registers, interrupts, etc. are all common,it was decided to have a single VPIF hardware node[1]. Because davinci uses legacy, non-DT boot on several SoCs still, the platform_drivers need to remain. But they are also needed in DT boot. Since there are no DT nodes for the display/capture parts in DT boot (there is a single node for the parent/common device) we need to create platform_devices somewhere to instantiate the platform_drivers. When VPIF display/capture are needed for a DT boot, the VPIF node will have endpoints defined for its subdevs. Therefore, vpif_probe() checks for the presence of endpoints, and if detected manually creates the platform_devices for the display and capture platform_drivers. [1] Documentation/devicetree/bindings/media/ti,da850-vpif.txt Signed-off-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] davinci: Switch from V4L2 OF to V4L2 fwnode

2017-06-08T15:34:16Z

The DaVinci VPIF capture driver V4L2 OF support was added after the V4L2 OF framework got removed. Switch VPIF capture driver to V4L2 fwnode. Signed-off-by: Sakari Ailus

[media] davinci: vpif_capture: cleanup raw camera support

2017-06-07T15:19:22Z

The current driver has a handful of hard-coded assumptions based on its primary use for capture of video signals. Cleanup those assumptions, and also query the subdev for format information and use that if available. Tested with 10-bit raw bayer input (SGRBG10) using the aptina,mt9v032 sensor, and also tested that composite video input still works from ti,tvp514x decoder. Both tests done on the da850-evm board with the add-on UI board. NOTE: Will need further testing for other sensors with different bus formats. Signed-off-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] davinci: vpif_capture: get subdevs from DT when available

2017-06-07T15:17:12Z

Enable getting of subdevs from DT ports and endpoints. The _get_pdata() function was larely inspired by (i.e. stolen from) am437x-vpfe.c Signed-off-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] davinci: vpif_capture: drop compliance hack

2017-06-07T15:15:56Z

Capture driver silently overrides pixel format with a hack (according to the comments) to pass v4l2 compliance tests. This isn't needed for normal functionality, and works for composite video and raw camera capture without. In addition, the hack assumes that it only supports raw capture with a single format (SBGGR8) which isn't true. VPIF can also capture 10- and 12-bit raw formats as well. Forthcoming patches will enable VPIF input with raw-camera support and has been tested with 10-bit format from the aptina,mt9v032 sensor. Any compliance failures should be fixed with a real fix. Signed-off-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] davinci: vpif_capture: fix default pixel format for BT.656/BT.1120 video

2017-06-06T19:49:23Z

For both BT.656 and BT.1120 video, the pixel format used by VPIF is Y/CbCr 4:2:2 in semi-planar format (Luma in one plane and Chroma in another). This corresponds to NV16 pixel format. This is documented in section 36.2.3 of OMAP-L138 Technical Reference Manual, SPRUH77A. The VPIF driver incorrectly sets the default format to V4L2_PIX_FMT_YUV422P. Fix it. Reported-by: Alejandro Hernandez Signed-off-by: Sekhar Nori Acked-by: Kevin Hilman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] media: vpif: use a configurable i2c_adapter_id for vpif display

2017-03-22T14:55:56Z

The vpif display driver uses a static i2c adapter ID of 1 but on the da850-evm board in DT boot mode the i2c adapter ID is actually 0. Make the adapter ID configurable like it already is for vpif capture. Signed-off-by: Bartosz Golaszewski Acked-by: Kevin Hilman Acked-by: Lad, Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab