[<prev] [next>] [day] [month] [year] [list]
Message-ID:
<MW4PR12MB71654039C6E8B9ED30AC51BDE6702@MW4PR12MB7165.namprd12.prod.outlook.com>
Date: Fri, 19 Jan 2024 05:51:25 +0000
From: "Klymenko, Anatoliy" <Anatoliy.Klymenko@....com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
"laurent.pinchart@...asonboard.com" <laurent.pinchart@...asonboard.com>,
"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
"daniel@...ll.ch" <daniel@...ll.ch>, "Simek, Michal" <michal.simek@....com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] drm: xlnx: zynqmp_dpsub: Make drm bridge
Hi Tomi,
Thanks for your response.
> Date: Wed, 17 Jan 2024 16:06:31 +0200
> From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
> To: Anatoliy Klymenko <anatoliy.klymenko@....com>,
> laurent.pinchart@...asonboard.com, maarten.lankhorst@...ux.intel.com,
> mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com,
> daniel@...ll.ch, michal.simek@....com,
> dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradeadorg,
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 1/4] drm: xlnx: zynqmp_dpsub: Make drm bridge
> discoverable
> Message-ID: <98a9f4f1-dd55-47c3-bb1b-07e201b299cd@...asonboard.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 13/01/2024 01:42, Anatoliy Klymenko wrote:
> > Assign device of node to bridge prior registering it. This will make
> > said bridge discoverable by separate crtc driver.
>
> I think a few words on why this is needed (and why it wasn't needed
> before) would be nice.
Sure. I will update.
" ZynqMP DPSUB supports 2 input modes: DMA based and live video.
In the first mode, the driver implements CRTC and DP encoder DRM bridge to
model the complete display pipeline. In this case, DRM bridge is being directly
instantiated within the driver, not using any bridge discovery mechanisms.
In the live video input mode video signal is generated by FPGA fabric and passed
into DPSUB over the connected bus. In this mode driver exposes the DP encoder as
a DRM bridge, expecting external CRTC to discover it via
drm_of_find_panel_or_bridge() or a similar call. This discovery relies on
drm_bridge.of_node being properly set.
Assign device OF node to the bridge prior to registering it. This will
make said bridge discoverable by an external CRTC driver.".
How does this sound?
>
> Other than that:
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
>
> Tomi
>
> > Signed-off-by: Anatoliy Klymenko <anatoliy.klymenko@....com>
> > ---
> > drivers/gpu/drm/xlnx/zynqmp_dp.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > index a0606fab0e22..d60b7431603f 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > @@ -1721,6 +1721,7 @@ int zynqmp_dp_probe(struct zynqmp_dpsub *dpsub)
> > bridge->ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID
> > | DRM_BRIDGE_OP_HPD;
> > bridge->type = DRM_MODE_CONNECTOR_DisplayPort;
> > + bridge->of_node = dp->dev->of_node;
> > dpsub->bridge = bridge;
> >
> > /*
>
>
Regards
Anatoliy
Powered by blists - more mailing lists