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:

quoted

Hi Boris,

[...]

quoted

quoted

I don't have any VGA connector (or I'm missing something :-)),

My bad.

No problem.

quoted

quoted

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.

quoted

quoted

quoted

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