The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old VLV bit layout, some the new
layout, and all of them seem to tell us nonsense about the cdclk
value encoding.

Testing on actual hardware has shown that we simply need to program
the desired CCK divider into the Punit register using the new layout of
the bits. Doing that, the status bit change to indicate the same value,
and the CCK 0x6b register also changes accordingly to indicate that CCK
is now using the new divider.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: NYogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Supposedly CHV can sustain a pixel clock of up to 95% of
cdclk, as opposed to the 90% limit that was used old older
platforms. Update the cdclk selection code to allow for this.

This will allow eg. HDMI 4k modes with their 297MHz pixel clock
while still respecting the 320 MHz cdclk limit on CHV.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: NYogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So try to enumerate eDP unconditionally in those cases.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add wa tag Damien dug out.]
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I was dumping the DDI translation tables to make sure my patch updating
the HDMI entry was doing the right thing when I noticed that the table
was showing reset values after DPMS.

And indeed, the DDI translation registers are in power well 1 on SKL,
and so we're losing their values when shutting down eDP.

Calling intel_prepare_ddi() on PW1 enabling re-programs the table.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't use this function on gen9, no need for that test here.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pipe interrupt registers are in the actual pipe power well, so we
need to restore them when re-enable the corresponding power well.

I've also copied what we do on HSW/BDW for VGA, even if the we haven't
enabled unclaimed registers just yet.

v2: Don't run skl_power_well_post_enable() if the power well is already
    enabled (Paulo)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just to be more consistent with what we do on HSW.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just like what we do for HSW/BDW, having those variables makes it a bit
easier to parse the code.
Suggested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While we only need to restore pipe B/C interrupt registers on BDW when
enabling the power well, skylake a bit more flexible and we'll also need
to restore the pipe A registers as it has its own power well that can be
toggled.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Collect the currently enabled counts of slice, subslice, and
execution units using the power gate control ack message
registers specific to Cherryview.

Slice/subslice/EU info and hardware status can now be
determined for CHV, so allow the debugfs SSEU status dump
to proceed for CHV devices.
Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Total EU was already being detected on CHV, so we just add the
additional info parameters. The detection method is changed to
be more robust in the case of subslice fusing - we don't want
to trust the EU fuse bits corresponding to subslices which are
fused-off.

v2: Fixed subslice disable bitmasks and removed unnecessary ?
    operation (Ville)
Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Poke at the CBR1_VLV register during init_clock_gating to make sure the
PND deadline scheme is used.

The hardware has two modes of operation wrt. watermarks:

1) PND deadline mode:
 - memory request deadline is calculated from actual FIFO level * DDL
 - WM1 watermark values are unused (AFAIK)
 - WM watermark level defines when to start fetching data from memory
   (assuming trickle feed is not used)

2) backup mode
 - deadline is based on FIFO status, DDL is unused
 - FIFO split into three regions with WM and WM1 watermarks, each
   part specifying a different FIFO status

We want to use the PND deadline mode, so let's make sure the chicken
bit is in the correct position on init.

Also take the opportunity to refactor the shared code between VLV and
CHV to a shared function.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV/CHV have similar DSPARB registers as older platforms, just more of
them due to more planes. Add a bit of code to read out the current FIFO
split from the registers. Will be useful later when we improve the WM
calculations.

v2: Add display_mmio_offset to DSPARB
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we have drm_planes for the cursor and primary we can move the
pixel_size handling into vlv_compute_drain_latency() and just pass the
appropriate plane to it.

v2: Check plane->state->fb instead of plane->fb

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict with Matt's s/plane->fb/plane->state->fb/
patch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduce struct vlv_wm_values to house VLV watermark/drain latency
values. We start by using it when computing the drain latency values.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the DDL precision handling into vlv_compute_drain_latency() so the
callers don't have to duplicate the same code to deal with it.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current drain lantency computation relies on hardcoded limits to
determine when the to use the low vs. high precision multiplier.
Rewrite the code to use a more straightforward approach.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kill the silly DRAIN_LATENCY_PRECISION_* defines and just use the raw
number instead.

v2: Move the sprite 32/16 -> 16/8 preision multiplier
    change to another patch (Jesse)
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently we must yet halve the DDL drain latency from what we're
using currently. This little nugget is not in any spec, but came
down through the grapevine.

This makes the displays a bit more stable. Not quite fully stable but at
least they don't fall over immediately on driver load.

