copy_from_user_inatomic() is actually a local function that returns
-EFAULT or positive values on error.  Otherwise copy_from_user() returns
the number of bytes remaining to be copied.  We want to return -EFAULT
here.

I removed an unlikely() because we just did a copy_from_user()
so I don't think it can possibly make a difference.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Extend the DSI PHY/PLL drivers to support the DSI 14nm PHY/PLL
found on 8x96.

These are picked up from the downstream driver. The PHY part is similar
to the other DSI PHYs. The PLL driver requires some trickery so that
one DSI PLL can drive both the DSIs (i.e, dual DSI mode).

In the case of dual DSI mode. One DSI instance becomes the clock master,
and other the clock slave. The master PLL's output (Byte and Pixel clock)
is fed to both the DSI hosts/PHYs.

When the DSIs are configured in dual DSI mode, the PHY driver communicates
to the PLL driver using msm_dsi_pll_set_usecase() which instance is the
master and which one is the slave. When setting rate, the master PLL also
configures some of the slave PLL/PHY registers which need to be identical
to the master's for correct dual DSI behaviour.

There are 2 PLL post dividers that should have ideally been modelled as
generic clk_divider clocks, but require some customization for dual DSI.
In particular, when the master PLL's post-diviers are set, the slave PLL's
post-dividers need to be set too. The clk_ops for these use clk_divider's
helper ops and flags internally to prevent redundant code.

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The 14nm DSI PHY on 8x96 (called PHY v2 downstream) requires a different
set of calculations for computing D-PHY timing params. Create a
timing_calc_v2 func for the newer v2 PHYs.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Since DSI PHY has been a separate platform device, it should not
depend on the resources in host to be functional. This change is
to trigger PHY operations in manager, instead of host, so that
host and PHY can be completely separated.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In case of dual DSI, some registers in PHY1 have been programmed
during PLL0 clock's set_rate. The PHY1 reset called by host1 later
will silently reset those PHY1 registers. This change is to reset
and enable both PHYs before any PLL clock operation.

[Originally worked on by Hai Li <hali@codeaurora.org>. Fixed up
by Archit Taneja <architt@codeaurora.org>]
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

For some new types of DSI PHY, more settings depend on
use cases controlled by DSI manager. This change allows
DSI manager to setup PHY with a use case.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The DSI host is required to configure more timings calculated
in PHY. By introducing a shared structure, this change allows
more timing information passed from PHY to host.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Create an init() op for dsi_phy which sets up things specific to
a given DSI PHY.

The dsi_phy driver probe expects every DSI version to get a
"dsi_phy_regulator" mmio base. This isn't the case for 8x96.
Creating an init() op will allow us to accommodate such
differences.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add 8x96 DSI data in dsi_cfg. The downstream kernel's dsi_host driver
enables core_mmss_clk. We're seeing some branch clock warnings on
8x96 when enabling this. There doesn't seem to be any negative effect
with not enabling this clock, so use it once we figure out why we
get the warnings.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The driver returns an error if a DSI DT node is populated, but no device
is connected to it or if the data-lane map isn't present. Ideally, such
a DSI node shouldn't be probed at all (i.e, its status should be set to
"disabled in DT"), but there isn't any harm in registering the DSI device
even if it doesn't have a bridge/panel connected to it.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This code has been more or less picked up from the vc4 and intel
implementations of update_plane() funcs for cursor planes.

The update_plane() func is usually the drm_atomic_helper_update_plane
func that will issue an atomic commit with the plane updates. Such
commits are not intended to be done faster than the vsync rate.

The legacy cursor userspace API, on the other hand, expects the kernel
to handle cursor updates immediately.

Create a fast path in update_plane, which updates the cursor registers
and flushes the configuration. The fast path is taken when there is only
a change in the cursor's position in the crtc, or a change in the
cursor's crop co-ordinates. For anything else, we go via the slow path.

We take the slow path even when the fb changes, and when there is
currently no fb tied to the plane. This should hopefully ensure that we
always take a slow path for every new fb. This in turn should ensure that
the fb is pinned/prepared.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In mdp5_plane_atomic_check, we get crtc_state from drm_plane_state.

Later, for cursor planes, we'll populate the update_plane() func that
takes a fast asynchronous path to implement cursor movements. There, we
would need to call a similar atomic_check func to validate the plane
state, but crtc_state would need to be derived differently.

Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state
such that the latter takes crtc_state as an argument.

This is similar to what the intel driver has done for async cursor
updates.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Register cursor drm_planes. The loop in modeset_init that inits the
planes and crtcs has to be refactored a bit. We first iterate all the
hwpipes to find the cursor planes. Then, we loop again to create
crtcs.

