Quite a number of things has changed since the last revision in the core code - notably the move to use drm_plane for overlay, and the limited and restricted use of dma_buf so that gem objects can be passed to the GALCORE code and libbmm contiguous video frames can be imported into DRM. As I thought, this does require quite a number of new system calls, but the case which I care more about (vlc) doesn't pass rendered frames directly to the X server by physical address, it's not something I'm particularly concerned about - for vlc and the "normal" Xv protocol we can cache four DRM gem objects with their framebuffers pre-prepared meaning we just copy the frame and call the DRM set_plane function. What the loss of the create_phys() interface does mean is that the modified gstreamer gstbmmxvimagesink plugin will not work; it will need to be updated. I do *not* intend to support the hacky bidirectional Xv SHM hack which Marvell came up with there! I've left out the TDA998x changes and the final patch which depends on those changes which add the HDMI output for the cubox, so this series will be lacking the final parts of connector support. It is probable that the patch from the previous series can be trivially applied to this (or easily adapted if not.) Other changes: - the crtc exports a few attributes now for setting the colour transform mode. (CCIR601/709 to Computer vs "Studio" RGB). An automatic mode for these settings provided depending on selected resolution. - overlay has working brightness/contrast/saturation settings, but not hue - not worked that bit out yet. - hardware ARGB cursor support only in this version. - backend ops are now called variants, because the structure started to contain other stuff other than just function pointers. Armada510 backend moved to a separate file. - features requiring the SPU_ADV_REG (only present on Armada 510) can be disabled by the variant structure - such as interlace and ARGB cursor. - use of page_alloc() reduced down to 8K, enough to store the hardware cursor. This is all that that allocation was really used for anyway. - now uses a common kfifo queue to free used framebuffers at the appropriate time, both from the crtc code and the drm_plane code, rather than having this logic in several places. kfifo is a weird API and there's a note in the driver about that. - framebuffers now carry their configuration with them, to save having the pixel format decode scattered in several places in the driver. - power down FIFOs and RAMs not being used, and keep them powered down where possible. - minimum framebuffer size added, moved out from the X server driver. - maximum horizontal resolution dropped to 1920 to avoid a potential problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.) - protection preventing various gem objects being used in unexpected ways added - eg, you can't create a framebuffer from a cursor gem object or an imported object which is non-contiguous. - full range of colorkey modes for video supported (hey, it's just drm plane properties!) - loads of smaller cleanups, and a number of checkpatch fixes. Things left to do, in no particular order: - Creation of planar YUV formatted framebuffers - I suspect the planar YUV formats are not supported for graphic framebuffers even though Marvell document the register settings. (Where do you program the base addresses of the U and V planes?) Not a high priority as Vmeta produces UYVY encoded frames and it's more efficient to keep the native format. - Gamma support if anyone cares. Again, not high priority. - Resolution of the clocking conundrum. - Resolution of the DT specification conundrum (super-device?) - Specification of DRM connectors (DT but how?), their configuration, what they're connected to and what fixed format(s) they support. - CMA or no CMA - I've added a comment pointing out additional concerns about how to get the physical address from CMA. I think for most platforms this driver will be used on, the device address and physical address will be the same, but _conceptually_ they have never been the same in the kernel. - DCON support... I have no use for this, and the information in my documentation is pretty damned poor, so much so that I'm reluctant to try prodding around with it, especially as some of it is self-contradictory. Anyone who really cares about this can look at the issues there. Stuff omitted: - the DRM refcounting bug fix which breaks the i915 driver (but without it, booting with this driver results in a leaked refcount on the framebuffer thanks what I consider to be a bug in the DRM crtc code.) So don't boot this without something reporting itself as being connected with a valid mode. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
