Hi Tomi, On Fri, Dec 13, 2019 at 02:04:30PM +0200, Tomi Valkeinen wrote: > On 13/12/2019 13:42, Laurent Pinchart wrote: > > On Fri, Dec 13, 2019 at 12:56:31PM +0200, Tomi Valkeinen wrote: > >> On 13/12/2019 12:42, Laurent Pinchart wrote: > >> > >>>> I think the correct way would be to have DRM framework understand that we have two displays, which > >>>> are mutually exclusive, and the display pipeline drivers would have the means to switch the gpio. > >>>> And that the display setup could be communicated properly to the userspace, and the userspace would > >>>> understand it. I don't think any of those exists. > >>> > >>> Isn't this what possible_clones in drm_encoder is for ? It notifies > >>> userspace of mutual exclusions between encoders. > >> > >> Hmm, how would that work here? Isn't encoder cloning about having two encoders, which take the input > >> from the same video source, and then outputting to two displays? > > > > That's the idea. If you have one encoder for HDMI and one for the panel, > > you can mark them as non-clonable, and then only one of the two can be > > active at a time. > > We have a single DPI output from the SoC. That goes to the panel, or to SiI9022 bridge, depending on > the GPIO switch. > > So... In the DT file, we would have multiple endpoints in the same output port in DSS, one going to > the panel, one to the SiI9022? omapdrm could then create two encoders, one abstracting the DPI > output and the connection to the panel, one abstracting the DPI output and SiI9022? That's the idea, yes. > And then someone would need to handle the GPIO, and set it based on the output used. These kind of > gpios are always difficult, as they don't belong anywhere =). https://lore.kernel.org/lkml/20191211061911.238393-5-hsinyi@xxxxxxxxxxxx/ Still, the infrastructure in omapdrm would need quite a bit of work. We're just about to get a helper layer for linear pipelines merged, and we already need to go one step further :-) -- Regards, Laurent Pinchart