In msm_atomic_wait_for_commit_done, remove the check which bypasses
waiting for vsyncs if state->legacy_cursor_updates is true.

We will later create a fast path for cursor position changes in the
cursor plane's update_plane func that doesn't go via the regular
atomic commit path. For rest of cursor related updates, we will have
to wait for vsyncs, so ignore the legacy_cursor_updates flag.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

These are various changes added in preparation for cursor planes:

- Add a pipe_cursor block for 8x96 in mdp5_cfg.
- Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
  assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
- Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor
  SSPPs.
- In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt,
  we need to do this because we can now have empty stages in between.
- In mdp5_crtc_atomic_check, make sure that the cursor plane has the
  highest zorder, and stage the cursor plane to the maximum stage #
  present on the HW.
- Create drm_crtc_funcs that doesn't try to implement cursors using the
  older LM cursor HW.
- Pass drm_plane_type in mdp5_plane_init instead of a bool telling
  whether plane is primary or not.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In MDP5 Layer Mixer HW, the blender output is only the blended color
components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
is fed to the BG input of the next blender. We also need to provide an
alpha (COLOR3) value for the BG input at the next stage.

This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register.
For each stage, we can propagate either the BG or FG alpha to the next
stage.

The approach taken by the driver is to propagate FG alpha, if the plane
staged on that blender has an alpha. If it doesn't, we try to propagate
the base layer's alpha.

This is borrowed from downstream MDP5 kernel driver. Without this, we
don't see any cursor plane content.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The MDP5 plane's atomic_check ops doesn't perform clipping tests.
This didn't hurt us much in the past, but clipping becomes important
with cursor planes.

Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers
already do. Use these drivers as reference.

Clipping requires knowledge of the crtc width and height. This requires
us to call drm_atomic_helper_check_modeset before
drm_atomic_helper_check_planes in the driver's atomic_check op, because
check_modetest will populate the mode for the crtc, needed to populate
the clip rectangle.

We update the plane_enabled(state) local helper to use state->visible,
since state->visible and 'state->fb && state->crtc' represent the same
thing.

One issue with the existing code is that we don't have a way to disable
the plane when it's completely clipped out. Until there isn't an update
on the crtc (which would de-stage the plane), we would still see the
plane in its last 'visible' configuration.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
the drm_plane. Returning '0' means we are returning VIG0 pipe.

Also, use the mdp5_pipe enum to pass around the stage array. Initialize
the stage to SSPP_NONE by default.

We do the above because 1) Cursor plane has to be staged at the topmost
blender of the LM, which can result in empty stages in between 2) In
the future, when we support multiple LMs per CRTC. We could have stages
which don't have any pipe assigned to them.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We currently create CRTCs equaling to the # of Layer Mixer blocks we
have on the MDP5 HW. This number is generally more than the # of encoders
(INTFs) we have in the MDSS HW. The number of encoders connected to
displays on the platform (as described by DT) would be even lesser.

Create only N drm_crtcs, where N is the number of drm_encoders
successfully registered. To do this, we call modeset_init_intf() before
we init the drm_crtcs and drm_planes.

Because of this change, setting encoder->possible_crtcs needs to be moved
from construct_encoder() to a later point when we know how many CRTCs we
have.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Count can't be non-zero. Changing to uint will also prevent future
warnings.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

For the DSI interfaces, the mdp5_kms core creates 2 encoders for video
and command modes.

Create only a single encoder per interface. When creating the encoder, set
the interface type to MDP5_INTF_MODE_NONE. It's the bridge (DSI/HDMI/eDP)
driver's responsibility to set a different interface type. It can use the
the kms func op set_encoder_mode to change the mode of operation, which
in turn would configure the interface type for the INTF.

In mdp5_cmd_encoder.c, we remove the redundant code, and make the commmand
mode funcs as helpers that are used in mdp5_encoder.c
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Rename the mdp5_encoder_* ops for active displays to
mdp5_vid_encoder_* ops.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for Video Mode and the other
for Command Mode operation. The reason behind this approach could have
been that we aren't aware of the DSI device's mode of operation when
we create the encoders.

This makes things a bit complicated, since these encoders have to
be further attached to the same DSI bridge. The easier way out is
to create a single encoder, and make the DSI driver set its mode
of operation when we know what the DSI device's mode flags are.

Start with providing a way to set the mdp5_intf_mode using a kms
func that sets the encoder's mode of operation. When constructing
a DSI encoder, we set the mode of operation to Video Mode as
default. When the DSI device is attached to the host, we probe the
DSI mode flags and set the corresponding mode of operation.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We currently create 2 encoders for DSI interfaces, one for command
mode and other for video mode operation. This isn't needed as we
can't really use both the encoders at the same time. It also makes
connecting bridges harder.

