Re: [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode

[Marek Vasut]

On 4/18/23 00:24, Adam Ford wrote:
> On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut <marex@xxxxxxx> wrote:
> > On 4/17/23 13:57, Adam Ford wrote:
> > > On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut <marex@xxxxxxx> wrote:
> > > > On 4/15/23 12:41, Adam Ford wrote:
> > > > > The high-speed clock is hard-coded to the burst-clock
> > > > > frequency specified in the device tree.  However, when
> > > > > using devices like certain bridge chips without burst mode
> > > > > and varying resolutions and refresh rates, it may be
> > > > > necessary to set the high-speed clock dynamically based
> > > > > on the desired pixel clock for the connected device.
> > > >
> > > > The link rate negotiation should happen internally between the nearest
> > > > bridge and DSIM, so please add that to DRM core instead of hacking
> > > > around it by tweaking the HS clock again.
> > >
> > > I thought you tried to add something like this before and had some resistance.
> >
> > Yes, all my attempts were rejected by a single reviewer. I suspended my
> > efforts in that area for now.
> >
> > > The Pixel clock is set by the bridge already without any new code
> > > added to the DRM core..  I am just reading that value that's there,
> > > and setting the clock accordingly.  I don't see how this is a hack.
> >
> > Assume you have a DSI-to-HDMI bridge attached to your DSIM bridge, it
> > operates in non-burst mode, like ADV7533 . How would you configure the
>
> I have an ADV7535
>
> > HS clock rate for such a bridge in DT ? (hint: you cannot, because the
> > required clock comes from the EDID, which may not be available just yet)
>
> The whole idea is that you wouldn't want to or need to configure the
> clock speed in the device tree because it comes from the
> EDID->bridge->DSI.
>
> I've tested this configuration on imx8mm, imx8mn, and imx8mp and I can
> change the resolution and refresh rate on the fly and the DSI will
> automatically readjust accordingly.   If you fixed the clock in the
> device tree, you wouldn't be able to do that, and that was the point
> of this patch.

Uh, I retract my comment, I was clearly confused here and we're talking 
about the same thing.