Re: [PATCH v5 00/13] Centralize format information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :-)

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux