[PATCH 09/20] drm/bridge: tc358775: remove complex vsdelay calculation

[Michael Walle]

Hi Daniel,

> > To cite the datasheet on VSDELAY:
> >   During DSI link speed is slower than that of LVDS link’s, data needs
> >   to be buffer within 775XBG before outputting to prevent data from
> >   underflow. Register field VPCTRL[VSDELAY] is used to for this purpose
> >
> > This driver assumes that the DSI link speed is the pixel clock (as does
> > every DSI bridge driver), after all the LVDS clock is derived from the
> > DSI clock. Thus we know for a fact, that the DSI link is not slower than
> > the LVDS side. Just use the (sane) default value of the bridge and drop
> > the complicated calculation here.
>
> I am not convinced this is a good idea to revert to a default
> VSdelay value. I tested your patch series with RK3399 platform
> and default value (5) was not enough there. There was small data
> underflow visible, resulting in display offset. Removing this patch
> and using the original calculation formula fixed the problem.
> The calculated VSDELAY value seems to be a lot bigger than required,
> but keeps us on the safe side.

Did you use just parts of this series or did you port the "lp11
notify" mechanism to the rk3399 platform? Please keep in mind, that
this bridge doesn't really work if the reset isn't deasserted during
lp-11 mode and lots of odd things happen.

Also, do you know if you have an EEPROM attached to the bridge or
does any firmware part initialize that bridge?

> It looks that hback-porch value for panel is used also on DSI link,
> effectively delaying hactive data delivered to TC358775 bridge.
> I suspect this causes the requirement for higher VSDELAY.

It was ages ago since I've worked on this bridge and extensively
tested and even measured and decoded the DSI link and the LVDS
stream. But IIRC this delay was only to compensate the difference
between the DSI clock and the LVDS clock, that is, if you push the
pixel stream slower into the bridge than the bridge is pushing it
out to the LVDS panel.

So the back porch should be irrelevant here (?!).

-michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240906/871c802d/attachment.sig>