- 12 Jan, 2021 40 commits
-
-
Ezequiel Garcia authored
No locking is needed to call video_unregister_device(). Drop it. Also, drop the superfluous video_is_registered() call, which is done by video_unregister_device(), and re-order media_entity_cleanup() and video_unregister_device() calls. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ezequiel Garcia authored
The csc/scaler device private struct is released by ipu_csc_scaler_video_device_release(), which can be called by video_unregister_device() if there are no users of the underlying struct video device. Therefore, the mutex can't be held when calling video_unregister_device() as its memory may be freed by it, leading to a kernel oops. Fortunately, the fix is quite simple as no locking is needed when calling video_unregister_device(): v4l2-core already has its own internal locking, and the structures are also properly refcounted. Fixes: a8ef0488 ("media: imx: add csc/scaler mem2mem device") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ezequiel Garcia authored
The csc/scaler device pointer (imxmd->m2m_vdev) is assigned after the imx media device v4l2-async probe completes, therefore we need to check if the device is non-NULL before trying to unregister it. This can be the case if the non-completed imx media device is unbinded (or the driver is removed), leading to a kernel oops. Fixes: a8ef0488 ("media: imx: add csc/scaler mem2mem device") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Martin Kepplinger authored
As described in NXPs' linux tree, the imx8m SoC includes the same CSI bridge hardware that is part of imx7d. We should be able to use the "fsl,imx7-csi" driver for imx8m directly. Since ipuv3 is not relevant for imx8m, move that dependency to VIDEO_IMX_CSI. That makes VIDEO_IMX7_CSI available to support imx8m too. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
struct device is used in ccs-data.h but no definition is included. Add a forward definition. Also ccs-data.c includes linux/types.h but this is already included in ccs-data.h which ccs-data.c includes. Do don't include linux/types.h in ccs-data.c. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
This reverts commit b3c0115e. As per Documentation/process/license-rules.rst "GPL v2" exists only for historical reasons and has the same meaning as "GPL". So revert this patch. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The preferred integer types in the kernel are the Linux specific ones, switch from standard C types to u32 and alike. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The preferred integer types in the kernel are the Linux specific ones, switch from standard C types to u32 and alike. The patch has been produced with the following Coccinelle spatch, with few alignment adjustments: @@ typedef uint32_t; typedef u32; @@ - uint32_t + u32 @@ typedef uint16_t; typedef u16; @@ - uint16_t + u16 @@ typedef uint8_t; typedef u8; @@ - uint8_t + u8 Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Include existing CCS PLL calculator kerneldoc documentation to the documentation build. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
CCS supports three variants of PHY timing control, auto, UI based and manual. The driver previously assumed UI based control that requires updating the link rate to the sensor. Now default to automatic control instead, and only write the link rate to the sensor in UI mode. If neither auto or UI control is supported, return an error in probe. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The driver depends on the external clock frequency. Add a sanity check for the frequency, by returning an error from probe if it's zero. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
A CCS compliant device requires a delay before the first I²C transaction after pulling xshutdown up or starting the external clock. This is what the driver does. However, if neither is actually there, there's no need for the delay. This also has the effect of removing an unnecessary delay on ACPI systems where ACPI is responsible for the power-up sequence. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Verify the software reset has been completed until proceeding. The spec does not guarantee a delay but presumably 100 ms should be enough. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The driver always used software reset after the sensor's power sequence that includes a hardware reset if we have a reset GPIO. Do not use software reset if we just brought the sensor up from hardware reset state. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The sensor's address was changed before resetting and changing the address again. Don't do it before reset as it's useless. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Get the first endpoint from port 0 instead of the next one, whatever it might be. There are no other ports so there's no functional change. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add controls for supporting lens shading correction, including colour shading and luminance correction level. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add V4L2 controls for controlling CCS lens shading correction as well as conveying its capabilities. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Also print out MSR registers written to the sensor. This isn't entirely optimal as the debug strings are produced even if they're not used but that isn't really a grave issue --- the I²C bus is very slow anyway. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The CCS spec defines an alternative implementation for global analogue gain. Add support for that in the driver. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add two new controls for alternative analogue gain some CCS compliant camera sensors support. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add four controls for reading CCS analogue gain coefficients. The values are constants that are device specific. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add V4L2 controls for analogue gain constants required to control analogue gain. The values are device specific and thus need to be obtained from the driver. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add user documentation for the CCS driver. This includes e.g. sub-devices implemented by the driver. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Add a control base for CCS controls, and reserve 128 controls. Luckily these numbers are cheap. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Some devices do not implement analogue gain this way. Only add the control when a device does have the support. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
The analogue gain control was stored to the device specific struct but was never used. Remove it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
SMIA only has per-component digital gain. Add support for it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
CCS supports global (all-component) digital gain. Add support for it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ezequiel Garcia authored
Drivers don't need to explicitly call devm_{}_put on driver removal, as it's automatically called by the device driver resource management code. Fixes: aab7ed1c ("media: i2c: Add driver for Aptina MT9V111") Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Paul Kocialkowski authored
The OV8865 is a 8 Mpx CMOS image sensor producing 3264x2448 at 30 fps. Other modes (including some with sub-sampling) are available too. It outputs 10-bit bayer CFA data through a MIPI CSI-2 interface with up to 4 lanes supported. Some register initialisation sequences are still needed for this driver, as they cover registers for which no documentation is available. This work is based on the first version of the driver submitted by Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP. This version is a rewrite of the first version that matches the structure of the OV5648 driver, with explicit PLL configuration, all the necessary mode-specific fields, associatied registers and reduced static sequences. It was tested with the Banana Pi Camera Board v3 and the Banana Pi M3. Co-developed-by: Kévin L'hôpital <kevin.lhopital@bootlin.com> Signed-off-by: Kévin L'hôpital <kevin.lhopital@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Paul Kocialkowski authored
This introduces YAML bindings documentation for the OV8865 image sensor. Co-developed-by: Kévin L'hôpital <kevin.lhopital@bootlin.com> Signed-off-by: Kévin L'hôpital <kevin.lhopital@bootlin.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Paul Kocialkowski authored
The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2 in a one or two lane configuration. Most of the features of the hardware are supported, including: - Auto and manual exposition/gain - Auto and manual white balance - Horizontal and vertical flip - Test patterns But the following are still missing: - Debanding, based on power source frequency; - Exposition setting correlated to time units. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Paul Kocialkowski authored
This introduces YAML bindings documentation for the OV5648 image sensor. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Pavel Machek authored
Loop was useless as it would always exit on the first iteration. Fix it with right condition. Signed-off-by: Pavel Machek (CIP) <pavel@denx.de> Fixes: a86cf9b2 ("media: ipu3-cio2: Validate mbus format in setting subdev format") Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: stable@vger.kernel.org # v4.16 and up Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jacopo Mondi authored
The driver currently reports a single supported value for V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0, which is very risky, as userspace might accidentally use it as divider when calculating the time duration of a line. Fix this by using as minimum the only supported value when registering the control. Fixes: 5de35c9b ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
Document pratices of handling clocks in camera sensor drivers on both DT and ACPI. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Andy Shevchenko authored
According to the original code in the driver it was never assumed to work with big page sizes: unsigned short type followed by PAGE_SHIFT and PAGE_MASK which may be different on non-x86 architectures. Recently LKP found an issue on non-x86 architectures due to above mentioned limitations. Since Sakari acknowledges that it's not really useful to be able to compile this elsewhere, mark it x86 only. Fixes: a31d19f8 ("media: ipu3: allow building it with COMPILE_TEST on non-x86 archs") Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
kvmalloc() was used to allocate the temporary memory buffer that was used to contain both the IOCTL argument as well as a possible array argument that could have been large. Now that the two are separated, the IOCTL argument is known to be small in size. Use kmalloc to allocate it instead of kvmalloc. Similarly for releasing it. Suggested-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sakari Ailus authored
When an IOCTL with argument size larger than 128 that also used array arguments were handled, two memory allocations were made but alas, only the latter one of them was released. This happened because there was only a single local variable to hold such a temporary allocation. Fix this by adding separate variables to hold the pointers to the temporary allocations. Reported-by: Arnd Bergmann <arnd@kernel.org> Reported-by: syzbot+1115e79c8df6472c612b@syzkaller.appspotmail.com Fixes: d14e6d76 ("[media] v4l: Add multi-planar ioctl handling code") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-