On Fri, 2025-03-07 at 08:05 +0200, Dmitry Baryshkov wrote: > On Thu, Mar 06, 2025 at 10:11:33AM +0100, A. Zini wrote: > > From: Alessandro Zini <alessandro.zini@xxxxxxxxxxx> > > > > 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. -- Alessandro
