- 08 Jul, 2022 40 commits
-
-
Hans de Goede authored
hmm_bo_get_page_info() is not used anywhere, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-17-hdegoede@redhat.comReviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans de Goede authored
Since the hmm-pool code has been removed this now always gets set to HMM_PAGE_TYPE_GENERAL, so just remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-16-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
ia_css_frame_map() has only one caller which passes a hardcoded 0 for the attribute argument, drop it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-15-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Since we have removed the hmm pools these are completely meaningless now. Link: https://lore.kernel.org/linux-media/20220615205037.16549-14-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Without pool support the (optional) debug logging done by these is not really meaningful, drop it all. Link: https://lore.kernel.org/linux-media/20220615205037.16549-13-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Since we never register any pools, this is all dead code, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-12-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
There are no callers of this code atm; and looking at the atomisp memory-management code if anything we want to make it simpler and not re-introduce use of these pools, so remove the pool code. Link: https://lore.kernel.org/linux-media/20220615205037.16549-11-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
These are no-ops, so lets remove them. Link: https://lore.kernel.org/linux-media/20220615205037.16549-10-hdegoede@redhat.comSigned-off-by:
-
Hans de Goede authored
Drop the ATOMISP_MAP_FLAG_CONTIGUOUS hmm_alloc flag. After the contiguous flag removal done in previous patches in this series it is never set. And hmm_alloc already did a WARN_ON on the flag and otherwise ignored it, proving that contiguous support was already never used. Link: https://lore.kernel.org/linux-media/20220615205037.16549-9-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Drop the contiguous flag from struct ia_css_frame, it is always false / not used. Link: https://lore.kernel.org/linux-media/20220615205037.16549-8-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Nothing ever sets the format to IA_CSS_FRAME_FORMAT_MIPI and frame_init_mipi_plane() is the only code-path which ever sets frame->contiguous to true. Drop A_CSS_FRAME_FORMAT_MIPI support from ia_css_frame_init_planes() as part of the removal of contiguous alloc support from the frame code. Link: https://lore.kernel.org/linux-media/20220615205037.16549-7-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Drop the contiguous argument from frame_create() all callers always passes false. Link: https://lore.kernel.org/linux-media/20220615205037.16549-6-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Drop the contiguous argument from frame_allocate_with_data() its only caller always passes false. Link: https://lore.kernel.org/linux-media/20220615205037.16549-5-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
Drop the contiguous argument from ia_css_frame_allocate_with_buffer_size() its only caller always passes false. Link: https://lore.kernel.org/linux-media/20220615205037.16549-4-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
ia_css_frame_allocate_contiguous() and ia_css_frame_allocate_contiguous_from_info() are not used anywhere, remove them. Link: https://lore.kernel.org/linux-media/20220615205037.16549-3-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
I noticed that the RAW_BUF_STRIDE macro is using the removed SH_CSS_BINARY_ID_POST_ISP define, which should be a problem except that the RAW_BUF_STRIDE macro itself is not used at all, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-2-hdegoede@redhat.comReviewed-by:
-
Krzysztof Hałasa authored
The driver has been extensively tested in an i.MX6-based system. AR0521 is a 5.7 mm x 4.3 mm, 5 MPix RGGB MIPI/HiSPi BSI CMOS sensor from On Semiconductor. Signed-off-by:
Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Krzysztof Hałasa authored
This patch documents DT bindings for the AR0521 camera sensor driver. [Sakari Ailus: Reworked subject and commit message a little] Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jacopo Mondi authored
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:
-
Jacopo Mondi authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
Implement the init_cfg pad operation to initialize the subdev state format to the default one. Signed-off-by:
-
Jacopo Mondi authored
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 authored
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:
-
Hugues Fruchet authored
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 authored
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 authored
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 authored
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 authored
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 authored
The per-mode register tables are not sorted by size. Fix it. Cosmetic change only. Signed-off-by:
-
Jacopo Mondi authored
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 authored
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 authored
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 authored
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 authored
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:
-
