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

[Laurent Pinchart]

Hi Rob,

On Monday 02 May 2016 17:01:23 Rob Clark wrote:
> On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen wrote:
> > On 26/04/16 23:35, Laurent Pinchart wrote:
> >> The number of bits per pixel is identical for all planes, don't store
> >> multiple copies.
> > 
> > That's not true, as with NV12, Y has 8 bits per pixel and UV has 16 bits
> > per pixel. But as the subsampling is precalculated into the stride_bpp
> > (is it bytes or bits? bpp always confuses me =), the 'stride_bpp' ends
> > up being same for both planes.
> > 
> > To be honest, I'd rather go into more complex struct than simpler one.
> > The current one is already confusing, I think, and your version is too.
> > The main issue is that the sub_x is encoded into the stride_bpp. In
> > kmsxx I used this format:
> > 
> > { PixelFormat::NV12, { 2, { { 8, 1, 1, }, { 8, 2, 2 } }, } },
> > 
> > The first number is the number of planes, and for each plane, bitspp,
> > xsub and ysub. It's more verbose, but (I think) easier to understand.
> 
> 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}_chrom
> 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 ?

-- 
Regards,

Laurent Pinchart