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. > It is therefore better to perfrom this locking/unlocking only once, > ie at the beginning and at the end of the entire I2C transfer. > The current design of drm_dp_helper.c doesn't allow this. > This patchset modifies drm_dp_helper.c and moves the locking/unlocking > operation to the top. > This fixes the long delay observed in > https://bugs.freedesktop.org/show_bug.cgi?id=86201 > > Egbert Eich (4): > drm/DP: Create pointer to generic DPCD access function > drm/DP: Export drm_dp_i2c_xfer() DP helper function > drm/DP: Export drm_dp_dpcd_access() DP helper function > drm/i915/eDP: Move pps_lock() and edp_panel_vdd_on() to top > > Ville Syrjälä (1): > drm/i915: Try to avoid pps_{lock,unlock}() on DP ports 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 xfer_pre/post functions. To make this as painless as possible we should probably refcount that in the dp helper, protected by aux->hw_mutex. That way normal dp reads could just do the xfer_pre/post around the call to aux->transfer while i2c could do it around the entire i2c transaction. -Daniel > > drivers/gpu/drm/drm_dp_helper.c | 11 ++-- > drivers/gpu/drm/i915/intel_dp.c | 132 +++++++++++++++++++++++++++++++-------- > drivers/gpu/drm/i915/intel_drv.h | 5 ++ > include/drm/drm_dp_helper.h | 14 +++++ > 4 files changed, 133 insertions(+), 29 deletions(-) > > -- > 1.8.4.5 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
