On Mon, Oct 06, 2025 at 07:42:56PM +0300, Cristian Ciocaltea wrote:
> On 10/6/25 7:25 PM, Laurent Pinchart wrote:
> > On Mon, Oct 06, 2025 at 02:19:24PM +0300, Dmitry Baryshkov wrote:
> >> On Mon, Oct 06, 2025 at 02:55:37AM +0300, Laurent Pinchart wrote:
> >>
ARCH_RZG2L dependency with ARCH_RENESAS to allow the driver
> to be built on all relevant Renesas SoCs.
>
> Signed-off-by: Lad Prabhakar
Happy to see the driver getting used more widely. Coming-of-age is
always a special time, for software too :-)
Reviewed-by: Laurent Pinchart
> ---
uot;drm/rcar-du: dsi: Implement DSI command support")
> Signed-off-by: Marek Vasut
Reviewed-by: Laurent Pinchart
> ---
> Cc: David Airlie
> Cc: Geert Uytterhoeven
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Magnus Damm
> Cc: Maxime
no functional change, because the driver only
> makes use of DRM_MODE_FLAG_P[HV]SYNC to divert from the default
> active-low polarity.
>
> Reported-by: Laurent Pinchart
> Closes:
> https://lore.kernel.org/all/20250923132616.gh20...@pendragon.ideasonboard.com/
> Fixes: a411558cc143
On Wed, Sep 24, 2025 at 04:36:00AM +0200, Marek Vasut wrote:
> On 9/24/25 3:18 AM, Sebastian Reichel wrote:
>
> Hello Sebastian,
>
> > On Tue, Sep 23, 2025 at 04:26:16PM +0300, Laurent Pinchart wrote:
> >> I wonder if the DRM_MODE_FLAG_P[HV]SYNC flags are always
> Do not convert bits and bitfields to BIT() and GENMASK() yet, to be
> consisten with the current style. Conversion to BIT() and GENMASK()
> macros is done at the very end of this series in the last two patches.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Laurent Pincha
> Signed-off-by: Marek Vasut
> ---
> Cc: David Airlie
> Cc: Geert Uytterhoeven
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Magnus Damm
> Cc: Maxime Ripard
> Cc: Simona Vetter
> Cc: Thomas Zimmermann
> Cc: Tomi Valk
series in the last two patches.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: David Airlie
> Cc: Geert Uytterhoeven
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Magnus Damm
> Cc: Maxime Ripard
> Cc: Simona Vetter
> Cc: Thom
ith the current style. Conversion to BIT() and GENMASK()
> macros is done at the very end of this series in the last two patches.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: David Airlie
> Cc: Geert Uytterhoeven
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Cc: Maarten
gt; Cc: David Airlie
> Cc: Geert Uytterhoeven
> Cc: Kieran Bingham
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Magnus Damm
> Cc: Maxime Ripard
> Cc: Simona Vetter
> Cc: Thomas Zimmermann
> Cc: Tomi Valkeinen
> Cc: dri-devel@lists.freedesktop.org
> Cc: li
hat's not worth it
> here, it would only add noise into the code.
I'm a bit surprised. I don't mind much as I don't work on this driver
myself, but for what it's worth I would find a switch statement to be
more readable too. Coding style is of course a matter of personal
preference in many cases.
--
Regards,
Laurent Pinchart
the code may still serve as an example for new drivers.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_lvds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas
ane_state variable, like done for new_plane_state in
for_each_new_plane_in_state() ? Or is it expected that drivers will
always make use of it.
Reviewed-by: Laurent Pinchart
> /**
> * for_each_new_plane_in_state - iterate over all planes in an atomic update
> * @__state: &struc
his hook is optional.
>*/
> int (*atomic_commit_setup)(struct drm_atomic_state *state);
> +
> + /**
> + * @atomic_reset:
> + *
> + * This hook is used to create the initial @drm_atomic_state.
> + * It's used by drm_mode_config_reset().
> + *
> + * The default implementation will create an empty one, but
> + * drivers can provide an alternative implementation to, for
> + * example, read the initial state from hardware to implement
> + * flicker-free and / or faster boot.
> + */
> + void (*atomic_reset)(struct drm_device *dev);
> };
>
> #endif
>
--
Regards,
Laurent Pinchart
e we almost never care about what the new
> state looks like when we commit a new state, but we're about to change
> that.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic.c| 45
>
reserved ? Or objects that have no
old state ? I assume it's the latter, a clarification would be useful
here. With that,
Reviewed-by: Laurent Pinchart
> In order to make it work, let's first test if the state pointer isn't
> NULL before calling atomic_destroy_state on it.
&g
truct drm_private_state
> *state)
> +{
> + memset(state, 0, sizeof(*state));
As Thomas mentioned, the memset is likely not needed.
Reviewed-by: Laurent Pinchart
> + state->obj = obj;
> +}
> +
> /**
> * __drm_atomic_helper_private_obj_duplicate
;bridge: %s", drm_get_connector_type_name(bridge->type));
It would be nice to identify the bridge more precisely, but bridges have
no object ID :-/ The raw pointer may not be very useful. I wonder if we
should give an object ID to drm_private_obj instances, even if we don't
expose them to userspa
cs->atomic_destroy_state(obj,
> > state->private_objs[i].state);
> > state->private_objs[i].ptr = NULL;
> > state->private_objs[i].state = NULL;
> > state->private_objs[i].old_state = NULL;
--
Regards,
Laurent Pinchart
obj) /* Only to avoid unused-but-set-variable
> warning */, \
> (old_obj_state) = (__state)->private_objs[__i].old_state,
> 1); \
>(__i)++)
>
> /**
> * for_each_new_private_obj_in_state - iterate over all private objects in
> an atomic update
--
Regards,
Laurent Pinchart
it is checked. If the check is successful, the
state update is then committed.
> > + * drm_atomic_helper_swap_state() which will turn the new state into
> > + * the active state. Doing so involves updating the entity state
> > + * pointer (&drm_crtc.state or simil
tch depends on a header file introduced by the second patch,
> so I will need to provide an immutable branch containing the first
> two patches (probably/hopefully based on v8).
--
Regards,
Laurent Pinchart
why this
> Design is good for drm_writeback_connector.
I'm busy, I'll try to reply in the next few days.
> > > > I plan to add drm_connector_dp in a similar way, covering DP needs
> > > > (currently WIP).
--
Regards,
Laurent Pinchart
macro. I
> would be tempted to remove the bits set to 0, that's probably the real
> discussion that should happen here. But that would also be a much bigger
> patch. What do you think ?
For what it's worth, for single-bit register fields, I usually define a
single macro. I understand it's usually a coding style preference.
--
Regards,
Laurent Pinchart
On Mon, Aug 11, 2025 at 01:22:30PM +0300, Dmitry Baryshkov wrote:
> On Mon, Aug 11, 2025 at 12:44:29PM +0300, Laurent Pinchart wrote:
> > On Mon, Aug 11, 2025 at 02:57:00PM +0530, Suraj Kandpal wrote:
> > > Some drivers cannot work with the current design where the connector
*/
> - spinlock_t fence_lock;
> - /**
> - * @fence_seqno:
> - *
> - * Seqno variable used as monotonic counter for the fences
> - * created on the connector's timeline.
> - */
> - unsigned long fence_seqno;
> - /**
> - * @timeline_name:
> - *
> - * The name of the connector's fence timeline.
> - */
> - char timeline_name[32];
> -};
> -
> /**
> * struct drm_writeback_job - DRM writeback job
> */
> @@ -131,10 +71,16 @@ struct drm_writeback_job {
> void *priv;
> };
>
> +static inline struct drm_connector *
> +drm_writeback_to_connector(struct drm_writeback_connector *wb_connector)
> +{
> + return container_of(wb_connector, struct drm_connector, writeback);
> +}
> +
> static inline struct drm_writeback_connector *
> drm_connector_to_writeback(struct drm_connector *connector)
> {
> - return container_of(connector, struct drm_writeback_connector, base);
> + return &connector->writeback;
> }
>
> int drm_writeback_connector_init(struct drm_device *dev,
--
Regards,
Laurent Pinchart
n;
>
> @@ -246,10 +250,10 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> cfg->mem[i] = sg_dma_address(rjob->sg_tables[i].sgl)
> + fb->offsets[i];
>
> - drm_writeback_queue_job(&rcrtc->writeback, state);
> + drm_writeback_queue_job(&rcrtc->connector.writeback, state);
> }
>
> void rcar_du_writeback_complete(struct rcar_du_crtc *rcrtc)
> {
> - drm_writeback_signal_completion(&rcrtc->writeback, 0);
> + drm_writeback_signal_completion(&rcrtc->connector.writeback, 0);
> }
--
Regards,
Laurent Pinchart
dersson
> Cc: Konrad Dybcio
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: Dmitry Baryshkov
Makes sense.
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/display-connector.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/g
On Mon, Aug 04, 2025 at 11:24:58PM +0200, sukrut heroorkar wrote:
> On Sun, Aug 3, 2025 at 6:56 PM Laurent Pinchart wrote:
> > On Sat, Aug 02, 2025 at 06:13:05PM +0200, Sukrut Heroorkar wrote:
> > > drm: drm_bridge: fix missing parameter documentation
> > >
> >
> *
> * If the bridge supports output detection, as reported by the
> * DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect for
> the
--
Regards,
Laurent Pinchart
ant to enable zero-copy between
> > DMA capable accelerators. You can simply import the V4L2 buffer into a
> > GL texture using EGL_EXT_image_dma_buf_import. Using this path you
> > don't need to bother with the cache at all, as the GPU will directly
> > read the video buffers from RAM.
>
> Yes, so GPU will read video buffer from RAM, then debayer it, and then
> what? Then I need to store a data into raw file, or use CPU to turn it
> into JPEG file, or maybe run video encoder on it. That are all tasks
> that are done on CPU...
--
Regards,
Laurent Pinchart
c4/vc4_v3d.c
> index bb09df5000bd..11ec7e913974 100644
> --- a/drivers/gpu/drm/vc4/vc4_v3d.c
> +++ b/drivers/gpu/drm/vc4/vc4_v3d.c
> @@ -153,7 +153,6 @@ vc4_v3d_pm_put(struct vc4_dev *vc4)
>
> mutex_lock(&vc4->power_lock);
> if (--vc4->power_refcount == 0) {
> - pm_runtime_mark_last_busy(&vc4->v3d->pdev->dev);
> pm_runtime_put_autosuspend(&vc4->v3d->pdev->dev);
> }
And here you can drop the curly braces. With that,
Reviewed-by: Laurent Pinchart
> mutex_unlock(&vc4->power_lock);
--
Regards,
Laurent Pinchart
Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Cc: Laurent Pinchart
> Reviewed-by: Thomas Zimmermann
> Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 ++--
> .../gpu/drm/amd/displa
t;
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Andy Yan
> Cc: Oleksandr Andrushchenko
> Cc: virtualizat...@lists.linux.dev
> Cc: spice-de...@lists.freedesktop.org
> Cc: Laurent Pinchart
> Reviewed-by: Thomas Zimm
en
> Cc: Dave Stevenson
> Cc: "Maíra Canal"
> Cc: Raspberry Pi Kernel Maintenance
> Cc: Dmitry Osipenko
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: Zack Rusin
> Cc: Broadcom internal kernel review list
>
> Cc: Oleksandr Andrushchenko
> Cc: amd-...@lists.freedeskto
On Mon, Jun 30, 2025 at 12:52:48PM +0200, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 12:33:35PM +0300, Laurent Pinchart wrote:
> > On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> >
On Mon, Jun 30, 2025 at 11:29:08AM +0200, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 12:11:56PM +0300, Laurent Pinchart wrote:
> > On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> >
On Mon, Jun 30, 2025 at 10:27:55AM +0200, Maxime Ripard wrote:
> On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> > On 27-06-2025 20:19, Laurent Pinchart wrote:
> > > On Fri, Jun 27, 2025 at 04:50:46PM +0200, Mike Looijmans wrote:
> > > > XRGB
On Mon, Jun 30, 2025 at 10:03:16AM +0200, Mike Looijmans wrote:
> On 27-06-2025 20:19, Laurent Pinchart wrote:
> > On Fri, Jun 27, 2025 at 04:50:46PM +0200, Mike Looijmans wrote:
> >> XRGB is the default mode that Xorg will want to use. Add support
> >> for thi
et to full opacity.
> }, {
> .drm_fmt = DRM_FORMAT_RGBA,
> .buf_fmt= ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_ABGR,
--
Regards,
Laurent Pinchart
ttle endian */
> >
> > +/* 48 bpp RGB */
> > +#define DRM_FORMAT_RGB161616 fourcc_code('R', 'G', '4', '8') /* [47:0]
> > R:G:B 16:16:16 little endian */
> > +#define DRM_FORMAT_BGR161616 fourcc_code('B', 'G', '4', '8') /* [47:0]
> > B:G:R 16:16:16 little endian */
> > +
> > /* 64 bpp RGB */
> > #define DRM_FORMAT_XRGB16161616fourcc_code('X', 'R', '4', '8') /*
> > [63:0] x:R:G:B 16:16:16:16 little endian */
> > #define DRM_FORMAT_XBGR16161616fourcc_code('X', 'B', '4', '8') /*
> > [63:0] x:B:G:R 16:16:16:16 little endian */
--
Regards,
Laurent Pinchart
On Tue, Jun 24, 2025 at 10:46:26AM +, dharm...@microchip.com wrote:
> On 24/06/25 4:12 pm, Laurent Pinchart wrote:
> > On Tue, Jun 24, 2025 at 02:54:14PM +0530, Dharma Balasubiramani wrote:
> >> Drop the drm_panel field of the mchp_lvds struct as it is unused.
> >>
The above code seems unneeded now, I think you can drop it too.
> -
> - lvds->panel = of_drm_find_panel(port);
> of_node_put(port);
>
> - if (IS_ERR(lvds->panel))
> - return -EPROBE_DEFER;
> -
> lvds->panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
>
> if (IS_ERR(lvds->panel_bridge))
--
Regards,
Laurent Pinchart
_attach,
> - .enable = mchp_lvds_enable,
> - .disable = mchp_lvds_disable,
> + .atomic_pre_enable = mchp_lvds_atomic_pre_enable,
> + .atomic_enable = mchp_lvds_atomic_enable,
> + .atomic_disable = mchp_lvds_atomic_disable,
> + .atomic_post_disable = mchp_lvds_atomic_post_disable,
> };
>
> static int mchp_lvds_probe(struct platform_device *pdev)
>
> ---
> base-commit: 4325743c7e209ae7845293679a4de94b969f2bef
> change-id: 20250618-microchip-lvds-b7151d96094a
--
Regards,
Laurent Pinchart
On Wed, Jun 18, 2025 at 03:50:11AM +, dharm...@microchip.com wrote:
> On 18/06/25 5:06 am, Laurent Pinchart wrote:
> > On Tue, Jun 17, 2025 at 10:36:34AM -0500, Anusha Srivatsa wrote:
> >> Hey folks,
> >>
> >> Can someone please explain why the drive
nywhere?
>
> I bumped into this while working on converting of_drm_find_panel() callers and
> the lvds->panel usage in this driver felt off. Am I missing something?
That doesn't seem needed.
By the way, please use plain text when posting to kernel mailing lists.
--
Regards,
Laurent Pinchart
gt; Cc: Laurent Pinchart
> Cc: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_kms.c
> b/drivers/g
gt; Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_kms.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
> b/drivers/gpu/drm/xlnx/zynqmp_kms.c
>
s")
While at it, I would also remove the parentheses. With that,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/d
;[PATCH v6 01/12] dt-bindings: display: renesas, rzg2l-du: Add support
for RZ/V2H(P) SoC"),
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/renesas,rzg2l-du.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devic
_bpp(dsi->format);
> - hsfreq = mode->clock * bpp / dsi->lanes;
> -
> - ret = pm_runtime_resume_and_get(dsi->dev);
> - if (ret < 0)
> - return ret;
> -
> - clk_set_rate(dsi->vclk, mode->clock * 1000);
> + vclk_ra
On Mon, Jun 02, 2025 at 11:09:51AM +0100, Lad, Prabhakar wrote:
> On Mon, Jun 2, 2025 at 10:42 AM Laurent Pinchart wrote:
> > On Fri, May 30, 2025 at 05:58:59PM +0100, Prabhakar wrote:
> > > From: Lad Prabhakar
> > >
> > > Update the RZ/G2L MIPI DSI driver
lock isn't used in this series, it will only be used when you will
submit the next version of "[PATCH v4 15/15] drm: renesas: rz-du:
mipi_dsi: Add support for RZ/V2H(P) SoC". As this patch doesn't bring
any used feature, I'm tempted to say it could be bundled with the
RZ/V2H(P) support patch.
> dsi->rstc = devm_reset_control_get_optional_exclusive(dsi->dev, "rst");
> if (IS_ERR(dsi->rstc))
> return dev_err_probe(dsi->dev, PTR_ERR(dsi->rstc),
--
Regards,
Laurent Pinchart
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
1 - 100 of 2121 matches
Mail list logo
