Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller
From: Laurent Pinchart
Date: Thu Aug 28 2014 - 18:52:09 EST
On Thursday 28 August 2014 16:21:00 Boris BREZILLON wrote:
> On Thu, 28 Aug 2014 14:19:22 +0200 Laurent Pinchart wrote:
> > Hi Boris,
> >> I don't have any VGA connector (or I'm missing something :-)),
> > My bad.
> No problem.
> >> but I have an LCD panel and an RGB to HDMI encoder connected on the same
> >> RGB connector.
> > There's no such thing as an RGB connector in DRM. Your SoC has a parallel
> > RGB video output (I assume it's a DPI bus). From a DRM point of view,
> > that bus corresponds to the output of the CRTC.
> Okay, this mean I'll have to dispatch some of the code I've put in
> atmel_hlcdc_output.c into atmel_hlcdc_crtc.c (BTW, any chance you could
> take a look at this files ?).
Not in the very near future I'm afraid, I'm moving to a new flat in a couple
of days, that will keep me pretty busy. If nobody has reviewed your patches in
a week from now feel free to ping me.
> >>> As DRM hardcodes the pipeline model to CRTC -> encoder -> connector,
> >>> you will also need a DRM encoder in the VGA path. I suppose your board
> >>> has a VGA DAC, that's the component you should expose as a DRM encoder
> >>> (even if it can't be controlled and doesn't limit the valid modes).
> >> Actually, my problem is that both devices are connected on the same RGB
> >> connector, and thus share the same display mode (resolution, HSYNC,
> >> VSYNC, RGB output mode, ...).
> >> This means that all remote devices have to agree on a specific mode if
> >> we want to mirror the display on several output devices, otherwise we
> >> must disable one of the output devices.
> > That's not really a problem. From a DRM perspective you need to model your
> > device as
> > ,------. ,---------------. ,-----------------.
> > | CRTC | -+--> | Dummy Encoder | ----> | Panel Connector |
> > `------´ | `---------------´ `-----------------´
> > | ,---------------. ,-----------------.
> > \--> | HDMI Encoder | ----> | HDMI Connector |
> > `---------------´ `-----------------´
> > The HDMI pipeline is pretty straightforward.
> > You have told me that the panel has a parallel RGB input without any
> > encoder in the panel pipeline (by the way, which panel model are you
> > using ?). However, DRM requires an encoder in every pipeline. You will
> > thus need to instantiate a dummy encoder. One option would be to set the
> > encoder and connector types to DRM_MODE_ENCODER_LVDS and
> > DRM_MODE_CONNECTOR_LVDS respectively, as that's what userspace usually
> > expects for panels. That doesn't reflect the reality in your case though,
> > so creating a new DRM_MODE_CONNECTOR_DPI type might be needed, possibly
> > to be used with DRM_MODE_ENCODER_NONE.
> > As neither encoder can modify the mode, the same mode will be output on
> > the two connectors.
> There are still several things to I'd like to understand:
> 1) who's gonna configure the RGB bus output format (RGB444, RGB666,
> RGB888) which directly depends on the device connected on this bus:
> the CRTC or the dummy and HDMI encoders.
Your mileage my vary, but in general I believe this should be the
responsibility of the CRTC driver (the HLCDC driver in your case), from
information it gets from DT and/or queries dynamically from the encoders at
> 2) Where should the HDMI encoder/connector support be implemented:
> in drivers/gpu/drm/atmel-hlcdc, drivers/gpu/drm/bridge or somewhere
> else. My point is that I don't want to add specific support for the
> Sil902x transmitter chip in the hlcdc driver.
The HDMI encoder should definitely be handled by a standalone driver. We have
two infrastructures for this at the moment, drm_bridge and drm_encoder_slave.
I'd like to see them being merged. I need to implement support for an HDMI
encoder as well, I'll see if I can give this a try.
> Sorry if these are silly questions, but I'm still trying to understand
> how my case should be modeled :-).
As I don't have straightforward answers I won't consider the questions as
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/