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

[Tomi Valkeinen]

On 03/05/16 00:01, Rob Clark wrote:
> On Mon, May 2, 2016 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> Hi Laurent,
>>
>> 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}_chroma_subsampling()/etc)

Indeed, I think we can remove all but the DRM -> DSS format mapping.

Btw, what is "cpp" short from?

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160503/56e7eef5/attachment.sig>