Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-1-ville.syrjala@linux.intel.comReviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

I'm stepping down, also handing all the drm-misc stuff to the new
team. Plan is that Sean handles 4.17, and Maarten then has fun with
4.18 as his first release.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131102156.25634-1-daniel.vetter@ffwll.ch

If the wait timeouts, the caps are probably invalid and we shouldn't be
passing them to userspace.
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20171127142126.25765-1-tomeu.vizoso@collabora.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130100528.GA7154@training

The parentheses are in the wrong place here so we pass the bits per
pixel as zero.

Fixes: abbee623 ("drm/mgag200: Added resolution and bandwidth limits for various G200e products.")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125142655.GA23885@mwanda

drm_encoder_slave is the old way to write bridge drivers, for i2c
bridges only. It's deprecated, and definitely should not be used in
new drivers. This has absolutely nothing to do with the new bridge
driver infrastructure implemented by drm_bridge.

What's even strange is that arcpgu doesn't even use any of this, it
really only wants a plain normal drm_encoder. Nuke all the surplus
real estate.

v2: Actually git add after compile testing ...

v3: Clarify commit message and stop including drm_encoder_slave.h.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117141755.16933-1-daniel.vetter@ffwll.ch

The structure should really be sw_sync_create_fence_data rather than
sw_sync_ioctl_create_fence which is the function name.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1515988079-8677-1-git-send-email-shawn.guo@linaro.org

Userspace can set a FB_ID on a plane without setting CRTC_ID, which
will fail with -EINVAL, but the kernel shouldn't warn about that.

Same for !FB_ID and CRTC_ID being set.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130102704.28016-1-maarten.lankhorst@linux.intel.comReviewed-by: NHarry Wentland <harry.wentland@amd.com>

The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: As the read feature is not implemented, only the
transmitted number of bytes is returned for the moment.
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125103800.1999-3-philippe.cornu@st.com

The dcs/generic dsi read feature is not yet implemented so it
is important to warn the host_transfer() caller in case of
read operation requests.
Reviewed-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125103800.1999-2-philippe.cornu@st.com

To optimize data transfers, align pitch on 128 bytes & height
on 4 bytes. This optimization is not applicable on hw without MMU.
Signed-off-by: NYannick Fertre <yannick.fertre@st.com>
Signed-off-by: NVincent Abriou <vincent.abriou@st.com>
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130104200.21602-1-philippe.cornu@st.com

Add support for the stm dsi phy/wrapper version 1.31.
Only lane capabilities need to be modified.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180122164628.24728-1-philippe.cornu@st.com

In the dsi panel example, clock names in the "clock-names"
field have been swapped:
* "pclk" (peripheral clock) is <&rcc 1 CLK_F469_DSI> on stm32f4
* "ref" (dsi phy pll ref clock) is <&clk_hse> on stm32f4
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180122153547.23470-1-philippe.cornu@st.com

During a non-blocking commit, it is possible to return before the
commit_tail work is queued (-ERESTARTSYS, for example).

Since a reference on the crtc commit object is obtained for the pending
vblank event when preparing the commit, the above situation will leave
us with an extra reference.

Therefore, if the commit_tail worker has not consumed the event at the
end of a commit, release it's reference.

Changes since v1:
- Also check for state->event->base.completion being set, to
  handle the case where stall_checks() fails in setup_crtc_commit().
Changes since v2:
- Add a flag to drm_crtc_commit, to prevent dereferencing a freed event.
  i915 may unreference the state in a worker.

Fixes: 24835e44 ("drm: reference count event->completion")
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: NLeo (Sunpeng) Li <sunpeng.li@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com> #v1
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117115108.29608-1-maarten.lankhorst@linux.intel.comReviewed-by: NSean Paul <seanpaul@chromium.org>

We never support certain mode flags etc. Reject those early on in the
mode_config.mode_valid() hook. That allows us to remove some duplicated
checks from the connector .mode_valid() hooks, and it guarantees that
we never see those flags even from user mode as the
mode_config.mode_valid() hooks gets executed for those as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-11-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Allow drivers to provide a device wide .mode_valid() hook in addition to
the already existing crtc/encoder/bridge/connector hooks. This can be
used to validate device/driver wide constraings without having to add
those to the other hooks. And since we call this hook also for user
modes later on in the modeset we don't have to worry about anything the
hook has already rejected.

