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

Laurent Pinchart laurent.pinchart at ideasonboard.com
Sun Dec 9 23:52:42 UTC 2018


Hi Stefan,

(Maxime, there's a question for you below)

On Wednesday, 5 December 2018 14:21:56 EET Stefan Agner wrote:
> On 05.12.2018 11:42, 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?
> 
> I guess whatever works best, e.g. if a display controller uses the
> sample perspective, to describe its register, I would use the matching
> defines.
> 
> > 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?
> 
> If it is fine to use either one in display controllers or displays, I
> guess that is fine. I'd rather prefer a mechanical change right now, and
> do logical fixes on a per case basis. However, in this patch the
> dumb-vga-dac.c case already breaks that rule. Maybe it should be a
> separate patch?

If that's preferred I'll submit a v3 with this patch split in two. Maxime ?

-- 
Regards,

Laurent Pinchart





More information about the dri-devel mailing list