[PATCH v2 2/2] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags

[Laurent Pinchart]

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 at ideasonboard.com>
> > 
> > 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