kernel/linux.git/drivers/staging/media, branch v4.19.112

media: imx: work around false-positive warning, again

2019-11-20T17:47:16+00:00

[ Upstream commit 8d1a4817cce1b15b4909f0e324a4f5af5952da67 ] A warning that I thought to be solved by a previous patch of mine has resurfaced with gcc-8: media/imx/imx-media-csi.c: In function 'csi_link_validate': media/imx/imx-media-csi.c:1025:20: error: 'upstream_ep' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:1026:24: error: 'upstream_ep.bus_type' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:127:19: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c: In function 'csi_enum_mbus_code': media/imx/imx-media-csi.c:132:9: error: '*((void *)&upstream_ep+12)' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:132:48: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] I spent some more time digging in this time, and think I have a better fix, bailing out of the function that either initializes or errors out here, which simplifies the code enough for gcc to figure out what is going on. The earlier partial workaround can be removed now, as the new workaround is better. Fixes: 890f27693f2a ("media: imx: work around false-positive warning") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: imx: mipi csi-2: Don't fail if initial state times-out

2019-10-05T11:09:43+00:00

[ Upstream commit 0d5078c7172c46db6c58718d817b9fcf769554b4 ] Not all sensors will be able to guarantee a proper initial state. This may be either because the driver is not properly written, or (probably unlikely) because the hardware won't support it. While the right solution in the former case is to fix the sensor driver, the real world not always allows right solutions, due to lack of available documentation and support on these sensors. Let's relax this requirement, and allow the driver to support stream start, even if the sensor initial sequence wasn't the expected. Also improve the warning message to better explain the problem and provide a hint that the sensor driver needs to be fixed. Signed-off-by: Ezequiel Garcia Signed-off-by: Fabio Estevam Reviewed-by: Steve Longerbeam Reviewed-by: Philipp Zabel Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: staging: media: davinci_vpfe: - Fix for memory leak if decoder initialization fails.

2019-07-26T07:14:02+00:00

[ Upstream commit 6995a659101bd4effa41cebb067f9dc18d77520d ] Fix to avoid possible memory leak if the decoder initialization got failed.Free the allocated memory for file handle object before return in case decoder initialization fails. Signed-off-by: Shailendra Verma Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: staging: davinci_vpfe: disallow building with COMPILE_TEST

2019-05-31T13:46:32+00:00

