Hi Jani, >-----Original Message----- >From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] >Sent: Wednesday, September 16, 2015 3:18 PM >To: R, Durgadoss; intel-gfx@xxxxxxxxxxxxxxxxxxxxx >Cc: R, Durgadoss >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT > >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@xxxxxxxxx> wrote: >> This is an RFC series to start the review/discussion on approach >> to support USB type C based DP panel. >> >> To support USB type C alternate DP mode, the display driver needs to >> know the number of lanes required by the DP panel as well as number >> of lanes that can be supported by the type-C cable. Sometimes, the >> type-C cable may limit the bandwidth even if Panel can support >> more lanes. >> >> The goal is to find out the number of lanes which can be supported >> using a particular cable so that we can cap 'max_available_lanes' >> to that number during modeset. >> >> These two patches are based on 4.2-rc2 and tested only on >> a BXT A1 platform for now. >> >> Brief summary of the approach taken: >> ----------------------------------- >> 1.As soon as DP-hotplug is detected, driver starts link training >> with highest number of lanes/bandwidth possible. If it fails, >> driver retries link training with lane/2 for same bandwidth. >> We continue this procedure until we find a working configuration >> of lane/bandwidth values. This 'number of lanes' is then >> set as the 'max_available_lanes', so that the following >> intel_dp_compute_config() during modeset picks it up as >> max_lane_count (instead of 4 always, from DPCD). > >Would all of this work automatically if our link training sequence >followed the DP spec to the letter wrt degrading the link on failures? That is one part of it. Our intention is also to filter out the modes that cannot be set with 'max_available_lanes' through connector->mode_valid callback, which uses these variables. Otherwise, we risk failing a modeset that uses higher resolutions than possible. Sorry, I should have also added this as part of the commit message. Thanks, Durga > >BR, >Jani. > > >> >> 2.Since we do only link training on hotplug, only the port >> and its PLLs are enabled/disabled without touching pipe/ >> planes etc. >> >> 3.For scenarios where we boot with DP connected (along with >> an LFP like MIPI/eDP) we disable the crtc and then start >> link training, since BIOS brings up DP. The crtc is >> enabled back during subsequent modeset. This needs some >> changes for latest -nightly branch since we do not have >> intel_crtc_control() anymore. >> >> 4.Since we are doing the link training on hotplug (as >> opposed to during modeset) we named the function >> '{chv/bxt/*}_upfront_link_train'. We can also think >> of a virtual func for this, inside intel_encoder. >> >> Durgadoss R (2): >> drm/i915/dp: Make bxt_ddi_pll_select non-static >> drm/i915/dp: Enable Upfront link training for type-C DP support >> >> drivers/gpu/drm/i915/intel_ddi.c | 11 +-- >> drivers/gpu/drm/i915/intel_display.c | 130 +++++++++++++++++++++++++++++++++++ >> drivers/gpu/drm/i915/intel_dp.c | 22 ++++++ >> drivers/gpu/drm/i915/intel_drv.h | 6 ++ >> 4 files changed, 165 insertions(+), 4 deletions(-) >> >> -- >> 1.9.1 >> > >-- >Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
