[RFC PATCH 0/3] Limit pluggable display modes

[Krzysztof Kozlowski]

On 08/09/2022 20:05, Dmitry Baryshkov wrote:
> 
> On 30/08/2022 06:33, Abhinav Kumar wrote:
>> As reported on https://gitlab.freedesktop.org/drm/msm/-/issues/17, currently
>> there is no mechanism to limit the display output to the pluggable displays
>> and it lets users connect any monitor on any chipset based device.
>>
>> This can lead to undefined behavior because lets say the display
>> advertises an unsupported pixel clock as its preferred resolution, then
>> the end-user can experience undefined behavior such as black screen,
>> crash or an underrun.
>>
>> The capabilities of every chipset are advertised in the product
>> specification for both on-device displays and pluggable displays.
> 
> After discussing this privately, it was agreed that there are two kinds 
> of issues here:
>   - filtering the modes which can not be handled by the DPU/DSI/DP 
> hardware pieces themselves
> 
>   - filtering the modes which can not be handled by the external 
> limitations (e.g. the bridge not being able to drive this mode, the pcb 
> routing of data lanes being unable to sustain the rate, the connector 
> being the limit, etc).
> 
> Krzysztof, I'd like to ask your advice if adding a properly like 
> `max-link-frequency' sounds like a good idea? The video-interfaces.yaml 
> bindings already has the `link-frequencies' property, but it is an array 
> of discrete frequencies supported by the link in the graph. In our case 
> the list of frequencies is more or less continuous, with max (and min) 

I would just use existing link-frequencies for min-max. Your binding
would need to clarify the difference against video-interfaces.

> values. Also, can it be added to the final device in the chain (e.g. 
> hdmi/dp/vga connectors) or should it be added to the endpoint graph nodes?

The same as existing usage of video-interfaces, so the endpoints?


Best regards,
Krzysztof