Refactor the handling of supported formats in the RZ/G2L CRU driver by
adding `pixelformat` and `bpp` members to the `rzg2l_cru_ip_format`
structure.
New helper functions, `rzg2l_cru_ip_format_to_fmt()` and
`rzg2l_cru_ip_index_to_fmt()`, are added to retrieve format information
based on 4CC format and index, respectively. These helpers allow the
removal of the now redundant `rzg2l_cru_format_from_pixel()` function.
The new helpers are used in `rzg2l_cru_format_bytesperline()`,
`rzg2l_cru_format_align()`, and `rzg2l_cru_enum_fmt_vid_cap()`,
streamlining the handling of supported formats and improving code
maintainability.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20241018133446.223516-14-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
`WARN_ON(!fmt)` check in `rzg2l_cru_format_bytesperline()` is unnecessary
because the `rzg2l_cru_format_align()` function ensures that a valid
`pixelformat` is set before calling `rzg2l_cru_format_bytesperline()`. As
a result, `rzg2l_cru_format_from_pixel()` is guaranteed to return a
non-NULL value, making the check redundant.
Additionally, the return type of `rzg2l_cru_format_bytesperline()` is
`u32`, but the code returned `-EINVAL`, a negative value. This mismatch is
now resolved by removing the invalid error return path.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20241018133446.223516-11-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Replace the ternary operator with an if. In this case the code is more
clear and also fixes the following cocci warnings:
drivers/staging/media/atomisp/pci/sh_css_frac.h:40:17-18: WARNING opportunity for max()
drivers/staging/media/atomisp/pci/sh_css_frac.h:50:17-18: WARNING opportunity for max()
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The current order of locking between the driver mutex and the v4l2 subdev
state lock causes a circular locking dependency when trying to set up a
link. Fix this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[Sakari Ailus: Fix spelling in commit message.]
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The `get_frame_desc()` operation should always be called on a source pad,
which is indicated by the `MEDIA_PAD_FL_SOURCE` flag. This patch adds a
check in `call_get_frame_desc()` to ensure that the `MEDIA_PAD_FL_SOURCE`
flag is set for the pad before invoking `get_frame_desc()`. If the pad is
not a source pad, the function will return an `-EOPNOTSUPP` error,
signaling that the operation is not supported on non-source pads.
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The function ub960_rxport_read is being called and afterwards ret is
being checked for any failures, however ret is not being assigned to
the return of the function call. Fix this by assigning ret to the
return of the call which appears to be missing.
Fixes: afe267f2d3 ("media: i2c: add DS90UB960 driver")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move request_irq() to probe(), in order to avoid requesting IRQ during
device start which happens frequently. As this function is in probe(), it
is better to replace it with its devm variant for managing the resource
efficiently.
While at it, drop the IRQF_SHARED flag as currently there is a single user
for this IRQ.
Suggested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If cci_read() fails, 'st' is set to 0 in cci_read(), so we return success,
instead of the expected error code.
Fix it and return the expected error.
Fixes: 9a6d7f2ba2 ("media: i2c: st-vgxy61: Convert to CCI register access helpers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add support for Raspberry Pi CFE. The CFE is a hardware block that
contains:
- MIPI D-PHY
- MIPI CSI-2 receiver
- Front End ISP (FE)
The driver has been upported from the Raspberry Pi kernel commit
88a681df9623 ("ARM: dts: bcm2712-rpi: Add i2c<n>_pins labels").
Co-developed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add two meta formats for PiSP FE: V4L2_META_FMT_RPI_FE_CFG and
V4L2_META_FMT_RPI_FE_STATS. The former is used to provide configuration
for the FE and the latter is used to read the statistics from the FE.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some R-Car SoCs are capable of capturing RAW10. Extend the format
enumeration, validation and setup to expose and configure for this
format if the particular device supports it.
The VIN is usually capable of converting from most media bus formats to
a range of different pixel formats. However if the input media bus
format is a RAW10 format this is not possible so the corresponding pixel
output format is forced.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The ISP Channel Selector IP is the same for all current Gen4 devices.
This was not known when adding support for V3U and V4H and a single SoC
specific compatible was used.
Before adding more SoC specific bindings for V4M add a family compatible
fallback for Gen4. That way the driver only needs to be updated once for
Gen4, and we still have the option to fix any problems in the driver if
any testable differences between the SoCs are found.
There are already DTS files using the V3U and V4H compatibles which
needs to be updated to not produce a warning for DTS checks. The driver
also needs to kept the compatible values to be backward compatible , but
for new Gen4 SoCs such as V4M we can avoid this.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The MAX96724 is almost identical to the MAX96712 and can be supported by
the same driver, add support for it.
For the staging driver which only supports patter generation the big
difference is that the datasheet (rev 4) for MAX96724 do not describe
the DEBUG_EXTRA register, which is at offset 0x0009 on MAX96712. It's
not clear if this register is removed or moved to a different offset.
What is known is writing to register 0x0009 have no effect on MAX96724.
This makes it impossible to increase the test pattern clock frequency
from 25 MHz to 75Mhz on MAX96724. To be able to get a stable test
pattern the DPLL frequency have to be increase instead to compensate for
this. The frequency selected is found by experimentation as the MAX96724
datasheet is much sparser then what's available for MAX96712.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The DEBUG_EXTRA register is not part of soon to be added MAX96724
device. To make it easier to understand the differences when reading the
code prepare for the addition by creating named defines for the
register.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Prepare for supporting MAX96724 by moving the soon device specific link
frequency setting into information structure. This struct will be
extended to carry more differences between the two devices supported.
While at it remove trailing comma in device table, no entries will be
appended after the sentinel.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This check is incorrect and checks the wrong register. Furthermore there
is no documented shared device id register for MAX96712. There might be
overlap with the soon to be added MAX96724 device which do document such
a register.
However as the check was merely a precaution and to check during
development that the driver could talk to the device there is no harm in
removing it all together. A correct and more sophisticated check can be
added later if there ever is a need to differentiate between different
versions of a device.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The MAX96712 and MAX96724 are both quad GMSL2 to CSI-2 deserializers and
are in parts similar, but not identical. The most obvious difference is
on the CSI-2 side where the MAX96712 have 4 PHYs and support D-PHY with
1x4, 2x2 and 4x2 lanes where the MAX96724 only have 2 PHYs and supports
D-PHY with 2x4 or 4x2 lanes.
The register layout overlap in part but there are differences and holes.
Most of the differences are related to the different number of CSI-2
PHYs, but there are other capability differences between the two.
Add a specific compatible for MAX96724 to the max96712 bindings. The
bindings do not yet support validating all DT properties to limit it the
each devices capabilities. However to allow for this in future a
specific compatible for the two different devices are needed.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The V4M is the second Gen4 device that is enabled in the rcar-csi2
driver. There is much overlap with the already supported V4H device. The
registers that where new on Gen4 and where added with the V4H prefix are
retained and only new registers unique to the V4M are added with the new
V4M prefix. This follows the style for when V4H was added which had an
overlap with Gen3 registers.
The V4M CSI-2 receiver supports D-PHY mode only, either in 1-, 2- or
4-lane configuration. The datasheets do not document lane swapping and
is left out for now.
While the V4M only supports D-PHY the configuration for it is added in
such a way that it can be reused for V4H which supports both C-PHY and
D-PHY. No known SoC exists to test the D-PHY configuration on V4H so
it's not wired-up.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Lad Prabhakar
Biju Das
Ricardo Ribalda
Paul Elder
Bingbu Cao
Colin Ian King
Sakari Ailus
Christophe JAILLET
Tomi Valkeinen
Hridesh MG
Niklas Söderlund