summaryrefslogtreecommitdiff
path: root/drivers/media/i2c/ov5640.c
AgeCommit message (Collapse)AuthorFilesLines
2022-08-16i2c: Make remove callback return voidUwe Kleine-König1-3/+1
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-07-08media: ov5640: Move format mux config in formatJacopo Mondi1-116/+117
The image format produced by the sensor is controlled by two registers, whose values computation is open coded in ov5640_set_framefmt(). As we have a list of formats already, move the OV5640_REG_FORMAT_CONTROL00 and OV5640_REG_ISP_FORMAT_MUX_CTRL register values to the static list of formats instead of open coding it. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Split DVP and CSI-2 formatsJacopo Mondi1-36/+90
The format enumeration list is shared between CSI-2 and DVP modes. This lead to the enumeration of unsupported format variants in both modes. Separate the list of DVP and CSI-2 formats and create helpers to access the correct one. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Adjust format to bpp in s_fmtJacopo Mondi1-0/+12
The ov5640 driver supports different sizes for different mbus_codes. In particular: - 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720) Adjust the image sizes according to the above constraints. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Restrict sizes to mbus codeJacopo Mondi1-3/+17
The ov5640 driver supports different sizes for different mbus_codes. In particular: - 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720) Restrict the frame sizes enumerations to the above constraints. While at it, make sure the fse->mbus_code parameter is valid, and return -EINVAL if it's not. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add BGR888 formatJacopo Mondi1-0/+9
Add support for BGR888 image format. No existing media bus codes describe exactly the way data is transferred on the CSI-2 bus. This is not a new issue, the CSI-2 YUV422 8-bit format is described by MEDIA_BUS_FMT_UYVY8_1X16 which is an arbitrary convention and not an exact match. Use the MEDIA_BUS_FMT_BGR888_1X24 to follow the same convention, based on the order in which bits are transmitted over the CSI-2 bus when producing images in RGB24 format. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add RGB565_1X16 formatJacopo Mondi1-0/+5
The driver already supports the 2X8_[LE|BE] variants of RGB565 formats. As for CSI-2 the 2X8 variants do not apply, add RGB565_1X16 variant with little-endian ordering of components as required by the CSI-2 specifications. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Register device propertiesJacopo Mondi1-17/+12
Parse the device properties and register the rotation and orientation V4L2 controls using v4l2_ctrl_new_fwnode_properties(). Remove the open-coded parsing of the rotation property and assume the DTS is correct is providing either <0> or <180> as possible rotations. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Implement get_selectionJacopo Mondi1-0/+46
Implement the get_selection pad operation for the OV5640 sensor driver. The supported targets report the sensor's native size, the active pixel array size and the analog crop rectangle from which the image is produced. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Implement init_cfgJacopo Mondi1-10/+25
Implement the init_cfg pad operation to initialize the subdev state format to the default one. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Change CSI-2 timings to comply with FPSJacopo Mondi1-15/+15
Now that the frame duration can be controlled by tuning the VBLANK duration in CSI-2 mode, fix all modes definitions to comply with the reported FPS. All modes run at 30 FPS except for full-resolution mode 2592x1944 which runs at 15FPS. Tested on a 2 data lanes setup in UYVY and RGB565 modes in CSI-2 mode. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Remove frame rate check from find_mode()Jacopo Mondi1-10/+9
The current implementation of ov5640_find_mode() fails if the frame rate programmed with s_frame_interval doesn't match the maximum frame rate for the current mode. This causes issues when moving from one mode with higher FPS to another one which only supports a lower FPS range with tools like media-ctl. It also forces users that do not use s_frame_interval(), but rather configure blankings explicitly, to adjust the programmed FPS range to avoid failures. For this reason, remove the FPS check from ov5640_find_mode() and only perform it at s_frame_interval() time. 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@kernel.org>
2022-07-08media: ov5640: Adjust vblank with s_frame_intervalHugues Fruchet1-16/+42
Adjust the vertical blanking when s_frame_interval is used. s_frame_interval allows to set a fixed frame rate, which gets stored as the sensor's current one. When a new mode is applied, the current frame rate is reset to the mode's default one. In order to correctly report the currently configured vertical blanking for s_frame_interval users, verify that the desired frame rate has not been changed. If that's the case, compute the correct blanking value and reflect it through the corresponding v4l2 control. Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> 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@kernel.org>
2022-07-08media: ov5640: Add VBLANK controlJacopo Mondi1-0/+52
Add the VBLANK control which allows to select the duration of the frame vertical blankings and allows to control the framerate. The VBLANK control also modifies the exposure time range, which cannot exceed the maximum frame length. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add HBLANK controlJacopo Mondi1-0/+16
Add the HBLANK control as read-only. The hblank value is fixed in the mode definition and is updated everytime a new format is applied. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Remove ov5640_mode_init_dataJacopo Mondi1-57/+10
The ov5640_mode_init_data is a fictional sensor more which is used to program the initial sensor settings. It is only used to initialize the sensor and can be replaced it with a throw-away mode which just wraps the register table. Also rename the register table to drop the format from the name to make it clear an actual sensor mode has to be applied after the initial programming. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Remove duplicated mode settingsJacopo Mondi1-105/+15
The register tables for all resolutions smaller than 720p are now identical. Remove the duplicated ones and create a single ov5640_setting_low_res[] register table. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Re-sort per-mode register tablesJacopo Mondi1-9/+9
The per-mode register tables are not sorted by size. Fix it. Cosmetic change only. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Provide timings accessorJacopo Mondi1-5/+11
Provide a function to shortcut access to the correct timings definition to avoid repeating the same pattern when accessing the sensor timings. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Split DVP and CSI-2 timingsJacopo Mondi1-162/+420
Separate the timings for the DVP mode from the timings for the CSI-2 mode in the ov5640 modes definition. The CSI-2 timings will deviate from the DVP ones as the clock tree is calculated differently. In CSI-2 mode change the analog crop rectangles as the OV5640 pixel array is composed as: - vertically: 16 dummy columns, 2592 valid ones and 16 dummy columns for a total of 2624 columns - horizontally: 8 optical black lines, 6 dummy ones, 1944 valid and 6 dummies for a total of 1964 lines Adjust the analog crop rectangle in CSI-2 mode to: - Skip the first 16 dummy columns - Skip the first 14 black/dummy lines - Pass the whole valid pixel array size to the ISP for all modes except 1024x768, 720p and 1080p which are obtained by cropping the valid pixel array. Tested in RGB565, UYVY and RGB888 modes in CSI-2 mode. 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@kernel.org>
2022-07-08media: ov5640: Fix 720x480 in RGB888 modeJacopo Mondi1-1/+1
Adjust the left crop of 720x480 to enable capture in RGB888 format, which is otherwise broken. The 56 pixels alignment has been copied from the 720x576 mode. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Rework timings programmingJacopo Mondi1-145/+300
The current definition of a sensor mode defines timings as follows: - hact, vact: Visible width and height - htot, vtot: Total sizes including blankings This makes difficult to clearly separate the visible sizes from the blankings and to make the vertical blanking programmable. Rework the sensor modes sizes definition to: - Report the analog crop sizes - Report the visible crop size - Report the total pixels per line as HBLANK is fixed - Report the VBLANK value to make it programmable Also modify the ov5640_set_timings() function to program all the windowing registers are remove them from the per-mode register-value tables. Do not change the timing values from the ones reported in the register tables to maintain bisectability. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Rework CSI-2 clock treeJacopo Mondi1-100/+96
Re-work the ov5640_set_mipi_pclk() function to calculate the PLL configuration using the pixel_rate and link_freq values set at s_fmt time. Rework the DVP clock mode settings to calculate the pixel clock internally and remove the assumption on the 16bpp format. Tested in MIPI CSI-2 mode with 1 and 2 data lanes with: - all the sensor supported resolutions in UYVY, RGB565 and MJPEG formats. - resolutions >= 1280x720 in RAW Bayer format. - resolutions < 1280x720 in RGB888 format. [Rework pclk_period and link_freq computation] Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Update pixel_rate and link_freqJacopo Mondi1-2/+83
After having set a new format re-calculate the pixel_rate and link_freq control values and update them when in MIPI mode. Take into account the limitation of the link frequency having to be strictly smaller than 1GHz when computing the desired link_freq, and adjust the resulting pixel_rate acounting for the clock tree configuration. [Adjust link_freq calculation] Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add LINK_FREQ controlJacopo Mondi1-0/+26
Add the V4L2_CID_LINK_FREQ control to the ov5640 driver. Make the control read-only for the moment. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Associate bpp with formatsJacopo Mondi1-15/+48
Associate the bit depth to each format supported by the sensor. The bpp will be used to calculate the line length. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add ov5640_is_csi2() functionJacopo Mondi1-3/+8
Checking if the sensor is used in DVP or MIPI CSI-2 mode is a repeated pattern which is about to be repeated more often. Provide an inline function to shortcut that. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5604: Re-arrange modes definitionJacopo Mondi1-60/+81
The array of supported modes is close to unreadable. Re-arrange it giving it some room to breath. Cosmetic change only. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-07-08media: ov5640: Add pixel rate to modesJacopo Mondi1-3/+41
Add to each mode supported by the sensor the ideal pixel rate, as defined by Table 2.1 in the chip manual. The ideal pixel rate will be used to compute the MIPI CSI-2 clock tree. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Adam Ford <aford173@gmail.com> #imx8mm-beacon-kit Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-02-23media: ov5640: Fix set format, v4l2_mbus_pixelcode not updatedMirela Rabulea1-7/+7
In ov5640_set_fmt, pending_fmt_change will always be false, because the sensor format is saved before comparing it with the previous format: fmt = &sensor->fmt;... *fmt = *mbus_fmt;... if (mbus_fmt->code != sensor->fmt.code) sensor->pending_fmt_change = true; This causes the sensor to capture with the previous pixelcode. Also, changes might happen even for V4L2_SUBDEV_FORMAT_TRY, so fix that. Basically, revert back to the state before commit 071154499193 ("media: ov5640: Fix set format regression") as it was more clear, and then update format even when pixelcode does not change, as resolution might change. Fixes: 071154499193 ("media: ov5640: Fix set format regression") Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame interval is unchanged") Fixes: fb98e29ff1ea5 ("media: ov5640: fix mode change regression") Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Acked-by: Hugues Fruchet <hugues.fruchet@st.com> Tested-by: Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2021-08-04media: ov5640: Complement yuv mbus formats with their 1X16 versionsXavier Roumegue1-0/+4
According to media bus pixel codes definition, data formats on serial busses should be described with one bus sample per pixel. Documentation/userspace-api/media/v4l/subdev-formats.rst states: "The media bus pixel codes document parallel formats. Should the pixel data be transported over a serial bus, the media bus pixel code that describes a parallel format that transfers a sample on a single clock cycle is used. For instance, both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are used on parallel busses for transferring an 8 bits per sample BGR data, whereas on serial busses the data in this format is only referred to using MEDIA_BUS_FMT_BGR888_1X24. This is because there is effectively only a single way to transport that format on the serial busses." Some MIPI CSI receivers strictly obey this definition and declare support for only *1X_* formats. Hence, complement the supported media bus formats with their 1X16 versions (currently applicable to yuyv, uyvy) to enhance interoperability with CSI receivers. Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-06-17media: v4l2-subdev: add subdev-wide state structTomi Valkeinen1-7/+7
We have 'struct v4l2_subdev_pad_config' which contains configuration for a single pad used for the TRY functionality, and an array of those structs is passed to various v4l2_subdev_pad_ops. I was working on subdev internal routing between pads, and realized that there's no way to add TRY functionality for routes, which is not pad specific configuration. Adding a separate struct for try-route config wouldn't work either, as e.g. set-fmt needs to know the try-route configuration to propagate the settings. This patch adds a new struct, 'struct v4l2_subdev_state' (which at the moment only contains the v4l2_subdev_pad_config array) and the new struct is used in most of the places where v4l2_subdev_pad_config was used. All v4l2_subdev_pad_ops functions taking v4l2_subdev_pad_config are changed to instead take v4l2_subdev_state. The changes to drivers/media/v4l2-core/v4l2-subdev.c and include/media/v4l2-subdev.h were written by hand, and all the driver changes were done with the semantic patch below. The spatch needs to be applied to a select list of directories. I used the following shell commands to apply the spatch: dirs="drivers/media/i2c drivers/media/platform drivers/media/usb drivers/media/test-drivers/vimc drivers/media/pci drivers/staging/media" for dir in $dirs; do spatch -j8 --dir --include-headers --no-show-diff --in-place --sp-file v4l2-subdev-state.cocci $dir; done Note that Coccinelle chokes on a few drivers (gcc extensions?). With minor changes we can make Coccinelle run fine, and these changes can be reverted after spatch. The diff for these changes is: For drivers/media/i2c/s5k5baf.c: @@ -1481,7 +1481,7 @@ static int s5k5baf_set_selection(struct v4l2_subdev *sd, &s5k5baf_cis_rect, v4l2_subdev_get_try_crop(sd, cfg, PAD_CIS), v4l2_subdev_get_try_compose(sd, cfg, PAD_CIS), - v4l2_subdev_get_try_crop(sd, cfg, PAD_OUT) + v4l2_subdev_get_try_crop(sd, cfg, PAD_OUT), }; s5k5baf_set_rect_and_adjust(rects, rtype, &sel->r); return 0; For drivers/media/platform/s3c-camif/camif-capture.c: @@ -1230,7 +1230,7 @@ static int s3c_camif_subdev_get_fmt(struct v4l2_subdev *sd, *mf = camif->mbus_fmt; break; - case CAMIF_SD_PAD_SOURCE_C...CAMIF_SD_PAD_SOURCE_P: + case CAMIF_SD_PAD_SOURCE_C: /* crop rectangle at camera interface input */ mf->width = camif->camif_crop.width; mf->height = camif->camif_crop.height; @@ -1332,7 +1332,7 @@ static int s3c_camif_subdev_set_fmt(struct v4l2_subdev *sd, } break; - case CAMIF_SD_PAD_SOURCE_C...CAMIF_SD_PAD_SOURCE_P: + case CAMIF_SD_PAD_SOURCE_C: /* Pixel format can be only changed on the sink pad. */ mf->code = camif->mbus_fmt.code; mf->width = crop->width; The semantic patch is: // <smpl> // Change function parameter @@ identifier func; identifier cfg; @@ func(..., - struct v4l2_subdev_pad_config *cfg + struct v4l2_subdev_state *sd_state , ...) { <... - cfg + sd_state ...> } // Change function declaration parameter @@ identifier func; identifier cfg; type T; @@ T func(..., - struct v4l2_subdev_pad_config *cfg + struct v4l2_subdev_state *sd_state , ...); // Change function return value @@ identifier func; @@ - struct v4l2_subdev_pad_config + struct v4l2_subdev_state *func(...) { ... } // Change function declaration return value @@ identifier func; @@ - struct v4l2_subdev_pad_config + struct v4l2_subdev_state *func(...); // Some drivers pass a local pad_cfg for a single pad to a called function. Wrap it // inside a pad_state. @@ identifier func; identifier pad_cfg; @@ func(...) { ... struct v4l2_subdev_pad_config pad_cfg; + struct v4l2_subdev_state pad_state = { .pads = &pad_cfg }; <+... ( v4l2_subdev_call | sensor_call | isi_try_fse | isc_try_fse | saa_call_all ) (..., - &pad_cfg + &pad_state ,...) ...+> } // If the function uses fields from pad_config, access via state->pads @@ identifier func; identifier state; @@ func(..., struct v4l2_subdev_state *state , ...) { <... ( - state->try_fmt + state->pads->try_fmt | - state->try_crop + state->pads->try_crop | - state->try_compose + state->pads->try_compose ) ...> } // If the function accesses the filehandle, use fh->state instead @@ struct v4l2_subdev_fh *fh; @@ - fh->pad + fh->state @@ struct v4l2_subdev_fh fh; @@ - fh.pad + fh.state // Start of vsp1 specific @@ @@ struct vsp1_entity { ... - struct v4l2_subdev_pad_config *config; + struct v4l2_subdev_state *config; ... }; @@ symbol entity; @@ vsp1_entity_init(...) { ... entity->config = - v4l2_subdev_alloc_pad_config + v4l2_subdev_alloc_state (&entity->subdev); ... } @@ symbol entity; @@ vsp1_entity_destroy(...) { ... - v4l2_subdev_free_pad_config + v4l2_subdev_free_state (entity->config); ... } @exists@ identifier func =~ "(^vsp1.*)|(hsit_set_format)|(sru_enum_frame_size)|(sru_set_format)|(uif_get_selection)|(uif_set_selection)|(uds_enum_frame_size)|(uds_set_format)|(brx_set_format)|(brx_get_selection)|(histo_get_selection)|(histo_set_selection)|(brx_set_selection)"; symbol config; @@ func(...) { ... - struct v4l2_subdev_pad_config *config; + struct v4l2_subdev_state *config; ... } // End of vsp1 specific // Start of rcar specific @@ identifier sd; identifier pad_cfg; @@ rvin_try_format(...) { ... - struct v4l2_subdev_pad_config *pad_cfg; + struct v4l2_subdev_state *sd_state; ... - pad_cfg = v4l2_subdev_alloc_pad_config(sd); + sd_state = v4l2_subdev_alloc_state(sd); <... - pad_cfg + sd_state ...> - v4l2_subdev_free_pad_config(pad_cfg); + v4l2_subdev_free_state(sd_state); ... } // End of rcar specific // Start of rockchip specific @@ identifier func =~ "(rkisp1_rsz_get_pad_fmt)|(rkisp1_rsz_get_pad_crop)|(rkisp1_rsz_register)"; symbol rsz; symbol pad_cfg; @@ func(...) { + struct v4l2_subdev_state state = { .pads = rsz->pad_cfg }; ... - rsz->pad_cfg + &state ... } @@ identifier func =~ "(rkisp1_isp_get_pad_fmt)|(rkisp1_isp_get_pad_crop)"; symbol isp; symbol pad_cfg; @@ func(...) { + struct v4l2_subdev_state state = { .pads = isp->pad_cfg }; ... - isp->pad_cfg + &state ... } @@ symbol rkisp1; symbol isp; symbol pad_cfg; @@ rkisp1_isp_register(...) { + struct v4l2_subdev_state state = { .pads = rkisp1->isp.pad_cfg }; ... - rkisp1->isp.pad_cfg + &state ... } // End of rockchip specific // Start of tegra-video specific @@ identifier sd; identifier pad_cfg; @@ __tegra_channel_try_format(...) { ... - struct v4l2_subdev_pad_config *pad_cfg; + struct v4l2_subdev_state *sd_state; ... - pad_cfg = v4l2_subdev_alloc_pad_config(sd); + sd_state = v4l2_subdev_alloc_state(sd); <... - pad_cfg + sd_state ...> - v4l2_subdev_free_pad_config(pad_cfg); + v4l2_subdev_free_state(sd_state); ... } @@ identifier sd_state; @@ __tegra_channel_try_format(...) { ... struct v4l2_subdev_state *sd_state; <... - sd_state->try_crop + sd_state->pads->try_crop ...> } // End of tegra-video specific // </smpl> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-04-06media: v4l: fwnode: Rename v4l2_async_register_subdev_sensor_commonSakari Ailus1-1/+1
Rename v4l2_async_register_subdev_sensor_common as v4l2_async_register_subdev_sensor. This is a part of the effort to make the long names present in V4L2 fwnode and async frameworks shorter. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: ov5640: fix support of BT656 bus modeHugues Fruchet1-37/+45
Fix PCLK polarity not being taken into account. Add comments about BT656 register control. Remove useless ov5640_set_stream_bt656() function. Refine comments about MIPI IO register control. Fixes: 4039b03720f7 ("media: i2c: ov5640: Add support for BT656 mode") Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-16media: ov5640: add support of 160x120 resolutionHugues Fruchet1-1/+25
Add support of 160x120 resolution. Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Fail probe on unsupported bus_typeLad Prabhakar1-0/+7
Fail probe if unsupported bus_type is detected. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-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>
2020-09-10media: i2c: ov5640: Add support for BT656 modeLad Prabhakar1-12/+34
Enable support for BT656 mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-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>
2020-09-10media: i2c: ov5640: Configure HVP lines in s_power callbackLad Prabhakar1-65/+58
Configure HVP lines in s_power callback instead of configuring everytime in ov5640_set_stream_dvp(). Alongside also disable MIPI in DVP mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-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>
2020-09-10media: i2c: ov5640: Enable data pins on poweron for DVP modeLad Prabhakar1-33/+40
During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed. To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected) Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-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>
2020-09-10media: i2c: ov5640: Separate out mipi configuration from s_powerLad Prabhakar1-56/+60
In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-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>
2020-09-10media: i2c: ov5640: Remain in power down for DVP mode unless streamingLad Prabhakar1-3/+16
Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-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>
2020-09-01media: ov5640: Correct Bit Div register in clock tree diagramPaul Kocialkowski1-1/+1
Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-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>
2020-08-29media: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+1
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14media: ov5640: fix use of destroyed mutexTomi Valkeinen1-2/+2
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting in the use of the destroyed mutex. Fix this by calling moving the mutex_destroy() to the end of the cleanup sequence, as there's no need to destroy the mutex as early as possible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-01-04media: ov5640: Fix check for PLL1 exceeding max allowed rateAdam Ford1-1/+1
The variable _rate is by ov5640_compute_sys_clk() which returns zero if the PLL exceeds 1GHz. Unfortunately, the check to see if the max PLL1 output is checking 'rate' and not '_rate' and 'rate' does not ever appear to be 0. This patch changes the check against the returned value of '_rate' to determine if the PLL1 output exceeds 1GHz. Fixes: aa2882481cad ("media: ov5640: Adjust the clock based on the expected rate") Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-01-04media: ov5640: Put max framerate into table and simplify checkAdam Ford1-17/+22
Currently the various modes are placed into a table, but when ov5640_find_mode is called, it has to double check whether or not the requested framerate is tolerated by the mode. The determination is based on checking hact, vact, and frame rate. Only 640x480 is allowed at 60fps and QSXGA is limited to 15fps, but as the number of permitted frame rates change, this will begin to add more and more complexity to the check. This patch simplifies the check by adding the max framerate allowed for each mode into the table of modes. It then compares the requested framerate to the max permitted in the mode's table. This reduces the number of comparisions to one down from three at run-time. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2019-10-25media: ov5640: Make 2592x1944 mode only available at 15 fpsBenoit Parrot1-0/+5
The sensor data sheet clearly state that 2592x1944 only works at 15 fps make sure we don't try to miss configure the pll out of acceptable range. Signed-off-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-25media: ov5640: Fix 1920x1080 mode to remove extra enable/disableBenoit Parrot1-2/+1
In the 1920x1080 register array an extra pair of reset ctrl disable re-enable was causing unwanted init delays. Signed-off-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-25media: ov5640: add PIXEL_RATE controlBenoit Parrot1-2/+23
Add v4l2 controls to report the pixel rates of each mode. This is needed by some CSI2 receiver in order to perform proper DPHY configuration. Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-08-15media: ov5640: Add support for flash and lens devicesLuca Weiss1-1/+1
Parse async sub-devices related to the sensor by switching the async sub-device registration function. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-10 23:52:05 +0300