On Mon, Aug 10, 2015 at 03:01:49PM +0200, Thierry Reding wrote:
On Sat, Aug 08, 2015 at 10:18:57PM +0200, Paul Menzel wrote:
Is it correct, that EDID is probed for both outputs? Is that necessary? I assume during startup the Linux kernel for example already collected this information and if no change of monitor/output is detected, the EDID should be the same, right?
Is that already implement and I just need to apply the correct configuration?
Any suggestions on how to decrease the startup time for the X server are much appreciated.
Russell and Sascha were discussing this kind of caching in the i.MX driver recently. Adding both for visibility. Also not trimming the quote in case they don't have the original.
It sounds like this could be useful to have in the core.
Yes, as I mentioned in the discussion between Sascha and myself, I think this should be implemented in the DRM core rather than each and every driver.
My reasoning is that the pretense for caching the EDID is basically one of performance: we don't want to keep on performing the time consuming I2C bus cycles to read it. However, drm_helper_probe_single_connector_modes_merge_bits() itself can be very expensive - it can call out to drm_load_edid_firmware(), which can involve requesting EDID firmware - which results in calling out to userspace.
So, if we're concerned about performance, I think it would be better to solve all the performance problems in this path in a generic way which covers both issues.
As I understand it, hotplug detection is pretty well specified for more modern display interfaces (like HDMI and DisplayPort), so I think caching of this sort could work for those. However, I think some older interfaces such as VGA (or perhaps even DVI as well) don't have reliable hotplug detection and hence would need to be able to force reading the EDID.
Yes, I think I've seen code in DRM which does hotplug-detection-by-EDID. Those are normally doing so in their ->detect callback, and using the presence of EDID to report whether there's a device connected. I'd suggest these remain separate from this caching as it's serving a different purpose.
Still, perhaps a connector flag could be introduced to enable caching on a per-connector basis, and then we should be able to deal with this in the DRM core, rather than have per-driver quirks.
I agree, and I think a lot of it can be handled entirely within DRM for most cases if we:
- arrange for a new connector "modes_invalid" flag which is set initially - arrange for drm_helper_probe_single_connector_modes_merge_bits to test this flag to determine whether it needs to re-read the modes and/or load EDID. - have drm_helper_probe_single_connector_modes_merge_bits clear this flag if caching is enabled and we successfully read the modes from the connector and/or loaded EDID. - set this flag whenever we see the connector transition from a non-connected state to a connected state.
I'm trying not to talk myself into writing another patch at the moment... my latency for getting development work into the kernel seems to be getting on for 2 years judging by the state of my dwhdmi audio and CEC patches, though I'm pretty sure that's just because they're fairly low-priority for me. :(