lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 28 Aug 2014 16:21:00 +0200
From:	Boris BREZILLON <>
To:	Laurent Pinchart <>
Cc:	Thierry Reding <>,
	Ludovic Desroches <>,
	Nicolas Ferre <>,
	Jean-Christophe Plagniol-Villard <>,
	Alexandre Belloni <>,
	Andrew Victor <>,
	David Airlie <>,,,
	Samuel Ortiz <>,
	Lee Jones <>,
	Rob Clark <>,
	Mark Rutland <>,, Pawel Moll <>,
	Ian Campbell <>,, Rob Herring <>,
	Bo Shen <>,
	Kumar Gala <>,
Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display

Hi Laurent,

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

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

Sorry if these are silly questions, but I'm still trying to understand
how my case should be modeled :-).

Best Regards,


Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists