DRM connector/encoder/crtc framework documentation?
alexdeucher at gmail.com
Wed Apr 21 18:09:23 PDT 2010
On Wed, Apr 21, 2010 at 1:15 PM, Matt Sealey <matt at genesi-usa.com> wrote:
> 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
>> 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?
Yes. Connectors should be what the user sees on the board.
> 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.
This sounds pretty straight forward. In your case you would expose 2
connectors (VGA and HDMI) and 2 encoders (digital TMDS, and analog
DAC). Ideally, internally the driver would handle any changes
necessary to use an DVI monitor on an HDMI connector which should be
pretty minimal. There are drm helper functions to detect an HDMI
monitor vs. DVI based on the EDID.
The driver determines what crtcs can drive which encoders and which
encoders are attached to which connectors.
> 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")
In your case it sounds like the crtc->encoder->connector paths are
hardcoded. You can enforce this by setting the possible_crtcs mask
when you set up the encoder objects.
Overlays aren't currently dealt with in any of the drm drivers in a
general manner. The radeon drm doesn't expose them with kms, and the
intel drm uses a special set of ioctls. There was some discussion a
while ago about adding a generic overlay abstraction.
> 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..
Tie your ddc i2c buses to your connector objects. Then if you've set
up the crtc and encoder restrictions properly, it should just work.
> 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:
> 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] :)
I've written a couple blog posts about the kms drm and the radeon
display hardware that might be helpful:
>>> 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)
Most of the probing is handled in the generic drm code. See
drm_crtc.c and drm_crtc_helper.c
> 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?
Unfortunately, radeon, intel, and nouveau are pretty much it at the
moment. It would be nice to have a relatively simple driver as a
reference. Perhaps your driver. We are happy to answer any questions
you have during the driver bring up.
> Matt Sealey <matt at genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel