DRM connector/encoder/crtc framework documentation?

[Matt Sealey]

On Tue, Apr 20, 2010 at 11:41 AM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Tue, 20 Apr 2010 10:56:41 -0500

Hi Jesse,

> Matt Sealey <matt at genesi-usa.com> wrote:
>
>> 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.

Well, it's appreciated, but unfortunately it does not really allay any
of the fears I have about writing this stuff. The parts I am
interested in just aren't documented (a small overview of which
component is what, I already had 90% down anyway).

>> 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.

Okay so I got that bit right.

>> 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.

Okay so if I have an HDMI socket on the board, I should always give back HDMI?

The problem is when it's an HDMI connector with a DVI sink. We have to
detect that really, but otherwise, the encoder is always on that
display bus, and if I give the IPU a framebuffer pointer, it will scan
it out to this one encoder. There are actually two buses and two
encoders (one HDMI and one VGA) and the encoders are fixed to an SoC
i2c bus.. so I can drive the two independently.

What I'm not sure about in the CRTC is how I manage that. In the
current driver it sets up 3 framebuffers (0, 1, 2) which correspond to
display bus 1 (HDMI on an SII9022A), display bus 2 (VGA, a Myson
Century abomination), and the video overlay (which is automatically
composited on top of the other two displays - or maybe just one of
them actually - when it is "unblanked")

The way the current framebuffer driver works is to init the encoder as
a completely seperate i2c driver and then call some of the framebuffer
functions (i.e. the encoder driver tells the crtc what to do,
otherwise it would just initialize some DMA channels, a dummy
framebuffer, and sit there). The i2c driver knows which framebuffer
*name* it connects to (DISP1 BG, DISP2 BG etc.) and searches for it
and then inits the display based on that framebuffer object (par or
var or something). I want to get rid of that monstrosity..

I guess what I am looking for is something "For Dummies" like a
flowchart of how DRM driver components talk to each other, or one of
those rats nest graphs like they did for Apache's syscalls:

http://www.visualcomplexity.com/vc/project.cfm?id=392

Just so I have some kind of instant reference of "what does this do?",
check the diagram and see that this component uses this component via
this function to do this thing. Reading through the source code is
incredibly complex and implemented differently enough across drivers
to be somewhat confusing if you've not written the Intel and Radeon
(or Nouveau) drivers yourself, especially if you're trying to do
something MUCH simpler (a single graphics controller with fixed
features and no chance of the manufacturer bringing out a newer card
that does fancy new things on this chip line - the nouveau directory
is a monster, and while it does what I want, doing it for 15 major
chip revisions is overdoing it in my case).

I have an allergy to laborious cross-referencing of text and my heart
broke when I saw [insert typical diagram here] :)

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

Well all I can think of is that the overlay, and two framebuffers need
to be allocated. Actually having objects and execution buffers isn't
required on this simple a display, it's just kind of my dream for the
framebuffer to know which i2c devices control it's display, and call
those to actually set up the display (instead of the i2c driver
forcing the framebuffer driver to do what it needs to do). A GEM
object for each framebuffer would work. More advanced stuff for the
IPU like blending planes could be layered on top of GEM too (all you
have to do is make your planes and have some ioctls for it.. which
Freescale already managed to implement on the framebuffer. GEM just
makes it easier to manage the objects :)

What I think I can manage is getting the CRTC and GEM parts done
because a vast majority of it is done in the current driver which is
going to be cut and paste into place anyway. But since Radeon and
Intel fbs have custom i2c buses, there is a lot of i2c bus setup
flying around, and not much probing (Intel don't change the basic
operation of their controller hubs very often it seems, so things are
assumed to be there at least in the example, there's a VGA connector
and a DAC encoder, and at least I get the order of creation:
connector, encoder, attach connector to encoder)

I saw the nouveau driver got it's little i2c slave encoder thing into
the tree, is this what I could/should be basing things on? Is there a
simpler GEM-aware DRM driver with framebuffer support (i.e. not
drivers/video but drivers/gpu/drm/ somewhere, like intel_fb) I could
be looking at that very much simplifies it? Is there any work being
done on a skeleton?

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.