Re: [Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-26 Thread Daniel Vetter
On Tue, Nov 25, 2014 at 06:20:17PM +0100, Egbert Eich wrote: Daniel Vetter writes: Imo this approach with overwrite all the entry points won't scale since besides i2c and dpcd there will be more sooner or later (oui, dp mst, some debugfs userspace dp aux tools, ...). I think

Re: [Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-25 Thread Jani Nikula
On Mon, 24 Nov 2014, Egbert Eich e...@suse.de wrote: For eDP in the Intel driver pps_lock()/unlock() need to be called before initiating an I2C/AUX channel transfer. These operations can be quite expensive - especially on values for HZ lower than 1000. It

Re: [Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-25 Thread Daniel Vetter
On Mon, Nov 24, 2014 at 06:16:22PM +0100, Egbert Eich wrote: For eDP in the Intel driver pps_lock()/unlock() need to be called before initiating an I2C/AUX channel transfer. These operations can be quite expensive - especially on values for HZ lower than 1000.

Re: [Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-25 Thread Egbert Eich
Daniel Vetter writes: Imo this approach with overwrite all the entry points won't scale since besides i2c and dpcd there will be more sooner or later (oui, dp mst, some debugfs userspace dp aux tools, ...). I think what we need is the same as in the i2c layer has with the

[Intel-gfx] [PATCH 0/5] drm/i915 Avoid long delays when reading EDID on eDP

2014-11-24 Thread Egbert Eich
For eDP in the Intel driver pps_lock()/unlock() need to be called before initiating an I2C/AUX channel transfer. These operations can be quite expensive - especially on values for HZ lower than 1000. It is therefore better to perfrom this locking/unlocking only