Re: [RFC PATCH 0/3] Limit pluggable display modes
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
Re: [RFC PATCH 0/3] Limit pluggable display modes
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
[RFC PATCH 0/3] Limit pluggable display modes
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. 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(-) -- 2.7.4
