kernel/drivers/media/platform/renesas, branch linux-6.9.y

media: rcar-vin: work around -Wenum-compare-conditional warning

2024-05-30T07:44:47Z

[ Upstream commit 1a742c6010d136cb6c441a0f1dd2bfbfae3c4df2 ] clang-19 warns about mixing two enum types here: drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-core.c:216:18: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] This one is intentional, and there is already a cast to work around another warning, so address this by adding another cast. Fixes: 406bb586dec0 ("media: rcar-vin: Add r8a779a0 support") Signed-off-by: Arnd Bergmann Reviewed-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin

media: rcar-isp: Disallow unbind of devices

2024-03-07T15:35:13Z

It is not safe to unbind and then rebind a subdevice in the rcar-vin pipeline. Depending on what subdevice and in what order a device is rebound the rcar-vin driver can misbehave. Until this can be solved suppress the files in sysfs which allows for this. This is in line with what is done for other subdevices exclusively use with the rcar-vin pipeline, e.g. rcar-csi2. Signed-off-by: Niklas Söderlund Reviewed-by: Sakari Ailus Signed-off-by: Hans Verkuil

media: rcar-csi2: Move driver to renesas directory

2024-02-16T10:46:32Z

The rcar-csi2 driver was added before the platform/renesas directory existed and since it was used together in a pipeline with the rcar-vin driver it was located together with it. The rcar-isp driver can also be used together with the rcar-csi2 driver in a pipeline that is terminated by the rcar-vin driver. However by the time rcar-isp was added the platform/renesas directory existed so it was added there. To remove the confusion that the rcar-csi2 driver have code dependencies on the rcar-vin driver move it to the same directory level as the rcar-isp driver. This makes it clear they are three distinct drivers that can be used together in a pipeline, but do not depend on each other. Signed-off-by: Niklas Söderlund Signed-off-by: Hans Verkuil

media: platform: rzg2l-cru: rzg2l-video: Fix start reception procedure

2024-02-15T09:57:54Z

As per section 35.3.1 Starting Reception for the MIPI CSI-2 Input on the latest hardware manual (R01UH0914EJ0145 Rev.1.45) we need to supply all the clocks and then release the CRU resets. Currently we are releasing the resets and then supplying the clocks. So, fix the start reception procedure. Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20240213181233.242316-6-biju.das.jz@bp.renesas.com Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: platform: rzg2l-cru: rzg2l-csi2: Restructure vclk handling

2024-02-15T09:57:54Z

As per section 35.3.1 Starting Reception for the MIPI CSI-2 Input on the latest hardware manual (R01UH0914EJ0145 Rev.1.45) we need to disable the vclk before enabling the LINK reception and enable the vclk after enabling the link Reception. So restructure vclk handling as per the HW manual. Signed-off-by: Biju Das Link: https://lore.kernel.org/r/20240213181233.242316-5-biju.das.jz@bp.renesas.com Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: platform: rzg2l-cru: rzg2l-video: Fix image processing initialization

2024-02-15T09:57:54Z

As per section 35.3.1 Starting Reception for the MIPI CSI-2 Input on the latest hardware manual (R01UH0914EJ0140 Rev.1.40) it is mentioned that initialize the AXI master first and then initialize the image processing. Fix the start procedure as per the hardware manual. Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240213181233.242316-4-biju.das.jz@bp.renesas.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: platform: rzg2l-cru: rzg2l-ip: Add delay after D-PHY reset

2024-02-15T09:57:54Z

As per section 35.3.1 Starting Reception for the MIPI CSI-2 Input on the latest hardware manual (R01UH0914EJ0140 Rev.1.40) it is mentioned that after DPHY reset, we need to wait for 1 msec or more before start receiving data from the sensor. So add a delay after pre_streamon(). Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240213181233.242316-3-biju.das.jz@bp.renesas.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: platform: rzg2l-cru: rzg2l-csi2: Switch to RUNTIME_PM_OPS()

2024-02-15T09:57:54Z

Replace the old SET_RUNTIME_PM_OPS() helpers with its modern alternative RUNTIME_PM_OPS(). The usage of pm_ptr and RUNTIME_PM_OPS() allows the compiler to see where it's used but still drop the dead code. After this we can get rid of the unnecessary '__maybe_unused' annotations on PM functions. Signed-off-by: Biju Das Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240213181233.242316-2-biju.das.jz@bp.renesas.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil

media: videobuf2: core: Rename min_buffers_needed field in vb2_queue

2023-12-13T16:31:27Z

Rename min_buffers_needed into min_queued_buffers and update the documentation about it. Signed-off-by: Benjamin Gaignard Signed-off-by: Hans Verkuil [hverkuil: Drop the change where min_queued_buffers + 1 buffers would be] [hverkuil: allocated. Now this patch only renames this field instead of making] [hverkuil: a functional change as well.] [hverkuil: Renamed 3 remaining min_buffers_needed occurrences.]

media: v4l2-subdev: Rename .init_cfg() operation to .init_state()

2023-12-04T09:37:47Z

The subdev .init_cfg() operation is affected by two issues: - It has long been extended to initialize a whole v4l2_subdev_state instead of just a v4l2_subdev_pad_config, but its name has stuck around. - Despite operating on a whole subdev state and not being directly exposed to the subdev users (either in-kernel or through the userspace API), .init_cfg() is categorized as a subdev pad operation. This participates in making the subdev API confusing for new developers. Fix it by renaming the operation to .init_state(), and make it a subdev internal operation. Signed-off-by: Laurent Pinchart Acked-by: Michael Riesch # for imx415 Acked-by: Shuah Khan # for vimc Reviewed-by: Philipp Zabel Reviewed-by: Tomi Valkeinen [Sakari Ailus: Resolved a conflict in Renesas vsp1 driver.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil