rote:
> >>>> On 26/05/25 12:49, Laurent Pinchart wrote:
> >>>>> On Mon, May 26, 2025 at 11:58:37AM +0200, Tommaso Merciai wrote:
> >>>>>> On 26/05/25 11:26, Maxime Ripard wrote:
> >>>>>>> On Mon, May 26, 2025 at 10:54:5
)
What is "old" and "new" here ? Is it before and after Dmitry's patch, or
before and after yours ? Please be precise when describing problems.
> What do you think? Thanks in advance.
You're only explaining above what the "old" and "new" behaviours are,
and claiming one of them is causing an issue, but you're not explaining
*why* it causes an issue. That's what your commit message is expected to
detail.
--
Regards,
Laurent Pinchart
Hi Wolfram,
Thank you for the patch.
On Thu, May 22, 2025 at 12:34:44PM +0200, Wolfram Sang wrote:
> Not RCAR, but R-Car.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Kieran Bingham
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gp
Hi Marco,
Thank you for the patch.
On Thu, May 15, 2025 at 07:36:43PM +0200, Marco Felsch wrote:
> Make use of __free(device_node) to simplify the of_node_put() error
> handling paths. No functional changes.
>
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
>
struct rzg2l_mipi_dsi *dsi, u64 hsfreq_millihz);
> + void (*dphy_late_init)(struct rzg2l_mipi_dsi *dsi);
As this is called at startup time I would have called it dphy_startup.
Up to you.
Reviewed-by: Laurent Pinchart
> void (*dphy_exit)(struct rzg2l_mipi_dsi *dsi);
> u32
if (IS_ERR(dsi->rstc))
> return dev_err_probe(dsi->dev, PTR_ERR(dsi->rstc),
>"failed to get rst\n");
--
Regards,
Laurent Pinchart
rained format support control for different
> SoC variants.
>
> Co-developed-by: Fabrizio Castro
> Signed-off-by: Fabrizio Castro
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v4->v5:
> - Updated RZ_MIPI_DSI_FEA
hsfreq_millihz, MILLI);
> /*
>* Global timings characteristic depends on high speed Clock Frequency
>* Currently MIPI DSI-IF just supports maximum FHD@60 with:
> @@ -776,7 +779,7 @@ static int rzg2l_mipi_dsi_probe(struct platform_device
> *pdev)
>* mode->clock and format are not available. So initialize DPHY with
>* timing parameters for 80Mbps.
>*/
> - ret = dsi->info->dphy_init(dsi, 8000);
> + ret = dsi->info->dphy_init(dsi, 8000ULL * MILLI);
> if (ret < 0)
> goto err_phy;
>
--
Regards,
Laurent Pinchart
rzg2l_mipi_dsi_dphy_exit(dsi);
> + dsi->info->dphy_exit(dsi);
> pm_runtime_put(dsi->dev);
>
> /* Initialize the DRM bridge. */
> @@ -782,7 +799,7 @@ static int rzg2l_mipi_dsi_probe(struct platform_device
> *pdev)
> return 0;
>
> err_phy:
> -
75;
> - } else if (hsfreq > 25) {
> + } else if (hsfreq > 25000) {
> clkkpt = 7;
> clkbfht = 8;
> clkstpt = 27;
> @@ -753,7 +759,7 @@ static int rzg2l_mipi_dsi_probe(struct platform_device
> *pdev)
>* mode->clock and format are not available. So initialize DPHY with
>* timing parameters for 80Mbps.
>*/
> - ret = rzg2l_mipi_dsi_dphy_init(dsi, 8);
> + ret = rzg2l_mipi_dsi_dphy_init(dsi, 8000);
> if (ret < 0)
> goto err_phy;
>
--
Regards,
Laurent Pinchart
;* lanes: number of data lanes
>*
> - * hsclk(bit) = hsclk(byte) * 8
> + * hsclk(bit) = hsclk(byte) * 8 = hsfreq
>*/
> bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> - hsfreq = (mode->clock * bpp * 8) / (8 * dsi->lanes);
>
Hi Prabhakar,
On Mon, May 12, 2025 at 07:23:21PM +0100, Prabhakar wrote:
> From: Lad Prabhakar
>
> The VCLK range for Renesas RZ/G2L SoC is 148.5 MHz to 5.803 MHz. Add a
I would write "5.803 MHz to 148.5 MHz" as ranges are usually expressed
in increasing order.
Reviewed-b
.
>
> There is one LCDC unit available on the RZ/V2H(P) SoC which is connected
> to the DSI.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v4->v5:
> - Added reviewed tag from Biju
>
> v3->v4:
> - N
pports both DSI and DPI interfaces.
>
> Due to this difference, a SoC-specific compatible string
> 'renesas,r9a09g057-du' is added for the RZ/V2H(P) SoC.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Krzysztof Kozlowski
> Reviewed-by: Biju Das
Reviewed-by
form_device *pdev)
> fsl_ldb->dev = &pdev->dev;
> fsl_ldb->bridge.funcs = &funcs;
> fsl_ldb->bridge.of_node = dev->of_node;
> + fsl_ldb->bridge.driver_private = fsl_ldb;
>
> fsl_ldb->clk = devm_clk_get(dev, "ldb");
> if (IS_ERR(fsl_ldb->clk))
--
Regards,
Laurent Pinchart
evice_node) =
> + of_graph_get_port_by_id(dev->of_node, 2);
>
> - port1 = of_graph_get_port_by_id(dev->of_node, 1);
> - port2 = of_graph_get_port_by_id(dev->of_node, 2);
> dual_link = drm_of_lvds_get_dual_link_pixel_order(port1, port2);
> - of_node_put(port1);
> - of_node_put(port2);
> -
> if (dual_link < 0)
> return dev_err_probe(dev, dual_link,
>"Error getting dual link
> configuration\n");
--
Regards,
Laurent Pinchart
Hi Marco,
Thank you for the patch.
On Thu, May 15, 2025 at 12:24:52AM +0200, Marco Felsch wrote:
> Make use of dev_err_probe() to easily spot issues via the debugfs or
> kernel log. No functional changes.
>
> Signed-off-by: Marco Felsch
Reviewed-by: Laurent Pinchart
> ---
>
Hi Tommaso,
On Fri, May 02, 2025 at 10:21:21AM +0200, Tommaso Merciai wrote:
> On Wed, Apr 30, 2025 at 02:28:55AM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series extends the VSP1 driver with colorspace support. It
> > turns out that the VSP RPF a
Now that the VSP1 driver supports color spaces, expose them through the
API used by the DU driver. This allows configuring the YCbCr encoding
and quantization used by each plane, ensuring correct color rendering.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/renesas/vsp1/vsp1_drm.c
The RPF and WPF support different encodings and quantizations when
converting between RGB and YUV formats. Allow setting the corresponding
format parameters from userspace, and configure the hardware
accordingly.
Signed-off-by: Laurent Pinchart
---
.../media/platform/renesas/vsp1/vsp1_pipe.c
Now that the VSP1 driver allows setting per-plance color encoding and
color range for its DRM pipeline, create the corresponding DRM
properties in the DU driver and wire them to the VSP. This completes
support for plane color space.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/renesas
The vsp1_drm structure defines an anonymous nested structure to store
per-input data. In preparation for extending that structure, give it a
name and is it through the driver. This improves code readability.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/renesas/vsp1/vsp1_drm.c | 18
The HSV formats are not restricted to Gen2 platforms, but to VSP
instances that implement the HSI and HST modules. Make it conditional to
the VSP1_HAS_HSIT feature flag.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
.../media/platform/renesas/vsp1/vsp1_pipe.c | 32
at it, remove an extra blank line.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Drop unneeded colorspace adjustements when propagating RWPF formats
---
.../media/platform/renesas/vsp1/vsp1_brx.c| 9 +++-
.../media/platform/renesas/vsp1/vsp1_entity.c | 22 +-
.../media/pla
-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/media/platform/renesas/vsp1/vsp1_rwpf.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rwpf.c
b/drivers/media/platform/renesas/vsp1/vsp1_rwpf.c
index
Not all VSP instance incorporate the HSI and HST modules. Add a
VSP1_HAS_HSIT feature flag, and create the modules only on VSP instances
that implement them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/media/platform/renesas/vsp1/vsp1.h| 1 +
.../media/platform
bus code, and report the missing
V4L2_CAP_IO_MC capability.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
.../media/platform/renesas/vsp1/vsp1_pipe.c | 103 ++
.../media/platform/renesas/vsp1/vsp1_pipe.h | 3 +
.../media/platform/renesas/vsp1/vsp1_video.c
refore address those issues
separately.
I would like to get patch 1/9 to 8/9 merged in v6.16, to then merge 9/9
in v6.17.
[1]
https://lore.kernel.org/linux-renesas-soc/20250409004758.11014-1-laurent.pinch...@ideasonboard.com
[2] https://git.ideasonboard.com/renesas/vsp-tests.git/log/?h=csc
Laurent Pi
e DRM_FORMAT_I210fourcc_code('I', '2', '1', '0') /* 2x1
> > subsampled Cb (1) and Cr (2) planes 10 bits per channel */
> > +#define DRM_FORMAT_I410fourcc_code('I', '4', '1', '0') /*
> > non-subsampled Cb (1) and Cr (2) planes 10 bits per channel */
> > +
> > +/*
> > + * 3 plane YCbCr LSB aligned
> > + * index 0 = Y plane, [15:0] x:Y [4:12] little endian
> > + * index 1 = Cr plane, [15:0] x:Cr [4:12] little endian
> > + * index 2 = Cb plane, [15:0] x:Cb [4:12] little endian
> > + */
> > +#define DRM_FORMAT_I012fourcc_code('I', '0', '1', '2') /* 2x2
> > subsampled Cb (1) and Cr (2) planes 12 bits per channel */
> > +#define DRM_FORMAT_I212fourcc_code('I', '2', '1', '2') /* 2x1
> > subsampled Cb (1) and Cr (2) planes 12 bits per channel */
> > +#define DRM_FORMAT_I412fourcc_code('I', '4', '1', '2') /*
> > non-subsampled Cb (1) and Cr (2) planes 12 bits per channel */
> > +
> >
> > /*
> >* Format Modifiers:
--
Regards,
Laurent Pinchart
0.0 - 1.0 nominal range definition for the abstract KMS
> > > color processing is necessary.
> > >
> > > It also means that limited range Y8 data, when containing values 0-15
> > > or 240-255, would produce negative and greater than 1.0 values,
> > > respectively. They might get immediately clamped to 0.0 - 1.0 with the
> > > first color operation they face, though, but the concept seems
> > > important and carrying over to the new color pipelines UAPI which might
> > > choose not to clamp.
> >
> > Is the behavior of values outside the limited range something that needs
> > to be defined? We can't know how each piece of HW behaves with
> > "undefined" input, so should we not just define the behavior as platform
> > specific?
>
> Hi Tomi,
>
> it's not undefined nor illegal input in general. The so-called
> sub-black and super-white ranges exist for a reason, and they are
> intended to be used in video processing to avoid clipping in
> intermediate processing steps when a filter overshoots a bit. There are
> also practices that depend on them, like PLUGE calibration with
> traditional signals on a display: https://www.itu.int/rec/R-REC-BT.814
>
> I think it would be really good to have defined behaviour if at all
> possible.
>
> > In any case: I can't say I fully understood all the discussions wrt.
> > color spaces. But my immediate interest is, of course, this series =).
> > So is there something that you think should be improved here?
>
> Right, the range discussion is a tangent and applies to all YUV
> formats, so it's not a new question.
>
> > My understanding is that the Y-only pixel formats behave in a well
> > defined way (or, as well defined as the YUV formats), and there's
> > nothing more to add here. Is that right?
>
> There are two things:
>
> - Y8 follows COLOR_RANGE property, just like all other YUV formats.
> - Y8 implies that Cb and Cr are both neutral (0.0 in nominal values).
>
> I'd like these explicitly written down, so that they become obvious to
> everyone. I suspect either one might be easy to forget when writing
> code and taking shortcuts without thinking.
>
>
> Laurent,
>
> I did find a case where (Y', neutral, neutral) does *not* seem to expand
> to RGB=(Y, Y, Y): ICtCp. The conversion from ICtCp to L'M'S' does
> produce (Y', Y', Y'), but the LMS-to-RGB matrix scrambles it.
>
> I didn't dig through BT.2020 constant-luminance Y'C'bcC'rc, but I
> wouldn't be surprised if it scrambled too.
>
> Of course, both of the above are not just one matrix. They require two
> matrices and the transfer characteristic each to compute. KMS color
> operations cannot implement those today, but with the colorop pipelines
> they will if the hardware does it.
>
> That's why I think it's important to document the assumption of Cb and
> Cr when not part of the pixel format, and not write down a specific
> expansion to RGB like (Y, Y, Y).
Every time I discuss color spaces, the scopes of "RGB" and "YUV" seem to
expand more and more. This makes me wonder how we define those two
concepts. Taking the conversion from RGB to ICtCp as an example, would
you consider LMS and L'M'S' as "RGB" formats, and ICtCp as a "YUV"
format ?
--
Regards,
Laurent Pinchart
The vsp1_drm structure defines an anonymous nested structure to store
per-input data. In preparation for extending that structure, give it a
name and is it through the driver. This improves code readability.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/renesas/vsp1/vsp1_drm.c | 18
s ?
[1]
https://lore.kernel.org/r/20250409003815.10253-1-laurent.pinchart+rene...@ideasonboard.com
Laurent Pinchart (3):
media: renesas: vsp1: Name nested structure in vsp1_drm
media: renesas: vsp1: Expose color space through the DRM API
drm: rcar-du: Create plane color properties
drivers/
Now that the VSP1 driver allows setting per-plance color encoding and
color range for its DRM pipeline, create the corresponding DRM
properties in the DU driver and wire them to the VSP. This completes
support for plane color space.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/renesas
Now that the VSP1 driver supports color spaces, expose them through the
API used by the DU driver. This allows configuring the YCbCr encoding
and quantization used by each plane, ensuring correct color rendering.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/renesas/vsp1/vsp1_drm.c
606] imx8mp-dw-hdmi-tx 32fd8000.hdmi: Detected HDMI TX controller
> > v2.13a with HDCP (SAMSUNG HDMI TX PHY)
> > [ 3.352436] imx8mp-dw-hdmi-tx 32fd8000.hdmi: registered DesignWare HDMI
> > I2C bus driver
> > [ 3.378609] etnaviv etnaviv: bound 3800.gpu (ops gpu_ops)
> > [ 3.379829] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops)
> > [ 3.381695] etnaviv etnaviv: bound 3850.npu (ops gpu_ops)
> > [ 3.382290] etnaviv-gpu 3800.gpu: model: GC7000, revision: 6204
> > [ 3.383178] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
> > [ 3.383735] etnaviv-gpu 3850.npu: model: GC8000, revision: 8002
> > [ 3.383753] etnaviv-gpu 3850.npu: etnaviv has been instantiated on a
> > NPU, for which the UAPI is still experimental
> > [ 3.386818] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > [ 3.390018] stackdepot: allocating hash table of 131072 entries via
> > kvcalloc
> > [ 3.399113] [drm] Initialized imx-lcdif 1.0.0 for
> > 32fc6000.display-controller on minor 1
> > [ 3.523021] Console: switching to colour frame buffer device 180x56
> > [ 3.539272] imx-lcdif 32fc6000.display-controller: [drm] fb0:
> > imx-lcdifdrmfb frame buffer device
>
> Thank you for sharing this.
>
> One last question: Is this log from the mainline kernel?
> If so, did you apply any external patches to the GPU driver to make it work?
Yes, that was from a v6.14-rc1 kernel. I'm compiling v6.15-rc1 now. I
haven't applied any patch to the GPU driver.
> > > [ 10.201152] systemd[1]: Starting Load Kernel Module drm...
> > >
> > > I have not yet identified a conclusive reason for GNOME Shell's failure
> > > to start.
> > >
> > > However, since my primary objective was to preview the camera output
> > > on the display, I initially suspected the issue might be related to the
> > > HDMI
> > > display, as I encountered errors while using autovideosink. After your
> > > confirmation that the display was functioning correctly, I explored
> > > alternative
> > > video sinks and was able to successfully achieve a working preview using
> > > fbdevsink.
> > >
> > > I may revisit the GNOME Shell issue when time permits. If you have any
> > > suggestions or insights regarding the compositor or GPU setup failure,
> > > I’d be
> > > happy to take them into consideration.
> > >
> > > > > > > Could you please help me out or point me in the right direction?
> > > > > > >
> > > > > > > Thank you for your time.
--
Regards,
Laurent Pinchart
;
> Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_modeset_helper.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c
> index
struct drm_file *file,
> +const struct drm_format_info *info,
> const struct drm_mode_fb_cmd2 *mode_cmd,
> const struct drm_framebuffer_funcs *funcs);
> struct drm_framebuffer *
> drm_gem_fb_create_with_funcs(struct drm_device *dev, struct drm_file *file,
> + const struct drm_format_info *info,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>const struct drm_framebuffer_funcs *funcs);
> struct drm_framebuffer *
--
Regards,
Laurent Pinchart
-I Wu
> Cc: Zack Rusin
> Cc: Broadcom internal kernel review list
>
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Cc: virtualizat...@lists.linux.de
mat_info *info,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> ...
> };
>
> Cc: Alex Deucher
> Cc: Liviu Dudau
> Cc: Maxime Ripard
> Cc: Russell King
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Patrik Jak
-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_framebuffer.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index
Valkeinen
> Cc: Alex Deucher
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Andy Yan
> Cc: Thierry Reding
> Cc: Mikko Perttunen
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: amd-...@lists.
was to support formats with auxialiary
compression control planes, this won't be possible anymore if we pass
cmd->modifier[0] only. Is that an issue, or was this a foreseen use case
that never materialized ? If we don't need to support this anymore then
the code change is fine, and the documentation should be updated
accordingly.
>*/
> - const struct drm_format_info *(*get_format_info)(const struct
> drm_mode_fb_cmd2 *mode_cmd);
> + const struct drm_format_info *(*get_format_info)(u32 pixel_format, u64
> modifier);
>
> /**
>* @mode_valid:
--
Regards,
Laurent Pinchart
0] etnaviv-gpu 3800.gpu: model: GC7000, revision: 6204
[3.383178] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
[3.383735] etnaviv-gpu 3850.npu: model: GC8000, revision: 8002
[3.383753] etnaviv-gpu 3850.npu: etnaviv has been instantiated on a
NPU, for which the UAPI is
licitly launching an X server or Wayland compositor myself
>
> However, based on your response, I now realize that I may also need to
> enable GPU support in the mainline device tree. Specifically, I believe I
> need to enable the gpu2D and gpu3D nodes to allow the graphical
> environment to start properly and render the desktop over HDMI.
>
> Does that sound correct, or is there anything else I should check or
> enable?
That's a plausible explanation. The 2D GPU is probably not used by the
compositor, but a 3D GPU could be required. I'd recommend checking the
system logs to see why the compositor (or session manager) failed to
start.
> > > Could you please help me out or point me in the right direction?
> > >
> > > Thank you for your time.
--
Regards,
Laurent Pinchart
y see a white blinking cursor on the screen.. I'm not sure
> what I'm missing.
The white blinking cursor means the display is working from the kernel
point of view. What are you expecting, are you running an X server or
Wayland compositor ?
> Could you please help me out or point me in the right direction?
>
> Thank you for your time.
>
> Best Regards,
> Tarang
--
Regards,
Laurent Pinchart
On Wed, Apr 02, 2025 at 07:38:52PM +0800, shao.ming...@zte.com.cn wrote:
> From: Zhang Enpei
>
> Replace the open-code with dev_err_probe() to simplify the code.
>
> Signed-off-by: Zhang Enpei
> Signed-off-by: Shao Mingyin
Reviewed-by: Laurent Pinchart
> ---
&g
Hi Biju,
Thank you for the patch.
On Sun, Mar 30, 2025 at 11:23:52AM +0100, Biju Das wrote:
> Drop the unused variable bpp from struct rzg2l_du_format_info.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> v2:
> * New patch.
> ---
> drive
BIT(DRM_MODE_BLEND_PIXEL_NONE) |
> + BIT(DRM_MODE_BLEND_PREMULTI) |
> + BIT(DRM_MODE_BLEND_COVERAGE));
It's interesting that the driver already handles the alpha, zpos and
blend mode properties set in the st
On Mon, Mar 24, 2025 at 10:17:05AM -0700, Doug Anderson wrote:
> On Mon, Mar 24, 2025 at 9:40 AM Laurent Pinchart wrote:
> > On Tue, Mar 18, 2025 at 10:00:31PM +0100, Wolfram Sang wrote:
> > > Hi Laurent,
> > >
> > > > > Read out and check t
On Mon, Mar 31, 2025 at 01:53:37PM +0300, Pekka Paalanen wrote:
> On Mon, 31 Mar 2025 11:21:35 +0300 Laurent Pinchart wrote:
> > On Mon, Mar 31, 2025 at 10:54:46AM +0300, Pekka Paalanen wrote:
> > > On Thu, 27 Mar 2025 17:35:39 +0100 Geert Uytterhoeven wrote:
> > > >
t; me to use R8 instead of Y8?
> > https://lore.kernel.org/all/20220202111954.6ee9a10c@eldfell
>
> Hi Geert,
>
> indeed I did. I never thought of the question of expansion to R,G,B
> before. Maybe that expansion is what spells R8 and Y8 apart?
>
> I do think that expansion needs to be specified, so that the KMS color
> pipeline computations are defined. There is a big difference between
> multiplying these with an arbitrary 3x3 matrix (e.g. CTM):
>
> - (R, 0, 0)
> - (R, R, R)
> - (c1 * Y, c2 * Y, c3 * Y)
I'd be very surprised by an YUV to RGB conversion matrix where the first
column would contain different values. What we need to take into account
though is quantization (full vs. limited range).
> I forgot to consider that in the discussion of single-channel displays,
> because the displays obviously do not consider any other channel than
> the one.
>
> Using DRM_FORMAT_Y8 FB with a single-channel display might even be
> surprising, because the proposed Y8 definition would result in c1 * Y,
> and not Y. The default c1 comes from the BT.601 matrix IIRC?
>
> Therefore I think the difference between R8 and Y8 has been found. Now
> we just need to determine whether R8 means (R, 0, 0) or (R, R, R) to
> nail down the color operations as well. There are questions like what
> is the outcome at the video signal level when we have one KMS plane
> with an R8 FB and another KMS plane with an RGBA FB on the same
> CRTC? What about Y8 or NV12 in the mix? What if the video signal is
> single-channel, RGB, or YCbCr?
--
Regards,
Laurent Pinchart
On Fri, Mar 28, 2025 at 12:05:40PM +0200, Tomi Valkeinen wrote:
> On 28/03/2025 00:34, Laurent Pinchart wrote:
> > On Wed, Mar 26, 2025 at 03:22:45PM +0200, Tomi Valkeinen wrote:
> >> Add two new pixel formats:
> >>
> >> DRM_FORMAT_XV15 ("XV15")
>
The rz-du driver uses GEM DMA helpers, but does not implement the
drm_driver .gem_prime_import_sg_table operation. This prevents
importing dmabufs. Fix it by implementing the missing operation using
the DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE() helper macro.
Signed-off-by: Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Wed, Mar 26, 2025 at 03:22:49PM +0200, Tomi Valkeinen wrote:
> Add XVUY2101010, a 10 bits per component YCbCr format in a 32 bit
> container.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm
.buf_fmt= ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YUV444_10,
> + .swap = false,
> + .sf = scaling_factors_101010,
I'll have to trust your word on this, the documentation is just too
wrong in too many places to trust it. Assuming you've tested thi
A - 10 (as in 0xA), 4 - 4 bytes.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_fourcc.c | 3 +++
> include/uapi/drm/drm_fourcc.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/
Hi Tomi,
Thank you for the patch.
On Wed, Mar 26, 2025 at 03:22:53PM +0200, Tomi Valkeinen wrote:
> Add support for X403 format.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 5 +
> 1 file changed, 5 inser
quot; {
> */
> #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1')
>
> +/* 3 plane non-subsampled (444) YCbCr
/*
* 3 plane non-subsampled (444) YCbCr
Reviewed-by: Laurent Pinchart
> + * 10 bpc, 30 bits per sample image dat
f (layer->drm_fmt->format == DRM_FORMAT_Y8 ||
> + layer->drm_fmt->format == DRM_FORMAT_Y10_P32) {
> + coeffs = csc_sdtv_to_rgb_yonly_matrix;
> + offsets = csc_sdtv_to_rgb_yonly_offsets;
> + } else if (layer->drm_fmt->is_yuv) {
> coeffs = csc_sdtv_to_rgb_matrix;
> offsets = csc_sdtv_to_rgb_offsets;
> } else {
--
Regards,
Laurent Pinchart
Hi Tomi,
Thank you for the patch.
On Wed, Mar 26, 2025 at 03:22:51PM +0200, Tomi Valkeinen wrote:
> Add support for XV15 & XV20 formats.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 10 ++
&g
s right, but I have a hard time validating it, as I
think the corresponding figures in UG1085 are incorrect (they show a
8bpp format as far as I can tell). Do I assume correctly that you've
tested the formats ?
> + */
> +#define DRM_FORMAT_XV15 fourcc_code('X', 'V', '1', '5') /* 2x2
> subsampled Cr:Cb plane 2:10:10:10 */
> +#define DRM_FORMAT_XV20 fourcc_code('X', 'V', '2', '0') /* 2x1
> subsampled Cr:Cb plane 2:10:10:10 */
> +
> /*
> * 2 plane YCbCr
> * index 0 = Y plane, [7:0] Y
--
Regards,
Laurent Pinchart
Tested on a
> > > Renesas GrayHawk board (R-Car V4M) by using a wrong I2C address and by
> > > not enabling RuntimePM for the device.
> >
> > What do you mean by not enabling runtime PM for the device ?
>
> I left out pm_runtime_get() before regmap_read_bulk().
--
Regards,
Laurent Pinchart
.bpp = 8,
> + .planes = 1,
> + .hsub = 1,
hsub isn't used in the driver, should it be removed (in a separate patch
of course) ? Or is that a sign there's a bug somewhere ?
Actually, bpp isn't used either. Biju, could you look into this, and
che
The ID string is stored backwards */
> + if (strncmp(id_buf, "68ISD ", ARRAY_SIZE(id_buf)))
> + return dev_err_probe(dev, -EOPNOTSUPP, "unsupported device
> id\n");
> +
> /*
>* Break ourselves up into a collection of aux devices. The only real
>* motiviation here is to solve the chicken-and-egg problem of probe
--
Regards,
Laurent Pinchart
one bridge, right? Because the
> suggested name is not unique.
Bridges can be chained. It's highly unlikely that a chain would contain
multiple bridges of the same model, as that would be quite pointless,
but in theory it could happen.
--
Regards,
Laurent Pinchart
pace
> > implementation, etc.
>
> I can drop DRM_FORMAT_XVUY2101010 until we get it to gstreamer. I just
> had it ready, so I thought it's better to include it than leave out.
>
> Is the current gstreamer support enough for the other formats to fulfill
> the userspace requirement?
We've received a green light in the past to add formats to drm_fourcc.h
that would be used by cameras only. There's no open formal standard there, but
we have libcamera as a de-facto standard. I would assume GStreamer to be
enough for a scanout format.
--
Regards,
Laurent Pinchart
On Wed, Feb 19, 2025 at 07:28:44PM +0200, Dmitry Baryshkov wrote:
> On Wed, Feb 19, 2025 at 05:08:40PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2025 at 04:47:26PM +0200, Tomi Valkeinen wrote:
> > > Hi,
> > >
> > > On 18/02/2025 05:26, Dmitry Baryshkov
urrently there can be at most one bridge in a chain that sets
> + * this bit. This is to simplify corresponding glue code in connector
> + * drivers. Having both HDMI and DisplayPort bridges in the same bridge
> + * chain is also not allowed.
> + */
> + DRM_BRIDGE_OP_DisplayPort = BIT(5),
The OP bits are not supposed to describe tbe type of bridge, but the
operations it implements. I see quite a bit of duplication between HDMI
and DisplayPort in this patch. Can we have a single bit named after the
feature that you want to support ? The bridge_hdmi and bridge_dp fields
should also be merged into a single one.
> };
>
> /**
>
--
Regards,
Laurent Pinchart
err_probe(&pdev->dev, ret, "failed to get
> HDMI +5V Power regulator\n");
> + if (ret < 0) {
> + dev_err_probe(
> + &pdev->dev, ret,
> + "failed to get HDMI +5V
ayer->dmas[i];
> struct dma_async_tx_descriptor *desc;
> + unsigned int width, height;
I'd got with one variable per line.
Reviewed-by: Laurent Pinchart
> dma_addr_t dma_addr;
>
> + width = drm_forma
width(info, plane) *
drm_format_info_block_height(info, plane)
in a local variable to avoid computing it twice ?
> + pr_warn("unable to return an integer bpp\n");
It would be nice to print the warning in the context of the drm device,
but we don't have
rnel NULL
> pointer dereference error.
>
> Fixes: 3ec5c1579305 ("drm: xlnx: zynqmp_dpsub: Add DP audio support")
> Signed-off-by: Charles Han
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp_audio.c | 4
> 1 file changed, 4 insertions(+
dp->config.bpp);
Could we use curly braces even for single-statement scopes ?
scoped_guard(mutex, &dp->lock) {
rate = zynqmp_dp_max_rate(dp->link_config.max_rate,
dp->link_config.max_lanes,
: Sean Anderson
> Cc: Tomi Valkeinen
> Fixes: 28edaacb821c ("drm: zynqmp_dp: Add debugfs interface for compliance
> testing")
> Signed-off-by: Bart Van Assche
> Reviewed-by: Sean Anderson
> Signed-off-by: Sean Anderson
Reviewed-by: Laurent Pinchart
> ---
&
AINERS | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ed86d884ee0d..5b1bf5fd56fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7760,7 +7760,8 @@ F: include/uapi/drm/tegra_drm.h
>
> DRM DRIVE
Hi Nicolas,
On Mon, Jan 27, 2025 at 09:43:23AM -0500, Nicolas Dufresne wrote:
> Le lundi 27 janvier 2025 à 08:07 +0200, Laurent Pinchart a écrit :
> > On Fri, Jan 24, 2025 at 06:12:24PM -0300, Leonardo Brás wrote:
> > > On Fri, 2025-01-24 at 10:45 -0500, Nicolas Dufresne
On Fri, Jan 24, 2025 at 06:12:24PM -0300, Leonardo Brás wrote:
> On Fri, 2025-01-24 at 10:45 -0500, Nicolas Dufresne wrote:
> > Le vendredi 24 janvier 2025 à 15:00 +0200, Laurent Pinchart a écrit :
> > > On Fri, Jan 24, 2025 at 01:52:03PM +0100, Mauro Carvalho Chehab wrote:
>
gt;
> This is definitely NOT "lots of flexibility".
>
> Are you dead seriously claiming that DevOps engineers could not handle
> well defined CI scripts and bind to whatever CI makes sense to them?
> o_O
>
> > BTW, here's the talk we gave at last year's LPC regarding current use of
> > GitLab in the kernel and surrounding community:
> >
> > https://lpc.events/event/18/contributions/1728/
>
> This patch set should make the case, not an old presentation.
--
Regards,
Laurent Pinchart
On Fri, Jan 24, 2025 at 01:52:03PM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 24 Jan 2025 10:12:50 +0200 Laurent Pinchart escreveu:
>
> > > It's been a few years since I first thought on finding a good way of
> > > helping
> > > kernel developers testing
ary services
in the kernel documentation ?
> Could you please apply it on top of your tree?
> Some stuff changed places, but I can send a v2 with that fix if you want.
>
>
> While I have yet to review this v2 patchset, I applied it on my repo for
> testing, and cherry-picked the patch on above link, triggering a Pipeline:
>
> https://gitlab.com/linux-kernel/linux/-/pipelines/1638955600
>
> It seems to be working fine, please check it, as you may be more used to the
> results.
>
> Thanks!
> Leo
--
Regards,
Laurent Pinchart
oes this seem like something worth pursuing to others? I've been trying
> to decide how to best move the allocation constraints efforts forward,
> so it's potentially something I could put some time into this year.
It's a fairly interesting idea I hadn't thought of.
My limited experience with all the graphics protocols and their history
means I have had limited exposure to the pain that communicating
modifiers everywhere has generated. As a result, I would have (perhaps
naively) tried to design a new mechanism. Using modifiers as a transport
mechanism is clearly a hack, but it may be a clever one. It seems worth
experimenting with it at least.
After reading the whole thread, I however wonder if this will be
backward compatible. If two devices expose a constraint that ends up
being encoded in the same binary form in a modifier (let's say for
instance the same pitch alignment), isn't there a risk that an
application not aware of this new scheme will pick that common modifier
when intersecting the modifiers list as done today, without realizing
it's not a real modifier ?
--
Regards,
Laurent Pinchart
agree with your concern in general, AFAIK there's no other
> solution for this even on the horizon, after years of talking about
> it. The solution proposed here seems like an acceptable stop gap,
> assuming it won't result in a gazillion linear modifiers.
Flipping that argument, the reason why we still have no solution is
because we've constantly accepted stop-gap measures. Maybe it's time to
stop. It may feel a bit unfair to Marek that everybody until know got
away with hacks, but I don't think he would be left alone designing a
proper solution.
--
Regards,
Laurent Pinchart
t
that to be the majority case, but I can't rule it out either. There's
also the issue that, even if the devices support configurable pitches,
the drivers may not implement it. That's fixable, but hardcoding the
pitch to 256 bytes without fixing that would be a regression.
--
Regards,
Laurent Pinchart
very sure and might be wrong. So other peoples
> can override me words.
>
> > Everyone agrees that CREATE_DUMB is not the best ioctl to allocate
> > buffers, and one can't consider it to work identically across the
> > platforms. But it's what we have and what has been used for ages.
>
> Yeah, your request are not unreasonable. It can be seen as a kind of rigid
> demand.
> Since GEM DMA helpers doesn't export an more advanced interface to userspace
> so far.
> As a result, drivers that employing GEM DMA has no other choice, but to abuse
> the
> dumb buffer API to do allocation for the more complex format buffers.
>
> The dumb buffer API doesn't support to specify buffer format, tile status and
> placement etc. The more advance drivers has been exposed the xxx_create_gem()
> to user-space. It seems that a few more experienced programmers hint us to
> create an new ioctl at above thread, so that we can keep employing simple API
> to do simple things and to suit complex needs with the more advanced APIs.
I'd really like to explore adding new ioctls to exposure memory
allocation constraints, and allocating the memory itself from DMA heaps.
--
Regards,
Laurent Pinchart
On Thu, Jan 16, 2025 at 12:07:49PM +0200, Tomi Valkeinen wrote:
> On 16/01/2025 11:38, Laurent Pinchart wrote:
> > On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> >> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> >>> On Wed, 15 Jan
On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is t
need a standard ioctl that can create
linear YUV buffers. I've been told many times that DRM doesn't want to
standardize buffer allocation further than what CREATE_DUMB is made for.
Can we reconsider this rule then ?
--
Regards,
Laurent Pinchart
e: 'oneOf'
> conditional failed, one must be fixed:
> ['fsl,imx7d-mipi-dsim', 'fsl,imx8mm-mipi-dsim'] is too long
>
> Signed-off-by: Alexander Stein
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/bridge/samsung,mipi-dsim.yam
/dts/nxp/imx/imx7s-mba7.dtb: iomuxc-gpr@3034: 'csi-mux' does
> not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id:
> http://devicetree.org/schemas/soc/imx/fsl,imx-iomuxc-gpr.yaml#
>
> Signed-off-by: Alexander Stein
Reviewed-by: Lauren
On Mon, Jan 06, 2025 at 04:36:26PM +0100, Marek Vasut wrote:
> On 1/6/25 8:05 AM, Laurent Pinchart wrote:
> > On Mon, Jan 06, 2025 at 03:48:52AM +0100, Marek Vasut wrote:
> >> On 1/6/25 12:22 AM, Laurent Pinchart wrote:
> >>> Hi Marek,
> >>
>
On Mon, Jan 06, 2025 at 03:48:52AM +0100, Marek Vasut wrote:
> On 1/6/25 12:22 AM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Sun, Jan 05, 2025 at 08:06:03PM +0100, Marek Vasut wrote:
> >> Add a flag m
(CC'ing Hans Verkuil)
On Mon, Jan 06, 2025 at 12:52:55AM +0200, Dmitry Baryshkov wrote:
> On Sun, Dec 15, 2024 at 02:38:05PM +0200, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > Thank you for the patch.
> >
> > On Sun, Dec 15, 2024 at 01:09:08PM +0200, Dm
; > drivers/gpu/drm/tegra/hdmi.c | 2 +-
> > drivers/gpu/drm/tegra/sor.c | 2 +-
> > drivers/gpu/drm/vc4/vc4_txp.c| 2 +-
> > drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 +-
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
> > include/drm/display/drm_hdmi_state_helper.h | 2 +-
> > include/drm/drm_encoder_slave.h | 2 +-
> > include/drm/drm_modeset_helper_vtables.h | 4 ++--
> > 71 files changed, 92 insertions(+), 93 deletions(-)
> > ---
> > base-commit: 4176cf5c5651c33769de83bb61b0287f4ec7719f
> > change-id: 20241115-drm-connector-mode-valid-const-ae3db0ef6cb7
--
Regards,
Laurent Pinchart
...
>
> ports {
> port@1 {
> hdmi_tx_out: endpoint {
> remote-endpoint = <&hdmi_connector_in>;
> };
> };
> };
> };
> ```
Are there any in-tree DT sources that use the old bindings ?
> Signed-off-
On Thu, Jan 02, 2025 at 05:26:50AM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 02, 2025 at 12:36:20AM +0200, Laurent Pinchart wrote:
> > On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
> > > On 12/31/24 9:31 PM, Laurent Pinchart wrote:
> > >
On Tue, Dec 31, 2024 at 10:10:51PM +0100, Marek Vasut wrote:
> On 12/31/24 9:31 PM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > Thank you for the patch.
> >
> > On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
> >> Add a flag m
kernel versions later (in commit
841281fe52a769fe, "drm: rcar-du: Drop LVDS device tree backward
compatibility").
> Signed-off-by: Marek Vasut
> ---
> Cc: Andrzej Hajda
> Cc: David Airlie
> Cc: Fabio Estevam
> Cc: Jernej Skrabec
> Cc: Jonas Karlman
> Cc: Laure
t;
> Also add the minItems and maxItems to the top level properties.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.yaml | 15
> ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
minItems: 4
> >> + maxItems: 4
> >
> > AFAIK these two additions are not needed, as they already match the
> > values defined at the top level.
>
> But if we add a new SoC, which has 5 vsps, we would need to increase the
> values in the top level. Which would then mean these are needed, and I'm
> sure adding them could be missed.
Let's keep things consistent with maxItems specified everywhere (my
preference is to not specify the items count at the top level hereas I
don't see any value in doing so, but I won't fight on that one if it's
what it takes to get the bindings merged).
--
Regards,
Laurent Pinchart
006.h | 4 +-
> > > .../gpu/drm/nouveau/include/i2c/encoder_i2c.h | 109
> > > -
> > > .../gpu/drm/nouveau/include}/i2c/sil164.h | 4 +-
> > > drivers/gpu/drm/nouveau/nouveau_connector.c| 6 +-
> > > drivers/gpu/drm/nouveau/nouveau_encoder.h | 13 +--
> > > 22 files changed, 172 insertions(+), 232 deletions(-)
> > > ---
> > > base-commit: 4176cf5c5651c33769de83bb61b0287f4ec7719f
> > > change-id: 20241214-nouveau-encoder-slave-a6dd422fa4a9
--
Regards,
Laurent Pinchart
1 - 100 of 2068 matches
Mail list logo
