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
