Hi Tomi, On Wednesday, 5 December 2018 12:42:12 EET Tomi Valkeinen wrote: > On 05/12/18 10:49, Laurent Pinchart wrote: > > From: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> > > > > The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and > > DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the > > new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and > > new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them > > through the code. > > > > This effectively changes the value of the .sampling_edge bridge timings > > field in the dumb-vga-dac driver. This is safe to do as no driver > > consumes these values yet. > > When to use which? The idea is to use the flags that correspond to the side corresponding to the code. A bridge driver, in its input_bus_flags, would use the sample flags. A display controller driver would likely use the drive flags. If we later extend drm_bridge to handle polarities on the source side of the bridge, the drive flags should be used there. It also makes sense to follow the perspective described in datasheets and hardware registers. If an internal encoder is documented using the driving perspective for its input signals, usage of the drive flags is likely best. In a nutshell, use the flags that result in the simplest possible code. > Looking at the omap drivers, you use the DRIVE variant. But if the > encoder/panel is describing what it wants as input, shouldn't it use the > SAMPLE variant? I have to confess I haven't paid much attention to the omapdrm/displays/ drivers as we're in the process of removing them, but I think you're right there. For the SDI encoder, the datasheet documents polarities from a drive perspective, so I've kept that. For the DSI encoder there's no documented polarities, so I used the drive perspective there as well to remain consistent. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel