On 27.05.2019 17:11, Tomi Valkeinen wrote: > On 21/05/2019 17:18, Andrzej Hajda wrote: > >>> DisplayPort spec talks about doing the display-props reading and EDID reading when >>> handling HPD. >>> >>> I think it would be best to change the code so that we read display props and EDID in HPD, >>> but so that we also can read them later (when needed, probably bridge enable and >>> get_modes) if we haven't done the reads already. I've had this in mind since I started the >>> series, but as it didn't feel like a simple change, I left it for later. >> >> My approach and experience suggest that detect, should be rather >> lightweight and should not modify state, I am not even sure if it is >> called at all on forced connector. > I just realized that this is not exactly perfect... > > Link training can adjust the link speed and/or number of lanes, although > the driver doesn't support this at the moment. The speed and number of > lanes affect the video modes that are possible, so they affect get_modes. > > So... I think the driver should set up the link fully before get_modes > get called, instead of leaving the link setup to the point where we > enable the bridge. Maybe... This is not exactly clear to me =). Moreover link state can change during work, so full implementation should handle HPD pulses (below 1ms if I remember correctly) re-train if necessary and use drm_connector_set_link_status_property as well :) Regards Andrzej > > In any case, I think that's future work. I have changed the code to read > the display props in get_modes(), and I have another small fix too. I'll > send v4 this week, and hopefully we can get this merged. > > Tomi > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