v2: Update high_precision in valleyview_update_sprite_wm() too (Jesse)
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we have a single unclaimed register, we will have lots. A WARN for
each one makes the machine unusable and does not aid debugging. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up. Even when i915.mmio_debug was disabled it would
continue to shout an *ERROR* for every interrupt, without any
information at all for debugging.

The massive verbiage was added in
commit 5978118c
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Wed Jul 16 17:49:29 2014 -0300

    drm/i915: reorganize the unclaimed register detection code

v2: Automatically enable invalid mmio reporting for the *next* invalid
access if mmio_debug is disabled by default. This should give us clearer
debug information without polluting the logs too much.
v3: Compile fixes, rebase.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Update modparam text per the thread.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit 05a2fb15 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.

Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused code
from decaying and having to update it for other driver changes, it was decided
to simply remove it.

For: VIZ-5115
Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to disable all sprite planes when disabling the CRTC.  We had
been using the top-level atomic 'disable' entrypoint to accomplish this,
which was wrong.  Not only can this lead to various locking issues, it
also modifies the actual plane state, making it impossible to restore
the plane properly later.  For example, a DPMS off followed by a DPMS on
will result in any sprite planes in use not being restored properly.

The proper solution here is to call directly into our 'commit plane'
hook with a copy of the plane's current state that has 'visible' set to
false.  Committing this dummy state will turn off the plane, but will
not touch the actual plane->state pointer, allowing us to properly
restore the plane state later.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the requested size is less than what the full range
of pdps can address, we end up setting pdps for only the
requested area.

The logical context however needs all pdp entries to be valid.
Prior to commit 06fda602 ("drm/i915: Create page table allocators")
we have been writing pdp entries with dma address of zero instead
of valid pdps. This is supposedly bad even if those pdps are not
addressed.

As commit 06fda602 ("drm/i915: Create page table allocators")
introduced more dynamic structure for pdps, we ended up oopsing
when we populated the lrc context. Analyzing this oops revealed
the fact that we have not been writing valid pdps with bsw, as
it is doing the ppgtt init with 2GB limit in some cases.

We should do the right thing and setup the non addressable part
pdps/pde/pte to scratch page through the minimal structure by
having just pdp with pde entries pointing to same page with
pte entries pointing to scratch page.

But instead of going through that trouble, setup all the pdps
through individual pd pages and pt entries, even for non
addressable parts. And let the clear range point them to scratch
page. This way we populate the lrc with valid pdps and wait
for dynamic page allocation work to land, and do the heavy lifting
for truncating page table tree according to usage.

The regression of oopsing in init was introduced by
commit 06fda602 ("drm/i915: Create page table allocators")

