DRM connector/encoder/crtc framework documentation?

[Jesse Barnes]

On Tue, 20 Apr 2010 10:56:41 -0500
Matt Sealey <matt at genesi-usa.com> wrote:

> Hi guys,
> 
> Is there any canonical or even rough, old documentation (I noticed a
> connector/encoder structure change lately) on how the DRM
> crtc/encoder/connector framework is constructed and what the
> responsibilities of each component are in a display driver?

I put together this documentation as a start; I've been waiting on Dave
to apply the corresponding source to the tree before working on it much
more. Would be good to get additional contributors as well.

> What we have is an i.MX515 with a display controller (IPU) which can
> do video overlay and all that fancy stuff. This is the CRTC right?
> This would be setting up clocks, and managing which GEM object is the
> current framebuffer?

The CRTCs generally contain actual mode timing information, as well as
a corresponding memory object for the framebuffer.  Current drivers map
CRTCs to display/overlay planes internally.

> Implementing a GEM memory manager to allocate framebuffers and other
> objects goes under this, and then the CRTC talks to it's encoder.. but
> how does the connector come in? All I see is that it is a sort of
> abstraction for parsing EDID data such that you can find out if you're
> running HDMI ("TV mode" on a TV) or DVI-like displays ("PC mode" on a
> TV).

Connectors should correspond to physical connectors attached to your
encoders.  If your configuration is simple, you could just tie your
encoder & connector code together, instantiating specific connectors
for your encoders if dynamic reconfiguration isn't possible.

> Is there a simple skeleton (maybe a virtual or off-screen
> framebuffer?) implementing the framework so I can relieve myself of
> having to pick apart Intel and Radeon drivers and working out for
> myself why and how they differ in implementation?
> 
> BTW the other question is: for future-proofing do I use GEM or TTM or what?

The TTM core is more driver independent at this point, but it's also
more complex, so it just depends on your needs.  Check out i915_gem.c
for details on how the driver specific portion of GEM should work
(basically cache domain management, buffer tracking, and execution
buffer management).

-- 
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm.pdf
Type: application/pdf
Size: 142454 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100420/f6dbb56d/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm.xml
Type: application/xml
Size: 32573 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100420/f6dbb56d/attachment-0001.xml>