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. :( -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
