[PATCH 02/23] drm: omapdrm: fb: Don't store format BPP for each plane

[Daniel Vetter]

On Mon, Jun 06, 2016 at 04:39:49AM +0300, Laurent Pinchart wrote:
> Hi Tomi, Rob and Daniel,
> 
> On Tuesday 10 May 2016 10:14:17 Tomi Valkeinen wrote:
> > On 09/05/16 23:57, Laurent Pinchart wrote:
> > >> fwiw, I guess a lot of data from that table could these days be
> > >> replaced w/ some of the drm format helpers
> > >> (drm_format_num_planes()/drm_format_plane_cpp()/drm_format_{horz,vert}_ch
> > >> rom a_subsampling()/etc)
> > > 
> > > I don't like those helpers as they're inefficient. Drivers often need to
> > > know multiple pieces of information about a format, and the API forces
> > > look-ups for every piece of information needed.
> > > 
> > > Would it make sense to add a drm_format_info() function that returns a
> > > pointer to a data structure that describes the format, and reimplement
> > > the existing helpers on top of that ?
> > 
> > I do like that idea.
> 
> Rob and Daniel, what do you think ?

Seems like a bikeshed, but then I don't mind bikesheds too much either.
Meh.
-Daniel

> 
> > A table implementation might possibly be faster even with the current
> > API. Those big switch-cases compile into a big pile of
> > if-else-if-else-ifs, whereas a for loop would compile into just a few
> > instructions. But just guessing here =).
> > 
> > In theory, the table could be sorted, making the lookup much faster, but
> > I'm not sure if that's worth the effort.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch