Prefer inclusive ranges for revision checks rather than "below B0". Per
specs A2 is not used, so revid <= A1 matches revid < B0.
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-2-git-send-email-jani.nikula@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Drop some useless 'reg' variables when we only use them once.

v2: A few more, including a few variable moves
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use goto to handle the error path to avoid duplicating the same code. In
the error path intel_dig_port is the last one to be released as it was
the first one to be allocated and ideally the error path should be the
reverse of the execution path.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The link training functions had confusing names. The start function
actually does the clock recovery phase of the link training, and the
complete function does the channel equalization. So call them that
instead. Also, every call to intel_dp_start_link_train() was followed
by a call to intel_dp_complete_link_train(), so add a new start
function that calls clock_recory and channel_equalization.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The docs are unclear as usual, so it's not clear whether LRC should be
bypassed, performed normally or GRC code should be used as the LRC code.
Some old docs stated that LRC bypass ought to be used, more recent ones
no longer say that. Some docs indicated that we could use GRC as the LRC
code on CHV, but the BIOS doesn't do that, so let's not do it either.

Besides to enable LRC bypass properly, I believe we should set the bit
already before deasserting cmnreset.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Previously we've relied on having basically one backlight and one
backlight type per platform. This is already a bit quirky with PMIC PWM
support on VLV/CHV platforms with MIPI DSI. In the foreseeable future
we'll have at least DPCD based backlight control on eDP and DCS command
based backlight control on MIPI DSI. Backlight is becoming more and more
connector specific, so reflect this fact by making the backlight control
hooks connector specific.

This enables further work to reuse generic backlight code in
intel_panel.c while adding more specific backlight code accessed via the
hooks.

Cc: Deepak M <m.deepak@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDeepak M <m.deepak@intel.com>
Reviewed-by: NYetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make adjusted_mode const whereever we don't have to modify it. This only
covers cases when we have a local adjusted_mode variable, and doesn't
make any difference for cases where we just dereference
pipe_config->adjusted_mode.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't support eDP on g4x, so let's not even look at the VBT
to determine the port type, just in case the VBT is bonkers
on some g4x machines and indicates the precense of eDP.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.

The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.

This is explained here in, in a rough way:
HPD line  ________________
			 |\ T1 = Monitor Hotplug causing IRQ
			 | \______________________________________
			 | |
                         | |
			 | |   T2 = Live status is stable
			 | |  _____________________________________
			 | | /|
Live status _____________|_|/ |
			 | |  |
			 | |  |
			 | |  |
			T0 T1  T2

(Between T1 and T2 Live status fluctuates or can be even low, depending on
 the monitor)

After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.

This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
    which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SKL port E handling was added in

commit 26951caf
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date:   Mon Aug 17 15:55:50 2015 +0800

    drm/i915/skl: enable DDI-E hotplug

but the whole function was moved in a another branch in

commit b93433cc
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Aug 20 10:47:36 2015 +0300

    drm/i915: move ibx_digital_port_connected to intel_dp.c

and the addition was lost at some backmerge that I was unable to
identify. Put it back in.
Tested-by: NTomi Sarvela <tomix.p.sarvela@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to treat this the same as
a normal i2c write.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.

Log an error if the sink has advertized HBR2 capability without TPS3
capability.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is no need to have a separate flag for tps3 as the information is
only used at one location. Move the logic there to make it easier to
follow.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make it available outside of intel_dp.c.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we release the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.

The one confusing thing in this is that when we remove the power down
override from the lanes, they power up with defaul register values,
which do not have the soft reset overrides enabled. And according to
some docs by default the data lane resets are tied to cmnreset. So that
would mean that lanes would come out of reset without staggering as
soon as the power down overrides are removed. But since we can't access
either the lane stagger register nor the soft reset override registers
until the lanes are powered on, we can't really do anything about it.
So let's just set the soft reset overrides as soon as the lane is
powered on and hope for the best.

v2: Fix typos in commit message (Daniel)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The DP MST encoder config function never sets ddi_pll_sel, even though
its value is programmed in its ->pre_enable() hook. That used to work
because a new pipe_config was kzalloc'ed at every modeset, and the value
of zero selects the highest clock for the PLL. Starting with the commit
below, the value of ddi_pll_sel is preserved through modesets, and since
the correct value wasn't properly setup by the MST code, it could lead
to warnings and blank screens.

commit 8504c74c
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Fri May 15 11:51:50 2015 +0300

    drm/i915: Preserve ddi_pll_sel when allocating new pipe_config

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628
Cc: stable@vger.kernel.org # 7e6313a2 drm/i915: Don't use link_bw for PLL setup
Cc: stable@vger.kernel.org
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/intel_dp_tps/drm_dp_tps/.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.

v2: Fix typo in commit message (Sivakumar)
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from future.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Enable eDP on DDI-E.

Also let's remove duplicated definitions to avoid later confusion.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.

If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.

Also remove the leftover comment that referred to the old retraining
from .hot_plug().

Fixes a regression introduced in:
commit 0e32b39c
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 2 14:02:48 2014 +1000

    drm/i915: add DP 1.2 MST support (v0.7)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453Tested-by: NPalmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

With DPIO powergating active the DPLL can't be accessed unless
something else is keeping the common lane in the channel on.
That means the PPS kick procedure could fail to enable the PLL.

Power up some data lanes to force the common lane to power up
so that the PLL can be enabled temporarily.

v2: Avoid gcc uninitilized variable warning
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Normmally the common lane in a PHY channel gets powered up when some
of the data lanes get powered up. But when we're driving port B with
pipe B we don't want to enabled any of the data lanes, and just want
the DPLL in the common lane to be active.