I also have some further ideas for this hook. Eg. we could replace the
drm_mode_set_crtcinfo(HALVE_V) call in drm_mode_convert_umode()/etc.
with a driver specific variant via this hook. At least on i915 we would
like to pass CRTC_STEREO_DOUBLE to that function instead, and then
we could safely use the crtc_ timings in all our .mode_valid() hooks,
which would allow us to reuse those hooks for validating the
adjusted_mode during a modeset.

v2: Fix the language fails in the kernel docs (Daniel)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-10-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's
refuse to generate them or accept them from userspace either. A
cursory check didn't reveal any userspace code that would depend
on these.

v2: Recommend DRIVER instead of BUILTIN (ajax)

Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115154504.14338-1-ville.syrjala@linux.intel.comReviewed-by: NJose Abreu <joabreu@synopsys.com>

No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to
achieve. Totally unused so kill if off.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-8-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

For some reason drm_mode_set_crtcinfo() does nothing if the mode has
the DRM_MODE_TYPE_BUILTIN flag set without the other bit from
DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed
to achieve, but since we have no users for neither flag bit let's kill
this nonsense off.

v2: Fix typo in commit message
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-7-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the
kernel command line. Update the docs to reflect that fact.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-6-ville.syrjala@linux.intel.comAcked-by: NAlex Deucher <alexander.deucher@amd.com>

Reject any mode with DRM_MODE_FLAG_BCAST. We have no code that even
checks for this flag hence it can't possibly do any good.

I think this maybe originated from fbdev where it was supposed to
indicate PAL/NTSC broadcast timings. I have no idea why those would
have to be identified by a flag rather than by just the timings
themselves. And then I assume it got copied into xfree86 for
fbdevhw, and later on it leaked into the randr protocol and kms uapi.

Since kms fbdev emulation never uses the corresponding fbdev flag
there should be no sane way for this to come back into kms via
userspace either.

Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-5-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJose Abreu <joabreu@synopsys.com>

Reject any mode with DRM_MODE_FLAG_PIXMUX. We have no code that even
checks for this flag hence it can't possibly do any good.

Looks like this flag had something to do the the controller<->ramdac
interface with some ancient S3 graphics adapters. Why someone though
it would be a good idea to expose it directly to users I don't know.
And later on it got copied into the randr protocol and kms uapi.

Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-4-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJose Abreu <joabreu@synopsys.com>

Currently userspace is allowed to feed in any king of garbage in the
high bits of the mode flags/type, as are drivers when probing modes.
Reject any mode with bogus flags/type.

Hopefully this won't break any current userspace...

