Re: Caching of EDID for X server to decrease startup time of X server

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel