[PATCH RFC v4 0/3] Armada DRM driver
Russell King - ARM Linux
linux at arm.linux.org.uk
Sat Jun 29 15:52:10 PDT 2013
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
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.)
- 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
- 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
- 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
- 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
- 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.
- 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.
More information about the dri-devel