[RFC PATCH 0/3] Limit pluggable display modes

[Dmitry Baryshkov]

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) 
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?

> Documents such as [1], [2] and [3] can easily be found on the vendor's
> website which advertise the max resolution support for that chipset.
> 
> Utilize this information to filter out the resolutions which have
> pixel clock more than the supported limits.
> 
> This change only addresses pluggable displays because the underlying
> assumption is that for the built-in displays, the display being chosen
> for the product will be done so after referring to the advertised limits.
> 
> For calculating the pixel clock, the value has been taken from the CEA
> speficiation if the resolution is a CEA one and from the CVT specification
> for non-CEA.
> 
> This change has only been compile tested so far to get a general feedback
> first and once it takes a final shape, will validate on whatever devices I have
> and will appreciate help from others who have devices which I dont.
> 
> [1]: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd7c.pdf
> [2]: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd7c_gen2.pdf
> [3]: https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/prod_brief_qcom_sd8cx_gen2.pdf
> 
> Abhinav Kumar (3):
>    drm/msm/dpu: add max external pixel clock for all targets
>    drm/msm: filter out modes for DSI bridge having unsupported clock
>    drm/msm: filter out modes for DP/eDP bridge having unsupported clock
> 
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  8 ++++++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  2 ++
>   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c        | 18 ++++++++----
>   drivers/gpu/drm/msm/dp/dp_display.c            | 16 +++++++++--
>   drivers/gpu/drm/msm/dp/dp_parser.h             |  1 -
>   drivers/gpu/drm/msm/dsi/dsi.c                  |  5 ++++
>   drivers/gpu/drm/msm/dsi/dsi.h                  |  6 ++--
>   drivers/gpu/drm/msm/dsi/dsi_host.c             | 40 ++++++++++++++++++++++----
>   drivers/gpu/drm/msm/dsi/dsi_manager.c          |  2 +-
>   drivers/gpu/drm/msm/msm_drv.h                  |  9 ++++--
>   10 files changed, 88 insertions(+), 19 deletions(-)
> 

-- 
With best wishes
Dmitry