v2: Clear the range for the unused part also (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89350
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NValtteri Rantala <valtteri.rantala@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Making the link_clock half in switch inline with the DPLL_CTRL1_* macros
(Ville)
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDp 1.4 supports custom frequencies.
Skylake supports following intermediate frequencies : 3.24 GHz, 2.16 GHz and
4.32 GHz along with usual LBR, HBR and HBR2 frequencies.
Read sink supported frequencies and get common frequencies from sink and
source and use these for link training.

v2: Rebased, removed calculation of min_clock since for edp it is taken as
max_clock (as per comment).
v3: Keeping single array for link rates (Satheesh)
v4: Setting LINK_BW_SET to 0 when setting LINK_RATE_SET (Satheesh)
v5: Some minor nits (Ville)
v6: Keeping separate arrays for source and sink rates (Ville)
v7: Remove redundant setting of DP_LINK_BW_SET to 0 (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Using DP_SUPPORTED_LINK_RATES macro for supported_rates array (Satheesh).
v3: Reading dpcd's supported link rates tables based upon edp version in the
same patch.
v4: Move version check under is_edp (Satheesh)
v5: Using le16 for rates, some naming, and removing nested if block (Ville)
v6: Correctly using DP_MAX_SUPPORTED_RATES and removing DP_SUPPORTED_LINK_RATES
(Ville)
v7: Incorrectly removed DP_SUPPORTED_LINK_RATES in v6, re-adding it
v8: Checking return value of intel_dp_dpcd_read_wake() (Ville)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kill the blt/render tracking we currently have and use the frontbuffer
tracking infrastructure.

Don't enable things by default yet.

v2: (Rodrigo) Fix small conflict on rebase and typo at subject.
v3: (Paulo) Rebase on RENDER_CS change.
v4: (Paulo) Rebase.
v5: (Paulo) Simplify: flushes don't have origin (Daniel).
            Also rebase due to patch order changes.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In invalidate and flush functions of eDP DRRS, if deferred downclock
work starts execution at a time window between acquiring the drrs
mutex and cancellation of the deferred work
(intel_edp_drrs_downclock_work), then deferred work will find
drrs mutex locked and wait for the same.

Meanwhile the function that acquired mutex drrs invalidate/flush will
wait for the completion of the deferred work before releasing the mutex.
Thats a deadlock.

To avoid such deadlock scenario, this change cancels the deferred work
before acquiring the mutex at invalidate and flush functions.
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adding a debugfs entry to determine if DRRS is supported or not

V2: [By Ram]: Following details about the active crtc will be filled
	in seq-file of the debugfs
	1. Encoder output type
	2. DRRS Support on this CRTC
	3. DRRS current state
	4. Current Vrefresh
Format is as follows:
CRTC 1:  Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_HIGH_RR, Vrefresh: 60
CRTC 2:  Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
CRTC 1:  Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_LOW_RR, Vrefresh: 40
CRTC 2:  Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless

V3: [By Ram]: Readability is improved.
	Another error case is covered [Daniel]

V4: [By Ram]: Current status of the Idleness DRRS along with
	the Front buffer bits are added to the debugfs. [Rodrigo]

V5: [By Ram]: Rephrased to make it easy to understand.
	And format is modified. [Rodrigo]

V6: [By Ram]: Modeset mutex are acquired for each crtc along with
	renaming the Idleness detection states  [Daniel]
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: dump full busy_frontbuffer_bits and remove the dubios
computed logical state of DRRS - debugfs is about what is fact,
developers should reach their own conclusion when debugging issues.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adds a parameter which can be used with DRM_I915_GETPARAM to query the
GPU revision. The intention is to use this in Mesa to implement the
WaDisableSIMD16On3SrcInstr workaround on Skylake but only for
revision 2.
Signed-off-by: NNeil Roberts <neil@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When logging that full mode switch is necessary, log which connector,
encoder or crtc has caused it, so it is easier to figure out what is
goind on by just looking at the log.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have similar macros for crtcs and encoders, and the pattern happens
often enough to justify the macro.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the path were there is no state to duplicate, the allocated crtc
state wouldn't have the crtc backpointer initialized.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current minimum vco frequency leaves us with a gap in our supported
frequencies at 233-243 MHz. Your typical 2560x1440@60 display wants a
pixel clock of 241.5 MHz, which is just withing that gap. Reduce the
allowed vco min frequency to 4.8GHz to reduce the gap to 233-240 MHz,
and thus allow such displays to work.

4.8 GHz is actually the documented (at least in some docs) limit of the
PLL, and we just picked 4.86 GHz originally because that was the lowest
value produced by the PLL spreadsheet, which obviously didn't consider
2560x1440 displays.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this for FBC, and possibly for PSR too.

v2: Don't only flush: invalidate too (Daniel).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.

v2: - s/ORIGIN_RENDER/ORIGIN_CS/ (Daniel, Rodrigo)
    - Fix copy/pasted wrong documentation
    - Rebase
v3: - Rebase
v4: - Don't pass the operation to flushes (Daniel).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 3f678c96.

We've been a bit too optimistic with this one here :(

The trouble is that internally we're still using these plane
update/disable hooks. Which was totally ok pre-atomic since the drm
core did all the book-keeping updating and these just mostly updated
hw state. But with atomic there's lots more going on, and it causes
heaps of trouble with the load detect code.

This one specifically cause a deadlock since both the load detect code
and the nested plane atomic helper functions tried to grab the same
locks. It only blows up because of the evil tricks though we play with
the implicit ww acquire context.

Applying this revert unearths the NULL deref on already freed
framebuffer objects reported as a regression in 4.0 by various people.

Fixing this will be fairly invasive, hence revert even for the
4.1-next queue.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Acked-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This translation entry was updated after electrical validation by the hw
team. The other entries are removed from existence as they aren't
validated and because the sole use of a certain type of level shifter
for SKL products is anticipated.

v2: Remove all the other entries and force the use of the 800mv+2dB
    config (Sonika)
Suggested-by: NSonika Jindal <sonika.jindal@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSonika Jindal <sonika.jindal@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>