[ Upstream commit 49dc762cffd8305a861ca649e82dc5533b3e3344 ] The driver should really call dm365_isif_setup_pinmux() through a callback, but uses a hack to include a davinci specific machine header file when compile testing instead. This works almost everywhere, but not on the ARM omap1 platform, which has another header named mach/mux.h. This causes a build failure: drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: implicit declaration of function 'davinci_cfg_reg' [-Werror,-Wimplicit-function-declaration] davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:2: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] drivers/staging/media/davinci_vpfe/dm365_isif.c:2028:18: error: use of undeclared identifier 'DM365_VIN_CAM_WEN' davinci_cfg_reg(DM365_VIN_CAM_WEN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2029:18: error: use of undeclared identifier 'DM365_VIN_CAM_VD' davinci_cfg_reg(DM365_VIN_CAM_VD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2030:18: error: use of undeclared identifier 'DM365_VIN_CAM_HD' davinci_cfg_reg(DM365_VIN_CAM_HD); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2031:18: error: use of undeclared identifier 'DM365_VIN_YIN4_7_EN' davinci_cfg_reg(DM365_VIN_YIN4_7_EN); ^ drivers/staging/media/davinci_vpfe/dm365_isif.c:2032:18: error: use of undeclared identifier 'DM365_VIN_YIN0_3_EN' davinci_cfg_reg(DM365_VIN_YIN0_3_EN); ^ 7 errors generated. Exclude omap1 from compile-testing, under the assumption that all others still work. Fixes: 4907c73deefe ("media: staging: davinci_vpfe: allow building with COMPILE_TEST") Signed-off-by: Arnd Bergmann Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: imx: Clear fwnode link struct for each endpoint iteration

2019-05-25T16:23:28+00:00

commit 107927fa597c99eaeee4f51865ca0956ec71b6a2 upstream. In imx_media_create_csi_of_links(), the 'struct v4l2_fwnode_link' must be cleared for each endpoint iteration, otherwise if the remote port has no "reg" property, link.remote_port will not be reset to zero. This was discovered on the i.MX53 SMD board, since the OV5642 connects directly to ipu1_csi0 and has a single source port with no "reg" property. Fixes: 621b08eabcddb ("media: staging/imx: remove static media link arrays") Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: imx: csi: Allow unknown nearest upstream entities

2019-05-25T16:23:27+00:00

commit 904371f90b2c0c749a5ab75478c129a4682ac3d8 upstream. On i.MX6, the nearest upstream entity to the CSI can only be the CSI video muxes or the Synopsys DW MIPI CSI-2 receiver. However the i.MX53 has no CSI video muxes or a MIPI CSI-2 receiver. So allow for the nearest upstream entity to the CSI to be something other than those. Fixes: bf3cfaa712e5c ("media: staging/imx: get CSI bus type from nearest upstream entity") Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: imx: csi: Stop upstream before disabling IDMA channel

2019-03-23T19:10:12+00:00

commit 4bc1ab41eee9d02ad2483bf8f51a7b72e3504eba upstream. Move upstream stream off to just after receiving the last EOF completion and disabling the CSI (and thus before disabling the IDMA channel) in csi_stop(). For symmetry also move upstream stream on to beginning of csi_start(). Doing this makes csi_s_stream() more symmetric with prp_s_stream() which will require the same change to fix a hard lockup. Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: imx: csi: Disable CSI immediately after last EOF

2019-03-23T19:10:12+00:00

commit 2e0fe66e0a136252f4d89dbbccdcb26deb867eb8 upstream. Disable the CSI immediately after receiving the last EOF before stream off (and thus before disabling the IDMA channel). Do this by moving the wait for EOF completion into a new function csi_idmac_wait_last_eof(). This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on: while true; do v4l2-ctl -d4 --stream-mmap --stream-count=3; done Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset. The lockup occurs when disabling the IDMA channel at stream off. Disabling the CSI before disabling the IDMA channel appears to be a reliable fix for the hard lockup. Fixes: 4a34ec8e470cb ("[media] media: imx: Add CSI subdev driver") Reported-by: Gaël PORTAY Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: imx: prpencvf: Stop upstream before disabling IDMA channel

2019-03-23T19:10:12+00:00

commit a19c22677377b87e4354f7306f46ad99bc982a9f upstream. Upstream must be stopped immediately after receiving the last EOF and before disabling the IDMA channel. This can be accomplished by moving upstream stream off to just after receiving the last EOF completion in prp_stop(). For symmetry also move upstream stream on to end of prp_start(). This fixes a complete system hard lockup on the SabreAuto when streaming from the ADV7180, by repeatedly sending a stream off immediately followed by stream on: while true; do v4l2-ctl -d1 --stream-mmap --stream-count=3; done Eventually this either causes the system lockup or EOF timeouts at all subsequent stream on, until a system reset. The lockup occurs when disabling the IDMA channel at stream off. Stopping the video data stream entering the IDMA channel before disabling the channel itself appears to be a reliable fix for the hard lockup. Fixes: f0d9c8924e2c3 ("[media] media: imx: Add IC subdev drivers") Reported-by: Gaël PORTAY Tested-by: Gaël PORTAY Signed-off-by: Steve Longerbeam Cc: stable@vger.kernel.org # for 4.13 and up Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: staging/media/mt9t031/Kconfig: remove bogus entry

2018-09-12T10:44:01+00:00

The 'config SOC_CAMERA_IMX074' is a copy-and-paste error and should be removed. This Kconfig is for mt9t031 only. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab