[Intel-gfx] [RFCv2 DP-typeC 0/6] Add support for USB typeC based DP

[Durgadoss R]

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.

The BXT patches are based on 4.2-rc2 and tested on BXT A1.
CHV implementation is tested on 3.18. Both are tested only
in non-MST mode.

The 1/6 to 4/6 are refactoring/exporting functions required
to do upfront link train for DDI platforms from intel_ddi.c.
Patch 5/6 is upfront implementation for BXT and 6/6 is for CHV.

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).

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.

As per Daniel's suggestion on RFCv1:
* Added the last patch 6/6 that has implementation for CHV
* Made intel_dp_upfront_link_train as common for all platforms
  and added a intel_ddi_upfront_* for all DDI platforms.
  Currently, have restricted it to only for SKL/BXT.
* Moved the upfront code for DDI platforms into intel_ddi.c
  from display.c, since that aligned better with other
  ddi* functions.
* Kept the CHV implementation in display.c as of now
  since we are using some pll functions defined in display.c
  We can discuss and finalize an appropriate place for this
  and then refactor/export required functions.

Durgadoss R (6):
  drm/i915/dp: Reuse encoder if it is already available
  drm/i915/dp: Reuse shared DPLL if it exists already
  drm/i915/dp: Abstract all get_ddi_pll methods
  drm/i915/dp: Export enable/disable_shared_dpll methods
  drm/i915/dp: Enable Upfront link training for typeC DP support on BXT
  drm/i915/dp: Enable Upfront link training for typeC DP support on CHV

 drivers/gpu/drm/i915/intel_ddi.c     | 231 ++++++++++++++++++++++++++++++-----
 drivers/gpu/drm/i915/intel_display.c | 159 ++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_dp.c      |  43 ++++++-
 drivers/gpu/drm/i915/intel_drv.h     |  11 +-
 4 files changed, 401 insertions(+), 43 deletions(-)

-- 
1.9.1