[PATCH v5 00/13] Centralize format information

[Laurent Pinchart]

On Tuesday 18 Oct 2016 15:45:14 Ville Syrjälä wrote:
> On Tue, Oct 18, 2016 at 03:33:29PM +0300, Laurent Pinchart wrote:
> > On Tuesday 18 Oct 2016 14:43:18 Ville Syrjälä wrote:
> >> On Tue, Oct 18, 2016 at 01:41:08AM +0300, Laurent Pinchart wrote:
> >>> Hello,
> >>> 
> >>> Various pieces of information about DRM formats (number of planes,
> >>> color depth, chroma subsampling, ...) are scattered across different
> >>> helper functions in the DRM core. Callers of those functions often
> >>> need to access more than a single parameter of the format, leading to
> >>> inefficiencies due to multiple lookups.
> >>> 
> >>> This patch series addresses this issue by centralizing all format
> >>> information in a single data structure (01/13). It reimplements the
> >>> existing format helper functions based on that structure (02/13) and
> >>> converts the DRM core code to use the new structure (03/13). The DRM
> >>> core now WARNs when a driver tries to query information about an
> >>> unsupported format (04/13).
> >>> 
> >>> The second part of the patch series removes the drm_fb_get_bpp_depth()
> >>> legacy function that shouldn't be used directly by drivers. It
> >>> modifies all its users to use the appropriate API instead (05/13 to
> >>> 12/13) and finally merges the function into its only caller in the DRM
> >>> core (13/13).
> >>> 
> >>> The new API is also useful for drivers as shown by the "[PATCH v2
> >>> 00/20] OMAP DRM fixes and improvements" patch series previously
> >>> posted.
> >>> 
> >>> All patches have been acked, the series is ready to be merged for
> >>> v4.10.
> >> 
> >> BTW and idea I had recently is that we could store the pointer to the
> >> format info into drm_framebuffer, and then a lot of the
> >> drm_format_...() calls could just vanish, or if the information we
> >> need isn't directly stored in the info structure we'd just need a small
> >> function that takes the entire drm_framebuffer or just the format info
> >> struct and computes what we need. Would avoid having to sprinkle
> >> drm_format_info() calls into the drivers.
> > 
> > That's a good idea. I didn't want to add that to my patch series in order
> > to avoid merge delays, but patches are certainly welcome :-)
> 
> Sure. I'll preserve the idea for a rainy day, unless someone else beats
> me to it that is.

I suppose I should expect lots of similar patch series during the Finnish 
winter then ;-)

-- 
Regards,

Laurent Pinchart