On Tue, Oct 18, 2016 at 03:33:29PM +0300, Laurent Pinchart wrote: > Hi Ville, > > 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. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
