[PATCH 1/4] ARM: dts: am437x-gp-evm: add HDMI support

Tomi Valkeinen tomi.valkeinen at ti.com
Fri Dec 13 12:04:30 UTC 2019


On 13/12/2019 13:42, Laurent Pinchart wrote:
> Hi Tomi,
> 
> 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?

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

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the dri-devel mailing list