[PATCH 2/2] drm/bridge: ti-sn65dsi83: add h/vsync-disable support

[Sverdlin, Alexander]

Hi Rob, Dmitry,

On Tue, 2025-03-11 at 15:27 +0000, Zini, Alessandro wrote:
> > > The h/vsync-disable properties are used to control whether to use or
> > > not h/vsync signals, by configuring their pulse width to zero.
> > > 
> > > This is required on some panels which are driven in DE-only mode but do
> > > not ignore sync packets, and instead require them to be low-voltage level
> > > or ground.
> > 
> > If this is required by 'some panels', then it should be a property of
> > the panel, not by the bridge itself.
> 
> I got the same, rightful objection also from Rob. I'll answer here to
> the both of you with the reasoning behind the submission of this patch.
> Actually, I waited for a while before sending this patch, because I
> originally had the same opinion. I do still have some difficulties
> drawing the line between "this is a panel property" and "this is a
> configurable feature of the bridge".
> 
> However, I have also prepared a second patch which adds support for
> configuring the LVDS near-end termination. Afterward, I found that this
> feature has already made its way in recently, so I dropped the patch.
> Arguably still, that feature could be seen in the same way as the one
> added from this patch, since a panel might require 100 Ohm, while
> another 200 Ohm. Likewise, a panel might require h/vsync signals, while
> another might require them to be zero/absent.
> 
> The TI E2E discussion I have attached to the cover letter of this patch
> series eventually made me change my mind. From my point of view, the
> discussion implies that avoiding the generation of h/vsync signals is
> indeed a (configurable) feature of the bridge, even though not
> explicitly documented in its datasheet.
> 
> Given the two reasons above, I think this patch would better fit in the
> bridge rather than in the panel (which, for context, is driven as a
> simple-panel).
> 
> > Can the panel return the mode with hsync_end = hsync_start and
> > vsync_enc = vsync_start?
> 
> I did try to set <h/vsync-len> to zero, which resulted in vsync_end =
> vsync_start and hsync_end = hsync_start, while also adjusting the other
> blanking properties. I am not sure if this is what you meant.
> However, this resulted in an issue along the pipeline, and ultimately
> caused drm_atomic_helper_wait_for_vblanks() to timeout.

the problem here is that actually we cannot model this pipeline with
the current Linux state of affairs: the bridge requires hsync/vsync signals
and the panel only works if they are always "0". With the only
solution we've found to set their length to "0" in the bridge itself.

So it's a quirk, not a proper configuration. A proper configuration would
lead to vsync/hsync missing in the whole pipeline and the bridge cannot
sync.

As I understand, currently DRM subsystem only supports different polarities
of the vsync/hsync signals along the pipeline, but not the entirely
different configuration (i.e. present/missing sync pulses for different
parts in the pipeline).

As I undestand, the bridges do not look into the panel properties directly,
but rather there is a common "mode" negotiated, but what to do if we have
different requirements along the pipeline?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com