Switch to creating a single encoder. For now, we assume that the
encoder is configured only in video mode. Later, the same encoder
would be usable in both modes.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.

The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.

msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.

Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.

Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Define the block in advance so that the generated mdp5.xml.h doesn't
break build.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Suggested by Rob Herring.  We still support the old names for
compatibility with downstream android dt files.

Cc: Rob Herring <robh@kernel.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Acked-by: NRob Herring <robh@kernel.org>

This was never documented or used in upstream dtb.  It is used by
downstream bindings from android device kernels.  But the quirks are
a property of the gpu revision, and as such are redundant to be listed
separately in dt.  Instead, move the quirks to the device table.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>

The original way we determined the gpu version was based on downstream
bindings from android kernel.  A cleaner way is to get the version from
the compatible string.

Note that no upstream dtb uses these bindings.  But the code still
supports falling back to the legacy bindings (with a warning), so that
we are still compatible with the gpu dt node from android device
kernels.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Acked-by: NRob Herring <robh@kernel.org>

The plan is to use the OPP bindings.  For now, remove the documentation
for qcom,gpu-pwrlevels, and make the driver fall back to a safe low
clock if the node is not present.

Note that no upstream dtb use this node.  For now we keep compatibility
with this node to avoid breaking compatibility with downstream android
dt files.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Acked-by: NRob Herring <robh@kernel.org>

The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.

In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.

v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # vmwgfx
Reviewed-by: Lucas Stach <l.stach@pengutronix.de> #etnaviv
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk

Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure.  I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.

I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates.  The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.

// <smpl>
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)

@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
// </smpl>

Changes since v1:
 - Rebased on top of the tip of drm-misc-next.
 - Remove mention to sti since a proper fix got merged.
Suggested-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk

Since we need to change the implementation, stop exposing internals.

Provide kref_read() to read the current reference count; typically
used for debug messages.

Kills two anti-patterns:

	atomic_read(&kref->refcount)
	kref->refcount.counter
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Fixes: 9cb07b099fb ("drm/msm: support multiple address spaces")
Reported-by: NRiku Voipio <riku.voipio@linaro.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

It would race between userspace thread and commit worker.  Ie. vblank
irq would trigger event and userspace could begin the next atomic
update, before the commit worker had a chance to clear the pending
flag.

If we do end up needing something to prevent userspace from trying
another pageflip before getting vblank event, it should probably be
implemented as a pending_planes bitmask, similar to pending_crtcs.  See
start_atomic() and end_atomic().
Signed-off-by: NRob Clark <robdclark@gmail.com>

This is the deprecated function for when you embedded the framebuffer
somewhere else (which breaks refcounting). But msm is using
drm_framebuffer_remove and a free-standing fb, so this is rendundant.

Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482835765-12044-1-git-send-email-daniel.vetter@ffwll.ch

Many DRM drivers only work with an MMU, and after the patch to enable
core DRM support without MMU, we already had one fixup for many of them.
The etnaviv, armada and msm drivers were missed and have the same problem:

warning: (DRM_ETNAVIV) selects IOMMU_SUPPORT which has unmet direct dependencies (MMU)
warning: (DRM_I915 && DRM_MSM && DRM_ETNAVIV) selects SHMEM which has unmet direct dependencies (MMU)
drivers/gpu/drm/armada/armada_gem.o: In function `armada_gem_vm_fault':
armada_gem.c:(.text.armada_gem_vm_fault+0x14): undefined reference to `vm_insert_pfn'
arch/arm/mm/dma-mapping.c: In function '__iommu_alloc_remap':
arch/arm/mm/dma-mapping.c:1390:4: error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function)
arch/arm/mm/dma-mapping.c:1456:31: error: 'atomic_pool' undeclared (first use in this function); did you mean 'atomic_xor'?

Fixes: 011cda58 ("drm: fix compilations issues introduced by "drm: allow to use mmuless SoC"")
Fixes: 62a0d98a ("drm: allow to use mmuless SoC")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111133357.3664191-2-arnd@arndb.de

Including all drivers. I thought about keeping small compat functions
to avoid having to change all drivers. But I really like the
drm_printer idea, so figured spreading it more widely is a good thing.

v2: Review from Chris:
- Natural argument order and better name for drm_mm_print.
- show_mm() macro in the selftest.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jyri Sarha <jsarha@ti.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483009764-8281-1-git-send-email-daniel.vetter@ffwll.ch