To make that happens we have to temporarily enable some data lanes
after which we can access the DPLL registers in the common lane. Once
the pipe is up and running we can drop the power override on the data
lanes allowing them to shut down. From this point forward the common
lane will in fact stay powered on until the data lanes in the other
channel get powered down.

Ville's extended explanation from the review thread:

On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
> One Q, why only for port B? Port C is also in same common lane right?

Port B is in the first PHY channel which also houses CL1. CL1 always
powers up whenever any lanes in either PHY channel are powered up.
CL2 only powers up if lanes in the second channel (ie. the one with
port C) powers up.

So in this scenario (pipe B->port B) we want the DPLL from CL2, but
ideally we only want to power up the lanes for port B. Powering up
port B lanes will only power up CL1, but as we need CL2 instead we
need to, temporarily, power up some lanes in port C as well.

Crossing the streams the other way (pipe A->port C) is not a problem
since CL1 powers up whenever anything else powers up. So powering up
some port C lanes is enough on its own to make the CL1 DPLL
operational, even though CL1 and the lanes live in separate channels.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
[danvet: Amend commit message with extended explanation.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. To
power down the unused lanes we use some power down override bits in the
DISPLAY_PHY_CONTROL register. Without the overrides it appears that the
hardware always powers on all the lanes. When the port is disabled the
power down override is not needed and the lanes will shut off on their
own. That also means the override is critical to actually be able to
access the DPIO registers before the port is actually enabled.

Additionally the common lanes will power down when not needed. CL1
remains on as long as anything else is on, CL2 will shut down when
all the lanes in the same channel will shut down. There is one exception
for CL2 that will be dealt in a separate patch for clarity.

With potentially some lanes powered down, the DP code now has to check
the number of active lanes before accessing PCS/TX registers. All
registers in powered down blocks will reads as 0xffffffff, and soe we
would drown in warnings from vlv_dpio_read() if we allowed the code
to access all those registers.

Another important detail in the DP code is the "TX latency optimal"
setting. Normally the second TX lane acts as some kind of reset master,
with the other lanes as slaves. But when only a single lane is enabled,
that single lane obviously has to be the master.

A bit of extra care is needed to reconstruct the initial state of the
DISPLAY_PHY_CONTROL register since it can't be read safely. So instead
read the actual lane status from the DPLL/PHY_STATUS registers and
use that to determine which lanes ought to be powergated initially.

We also need to switch the PHY power modes to "deep PSR" to avoid
a hard system hang when powering down the single channel PHY.

Also sprinkle a few debug prints around so that we can monitor the
DISPLAY_PHY_STATUS changes without having to read it and risk
corrupting it.

v2: Add locking to chv_powergate_phy_lanes()
v3: Actually enable dynamic powerdown in the PHY and deal with the
    fallout
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BXT platform uses live status bits from 0x44440 register to obtain DP
status on hotplug. The existing g4x_digital_port_connected() uses a
different register and hence misses DP hotplug events on BXT
platform. This patch fixes it by using the appropriate register(0x44440)
and live status bits(3:5).

Based on a patch by Durgadoss R <durgadoss.r@intel.com>, from whom the
commit message is shamelessly copy pasted.
Reported-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Choose the right function at the intel_digital_port_connected level.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Choose the right function at the intel_digital_port_connected level.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.

v2: make the function return a boolean
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the case added for eDP on port A (always connected from this
function's point of view), we should not be hitting any of the default
cases in ibx_digital_port_connected, so add MISSING_CASE annotation.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should not be hitting any of the default cases in
g4x_digital_port_connected, so add MISSING_CASE annotation and return
boolean status. The current behaviour is just cargo culting from the
days of yonder when the display port support was added to i915.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The function can be made static there. No functional changes.
Reviewed-by: NDurgadoss R <durgadoss.r@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the CHV clock buffer disable from chv_disable_pll() to the new
encoder .post_pll_disable() hook. This is more symmetric since the
clock buffer enable happens from the .pre_pll_enable() hook.

We'll have more use for the new hook soon.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The docs give you the impression that the unique transition scale
value shouldn't matter when unique transition scale is enabled. But
as Imre found on BXT (and I verfied also on BSW) the value does
matter. So from now on just program the same value 0x9a always.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With MST there won't be a crtc assigned to the main link encoder, so
trying to dig up the pipe_config from there is a recipe for an oops.

Instead store the parameters (lane_count and link_rate) in the encoder,
and use those values during link training etc. Since those parameters
are now assigned only when the link is actually enabled,
.compute_config() won't clobber them as it did before.

Hardware state readout is still bonkers though as we don't transfer the
link parameters from pipe_config intel_dp. We should do that during
encoder sanitation. But since we don't even do a proper job of reading
out the main link encoder state for MST there's littel point in
worrying about this now.

Fixes a regression with MST caused by:
 commit 90a6b7b0
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Jul 6 16:39:15 2015 +0300

    drm/i915: Move intel_dp->lane_count into pipe_config

v2: Different apporoach that should keep intel_dp_check_mst_status()
    somewhat less oopsy

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: fix one error found by checkpath.pl
v3: Add one ignored break for switch-case. DDI-E hotplug
    function doesn't work after updating drm-intel tree,
    I checked the code and found this missing which isn't
    the root cause for broke DDI-E hp.  The broken
    DDI-E hp function is fixed by "Adding DDI_E power
    well domain".
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: NTimo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

v2: optimize if else condition (Jani)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: minor whitespace fix.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)
v3: update comment to indicate TP3 dependency on HBR2 supported
    hardware (Jani)

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
[Jani: fixed a couple of checkpatch warnings.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

v2: change the ordering for better readability (Ville)

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts
commit fe51bfb9.
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Cc: stable@vger.kernel.org # v4.1+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>