summaryrefslogtreecommitdiff
path: root/drivers/media/platform/renesas/vsp1/vsp1_pipe.h
AgeCommit message (Collapse)Author
2025-05-02media: renesas: vsp1: Report colour space information to userspaceLaurent Pinchart
The vsp1 driver implements very partial colour space support: it hardcodes the colorspace field on all video devices and subdevices to V4L2_COLORSPACE_SRGB, regardless of the configured format. The xfer_func, ycbcr_enc and quantization fields are not set (except for hsv_enc for HSV formats on video devices). This doesn't match the hardware configuration, which handles YUV data as encoding in BT.601 with limited range. As a first step towards colour space configuration, keep the colour space fields hardcoded, but set them based on the selected format type (RGB, YUV or HSV). While at it, remove an extra blank line. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-6-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Implement pixel format enumerationLaurent Pinchart
The VSP1 driver is missing the ability to enumerate pixel formats on its video nodes, which is supposed to be supported according to the V4L2 API. Implement the enumeration to fix this issue. As the device is media controller-centric, also implement the ability to filter pixel formats by media bus code, and report the missing V4L2_CAP_IO_MC capability. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250429232904.26413-2-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-02media: renesas: vsp1: Add support IIF ISP InterfaceJacopo Mondi
The IIF (ISP InterFace) is a VSP2 function that transfers data to the ISP by reading from external memory through two RPF instances. Add support for it in the vsp1 driver by introducing a new entity type. The sole required operation is to enable the IIF function during configure_stream(). Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20250401-v4h-iif-v7-1-cc547c0bddd5@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2024-06-20media: renesas: vsp1: Add and use function to dump a pipeline to the logLaurent Pinchart
It is useful for debugging purpose to dump a vsp1_pipeline to the kernel log. Add a new function to do so, and use it when initializing the video and DRM pipelines. As __vsp1_pipeline_dump() needs to construct the log message iteratively, it uses pr_cont(...) (exact equivalent to the more verbose "printk(KERN_CONT ..."). The function thus can't use dev_dbg() to log the initial part of the message, for two reasons: - pr_cont() doesn't seem to work with dev_*(). Even if the format string passed to dev_*() doesn't end with a '\n', pr_cont() starts a new line in the log. This behaviour doesn't seem to be clearly documented, and may or may not be on purpose. - Messages printed by dev_dbg() may be omitted if dynamic debugging is enabled. In that case, the continuation messages will still be printed, leading to confusing log messages. To still benefit from the dynamic debug infrastructure, we declare a vsp1_pipeline_dump() macro that uses _dynamic_func_call() when dynamic debugging is enabled. The whole vsp1_pipeline_dump() call can be selected at runtime. The __vsp1_pipeline_dump() function then uses a plain "printk(KERN_DEBUG ...)" to print the message header using the debug log level, and pr_cont() to print the rest of the message on the same line. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
2024-06-20media: renesas: vsp1: Replace vsp1_partition_window with v4l2_rectLaurent Pinchart
The vsp1_partition_window structure is used to store the horizontal size of a partition window. This is all that is currently needed, as all partitions span the whole image vertically. The horizontal window size is retrieved in the .configure_partition() handler from the vsp1_partition_window structure, and the vertical window size from the subdev state. Accessing the subdev state in the .configure_partition() handler is problematic in the context of moving to the V4L2 subdev active state API, as .configure_partition() is called in non-interruptable context, and the state lock can't be taken. To avoid this, start by storing the vertical size in the window, replacing the custom vsp1_partition_window structure with a v4l2_rect. Retrieving the vertical size from the window in .configure_partition() will be done in a subsequent change. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
2024-06-20media: renesas: vsp1: Pass partition pointer to .configure_partition()Laurent Pinchart
The entity .configure_partition() function operates on a partition, and has to retrieve that partition from the pipeline's current partition field. Pass the partition pointer to the function to make it clearer what partition it operates on, and remove the vsp1_pipeline.partition field. This change clearly shows that the DRM pipeline doesn't use partitions, which makes entity implementation more complex and error-prone. This will be addressed in a further cleanup. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
2024-06-20media: renesas: vsp1: Store RPF partition configuration per RPF instanceLaurent Pinchart
The vsp1_partition structure stores the RPF partition configuration in a single field for all RPF instances, while each RPF can have its own configuration. Fix it by storing the configuration separately for each RPF instance. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Fixes: ab45e8585182 ("media: v4l: vsp1: Allow entities to participate in the partition algorithm") Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
2024-06-20media: renesas: vsp1: Move partition calculation to vsp1_pipe.cLaurent Pinchart
The partition calculation code, located in vsp1_video.c, is not specific to video pipelines. To prepare for its usage in DRM pipelines, move it to vsp1_pipe.c. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
2023-04-11media: vsp1: Add underrun debug printTomi Valkeinen
Print underrun interrupts with ratelimited print. Note that we don't enable the underrun interrupt. If we have underruns, we don't want to get flooded with interrupts about them. It's enough to see that an underrun happened at the end of a frame. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
2022-03-14media: platform: place Renesas drivers on a separate dirMauro Carvalho Chehab
In order to cleanup the main platform media directory, move Renesas driver to its own directory. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>