- 08 Jul, 2022 40 commits
-
-
Hans de Goede authored
Drop the ATOMISP_ACC_FW_LOAD_* defines, these are no longer used anywhere. Link: https://lore.kernel.org/linux-media/20220615205037.16549-25-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
atomisp_is_acc_enabled() always returns false now, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-24-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
atomisp_css_acc_done() is no longer used anywhere, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-23-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
With the removal of the ACC ioctls and atomisp_acc.c asc.acc.pipeline never gets set, so it is always NULL. Remove asc.acc.pipeline and drop checks for it being NULL / !NULL. Link: https://lore.kernel.org/linux-media/20220615205037.16549-22-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
With the removal of the ACC ioctls and atomisp_acc.c a whole bunch of atomisp_*css_* functions is no longer used, remove them. Link: https://lore.kernel.org/linux-media/20220615205037.16549-21-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
With the ACC ioctls removed sd->acc.fw is always empty turning the atomisp_acc.c code into no-ops, remove it. Link: https://lore.kernel.org/linux-media/20220615205037.16549-20-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
These ioctls allow userspace to load custom programs into the ISP, which: a) Seems dangerous b) Cannot be used by opensource userspace since there is no FOSS code to create such programs b) These seem to be unused even by the Android closed source camera code (they don't show up in a strace of the camera app) So removing these seems be a good idea. Another reason to remove these is that atomisp_acc_map() is the only user of the userptr functionality in hmm_alloc(), so it gets in the way of further cleanups / simplification of the hmm code. Link: https://lore.kernel.org/linux-media/20220615205037.16549-19-hdegoede@redhat.comReviewed-by:
-
Hans de Goede authored
The comment documenting hmm_bo_allocated() was copied (and not modified) from the comment documenting hmm_bo_alloc(), so there are 2 copies of the hmm_bo_alloc() documentation. Remove the copy of the comment above the hmm_bo_allocated() prototype. Link: https://lore.kernel.org/linux-media/20220615205037.16549-18-hdegoede@redhat.comReviewed-by:
-
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:
-
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:
-
