lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1589754.DxSd6XN1nL@avalon>
Date:	Fri, 29 Aug 2014 00:52:47 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Andrew Victor <linux@...im.org.za>,
	David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org, linux-pwm@...r.kernel.org,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Rob Clark <robdclark@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	Bo Shen <voice.shen@...el.com>,
	Kumar Gala <galak@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller

Hi Boris,

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

>  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 
silly :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