[PATCH v5 00/13] Centralize format information

[Ville Syrjälä]

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.

-- 
Ville Syrjälä
Intel OTC