[Intel-gfx] [PATCH v1½ 00/13] drm/i915/dp: link rate and lane count refactoring

[Jani Nikula]

On Thu, 02 Feb 2017, Manasi Navare <manasi.d.navare at intel.com> wrote:
> On Wed, Feb 01, 2017 at 11:40:06AM -0800, Manasi Navare wrote:
>> Are you planning on submitting a v2 for these pretty soon
>> that can make it to patchwork/
>> 
>> Regards
>> Manasi
>> 
>> On Thu, Jan 26, 2017 at 09:44:14PM +0200, Jani Nikula wrote:
>> > This is kind of version 1½ of [1], basically just rebased on current git
>> > (including Manasi's test automation patches) and a couple of more
>> > cleanups slammed on top.
>> > 
>> > BR,
>> > Jani.
>> >
>
> So the problem we still have with link rate fallback after link
> failure->uevent-> fetch new modes->link retrain is that after we send
> a uevent, userspace fetches new modes which calls
> drm_helper_probe_single_connector_modes() that calls dp_detect which
> ends up calling intel_dp_long_pulse(). So while userspace is just
> trying to fetch new modes it overwrites the max_link_rate and
> max_lane_count values through intel_dp_long_pulse().  So while
> retraining, when it calls intel_dp_compute_config(), it will use the
> overwritten values of common_rates/max_link_rate/max_lane_count as
> opposed to the ones set in intel_dp_get_fallback_values().
> I wonder if this patch series solves this problem somehow...
> else, do you have any insight on how we can solve this?

I'm not sure this does solve that, but this series certainly makes it
easier to follow through the code and see what happens where. ;)

Writing this patch has also highlighted the problem with merging
preparatory patches that don't actually do anything, in this case the
intel_dp_get_link_train_fallback_values() function. How is one supposed
to know how it can be refactored when it doesn't have a single user?

BR,
Jani.



>
> Regards
> Manasi
>
>  
>> > 
>> > [1] http://mid.mail-archive.com/cover.1485015599.git.jani.nikula@intel.com
>> > 
>> > 
>> > Jani Nikula (13):
>> >   drm/i915/dp: use known correct array size in rate_to_index
>> >   drm/i915/dp: return errors from rate_to_index()
>> >   drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse
>> >   drm/i915/dp: cache source rates at init
>> >   drm/i915/dp: generate and cache sink rate array for all DP, not just
>> >     eDP 1.4
>> >   drm/i915/dp: use the sink rates array for max sink rates
>> >   drm/i915/dp: cache common rates with sink rates
>> >   drm/i915/dp: do not limit rate seek when not needed
>> >   drm/i915/dp: don't call the link parameters sink parameters
>> >   drm/i915/dp: add functions for max common link rate and lane count
>> >   drm/i915/mst: use max link not sink lane count
>> >   drm/i915/dp: localize link rate index variable more
>> >   drm/i915/dp: use readb and writeb calls for single byte DPCD access
>> > 
>> >  drivers/gpu/drm/i915/intel_dp.c               | 275 ++++++++++++++------------
>> >  drivers/gpu/drm/i915/intel_dp_link_training.c |   3 +-
>> >  drivers/gpu/drm/i915/intel_dp_mst.c           |   4 +-
>> >  drivers/gpu/drm/i915/intel_drv.h              |  19 +-
>> >  4 files changed, 166 insertions(+), 135 deletions(-)
>> > 
>> > -- 
>> > 2.1.4
>> > 
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center