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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
