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