v2: Split the type and flags checks to separates ifs (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115154913.23827-1-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Currently we don't sanity check the 3D stereo flags for modes filled out
by the kernel. Move the check from drm_mode_convert_umode() into
drm_mode_validate_basic() so that we get the same check going both ways.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114183258.16976-2-ville.syrjala@linux.intel.comReviewed-by: NAlex Deucher <alexander.deucher@amd.com>

We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.

For connectors the issue is a bit more complicated as they can
be created/destroyed at runtime due to MST. So the problem is no
longer a purely theoretical programmer error. As the connector
indexes are allocated via ida, we can simply limit the maximum
value the ida is allowed to hand out. The error handling is already
in place.

v2: Return an error to the caller (Harry)
v3: Print a debug message so that we know what happened (Maarten)

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125133020.23845-1-ville.syrjala@linux.intel.comReviewed-by: NHarry Wentland <harry.wentland@amd.com>

Due to the way the composition is done in hardware, we can only have a
single alpha-enabled plane active at a time, placed in the second (highest
priority) pipe.

Make sure of that in our atomic_check to not end up in an impossible
scenario.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7371f62a1385f2cbe3ed75dfca2e746338eb2286.1516617243.git-series.maxime.ripard@free-electrons.com

Our various planes have a configurable zpos, that combined with the pipes
allow to configure the composition.

Since the interaction between the pipes, zpos and alphas framebuffers is
not trivial, let's just enable the zpos as an immutable property for now,
and use that zpos in our atomic_update part.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b006853e908bd06661c5bc1f2191121523bce0e4.1516617243.git-series.maxime.ripard@free-electrons.com

The plane state zpos value will be set only if there's an existing state
attached to the plane when creating the property.

However, this is not the case during the probe, and we therefore need to
put our default value in our reset hook.
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b6a183234f0ad5a9a58c780c9cabbe29cbf40888.1516617243.git-series.maxime.ripard@free-electrons.com

The function supposed to update a plane's coordinates is called in both
branches of our function. Let's move it out the if statement.
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2cd57bcf13652109da7bd5bbe12fa1d29429f02f.1516617243.git-series.maxime.ripard@free-electrons.com

In order to support normalized zpos, we need to call
drm_atomic_normalize_zpos in our driver's drm_mode_config_funcs'
atomic_check.

Let's duplicate the definition of drm_atomic_helper_check for now.
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/67cb4ca9889e6bf29314db37127ff15eed279c53.1516617243.git-series.maxime.ripard@free-electrons.com

There was a typo in the width spelling of the (unused)
SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it.
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6b2e872b611b733a98a38902a2197b70c725e0b9.1516617243.git-series.maxime.ripard@free-electrons.com

The sun4i_plane_desc structure was somehow indented to two tabulations
instead of one as we shoud do. Fix that.
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8a6714bddb865adfcfe2b792e406a2f10bb819bc.1516617243.git-series.maxime.ripard@free-electrons.com

Now that the drm_format_info has a alpha field to tell if a format embeds
an alpha component in it, let's use it.

Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/38d4d0a085634a0b8308e819c846b9173d4d93df.1516617243.git-series.maxime.ripard@free-electrons.com

Now that the drm_format_info has a alpha field to tell if a format embeds
an alpha component in it, let's use it.
Acked-by: NSandy huang <hjc@rock-chips.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5a217e8c93eea6f0a7f6bc5883424b47dbb6c664.1516617243.git-series.maxime.ripard@free-electrons.com

Now that the drm_format_info has a alpha field to tell if a format embeds
an alpha component in it, let's use it.

Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cb1bdfbb481419a17cc4f6c8a1f07930136ac13f.1516617243.git-series.maxime.ripard@free-electrons.com

Now that the drm_format_info has a alpha field to tell if a format embeds
an alpha component in it, let's use it.
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/23518426a46320dd884465cebec0961f839f2972.1516617243.git-series.maxime.ripard@free-electrons.com

There's a bunch of drivers that duplicate the same function to know if a
particular format embeds an alpha component or not.

Let's create a field in the drm_format_info to avoid duplicating that logic
and looking up formats all the time.

Cc: Eric Anholt <eric@anholt.net>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9cd9951d147ff810c1f6f68d79e7983361ed6b68.1516617243.git-series.maxime.ripard@free-electrons.com

There is a difference between the panel/bridge requested pixel clock
value and the real one due to the hw platform clock preciseness (pll,
dividers...). This patch updates the adjusted_mode clock value with
the real hw clock value so then attached encoder & connector can use
it for precise timing computations.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NYannick Fertré <yannick.fertre@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125160101.9102-1-philippe.cornu@st.com

DP 1.4 spec adds a TPS4 training pattern sequence required for
HBR3. This patch adds the corresponding bit definitions in
MAX_DOWNSPREAD register and TRAINING_PATTERN_SET and
inline functions to check if this bit is set and for selecting
a proper TRAINING_PATTERN_MASK that changed to 0x7 on
DP spec 1.4

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-2-git-send-email-manasi.d.navare@intel.com

Existing helpers add support upto HBR2. This patch
adds support for HBR3 rate (8.1 Gbps) introduced as
part of DP 1.4 specification.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516660991-20697-1-git-send-email-manasi.d.navare@intel.com