Backmerge because of numerous and interleaving conflicts and git
rerere getting confused a bit too often.

Conflicts:
	drivers/gpu/drm/i915/intel_display.c

All conflicts are because of -next patches backported to -fixes, so
just go with the code in -next.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.

Refuse to read out the fb state when the primary plane isn't enabled.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: NAndrey Skvortsov <andrej.skvortzov@gmail.com>
Reported-by: NSteven Rostedt <rostedt@goodmis.org>
Reference: http://mid.gmane.org/20150203191507.GA2374@crion86Tested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

vmap_batch() calculates amount of needed pages for the mapping
we are going to create. And it uses this page count as an
argument for the for_each_sg_pages() macro. The macro takes the number
of sg list entities as an argument, not the page count. So we ended
up iterating through all the pages on the mapped object, corrupting
memory past the smaller pages[] array.

Fix this by bailing out when we have enough pages.

This regression has been introduced in

commit 17cabf57
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Jan 14 11:20:57 2015 +0000

    drm/i915: Trim the command parser allocations

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

Setup new I915_GETPARAM ioctl entries for subslice total and
EU total. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can employ fuse register reads as needed to
ensure the most accurate determination of GT config attributes.
This first became important with Cherryview in which the config
could differ between devices with the same PCI ID.

The kernel detection of these values is device-specific and not
included in this patch. Because zero is not a valid value for any of
these parameters, a value of zero is interpreted as unknown for the
device. Userspace drivers should continue to maintain ID-based tables
for older devices not supported by the new query method.

v2: Increment our I915_GETPARAM indices to fit after REVISION
    which was merged ahead of us.

For: VIZ-4636
Signed-off-by: NJeff McGee <jeff.mcgee@intel.com>
Tested-by: NZhigang Gong <zhigang.gong@linux.intel.com>
Acked-by: NZhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Same as

commit c883ef1b
Author: Mika Kuoppala <miku@iki.fi>
Date:   Tue Oct 28 17:32:30 2014 +0200

    drm/i915: Redefine WARN_ON to include the condition

but for WARN_ON_ONCE. Since the kernel WARN_ON_ONCE actually picks up
*our* version of WARN_ON, we end up with messages like

[  838.285319] WARN_ON(!__warned)

which are not that helpful.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines
    (Nick Hoath)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89554Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CHV should be in a good enough shape now, so let's drop the
.is_preliminary flag.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We accidentally pass 'pipe' instead of 'port' to CHV_PLL_DW8() and
with PIPE_C we end up at register offset 0x8320 which isn't the
0x8020 we wanted. Fix it.

The problem was fortunately caught by the sanity check in vlv_dpio_read():
WARNING: CPU: 1 PID: 238 at ../drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x77/0x80 [i915]()
DPIO read pipe C reg 0x8320 == 0xffffffff

The problem got introduced with this commit:
 commit 71af07f91f12bbab96335e202c82525d31680960
 Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
 Date:   Thu Mar 5 19:33:08 2015 +0530

    drm/i915: Update prop, int co-eff and gain threshold for CHV

Cc: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ignore the current state of the pipe and just check crtc_state->enable
and the number of FDI lanes required. This means we don't accidentally
mistake the FDI lanes as being available of one of the pipes just
happens to be disabled at the time of the check. Also we no longer
consider pipe C to require FDI lanes when it's driving the eDP
transcoder.

We also take the opportunity to make the code a bit nicer looking by
hiding the ugly bits in the new pipe_required_fdi_lanes() function.

Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The logic in the FDI lane checks is very hard for my poor brain to
grasp. Rewrite it in a more straightforward way.

Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enable the RPS interrupts programming(enable/disable/reset) for GEN9,
as missing changes to enable the RPS support on GEN9 have been added.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Earlier Turbo interrupts were not being processed for SKL,
as something was amiss in turbo programming for SKL.
Now missing changes have been added, so enabling the Turbo
interrupt processing for SKL.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added support for SKL in the i915_frequency_info debugfs function

v2:
- corrected the handling of reqf (Damien)
- Reorderd the platform check for cagf (Ville)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove the global modeset resource function that would disable the
bifurcation bit, and instead enable/disable it when enabling the pch
transcoder. The mode set consistency check should prevent us from
disabling the bit if pipe C is enabled so the change should be safe.

Note that this doens't affect the logic that prevents the bit being
set while a pipe is active, since the patch retains the behavior of
only chaging the bit if necessary. Because of the checks during mode
set, the first change would necessarily happen with both pipes B and
C disabled, and any subsequent write would be skipped.

v2: Only change the bit during pch trancoder enable. (Ville)
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: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added support for SKL in the act_freq_mhz_show sysfs function
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On SKL, GT frequency is programmed in units of 16.66 MHZ units compared
to 50 MHZ for older platforms. Also the time value specified for Up/Down EI &
Up/Down thresholds are expressed in units of 1.33 us, compared to 1.28
us for older platforms. So updated the gen9_enable_rps function as per that.

v2: Updated to use new macro GT_INTERVAL_FROM_US

v3: Removed the initial setup of certain registers, from gen9_enable_rps,
    which gets overridden later from gen6_set_rps (Damien)

v4: Removed the enabling of rps interrupts, from gen9_enable_rps.
    To be done from intel_gen6_powersave_work only, as done for other
    platforms also.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

RP Interrupt Up/Down Frequency Limits register (A014) definition
has changed for SKL. Updated the gen6_rps_limits function as per that

v2: Renamed the function to intel_rps_limits (Chris)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prior to SKL, the time period programmed in Up/Down EI & Up/Down
threshold registers was in units of 1.28 micro seconds. But for
SKL, the units have changed (1.333 micro seconds).
Have generalized the implementation of gen6_set_rps_thresholds function,
by removing the hard coding done in it as per 1.28 micro seconds.

v2: Renamed the local variables & removed superfluous comments (Chris)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On SKL, the frequency is programmed differently in RPNSWREQ (A008)
register (from bits 23 to 31, compared to bits 24 to 31). So updated
the gen6_set_rps function, as per this change.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On SKL the frequency is specified in units of 16.66 MHZ, barring the
RP_STATE_CAP(0x5998) register, which still reports frequency in units
of 50 MHZ. So an extra conversion is required in gen6_init_rps_frequencies
function for SKL, to store the frequency values as per the actual hardware unit.

v2: Corrected the conversion from 50 to 16.66 MHZ (Ville)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On SKL, frequency is specified in units of 16.66 MHZ.
Updated the intel_gpu_freq() and intel_freq_opecode() functions
to do the conversion appropriately.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For SKL, register definition for RPNSWREQ (A008), RPSTAT1(A01C)
have changed slightly. Also on SKL, frequency is specified in
units of 16.66 MHZ, compared to 50 MHZ for most of the earlier
platforms and the time values are expressed in units of 1.33 us,
compared to 1.28 us for earlier platforms.
Added new macros for the aforementioned changes.

v2: Renamed the GT_FREQ_FROM_PERIOD macro to GT_INTERVAL_FROM_US (Damien)

v3: Removed the implicit use of dev_priv in GT_INTERVAL_FROM_US macro (Chris)
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spell all the PCI IDs out to be able to quickly grep for the IDs. No
functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Add GT1/2 to comments to not loose that distinction.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the FW_WM() macro from the VLV wm code to polish up the wm
code for older gmch platforms.

Cc: Daniel Vetter <daniel@ffwll.ch>
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>

Wrap the FW register value shift+mask operations into a macro to hide
the ugliness a bit. Also might avoid bugs due to typos.

Also rename all the primary/sprite plane low order bit masks to have the
_VLV suffix, so that we can use the FW_WM_VLV() macro instead of the
FW_WM() macro for them in a consistent manner. Cursor and all the high
order bits are left to use the FW_WM() macro as there's no real
confusion with them.

Cc: Daniel Vetter <daniel@ffwll.ch>
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>

plane->fb is not as reliable as plane->state->fb so let's convert
intel_plane_restore() over the the new way of thinking as well.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No need to go dig throguh intel_crtc->base.cursor when we already have
the same thing as 'plane' local variable.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are now called from the plane commit hooks, so they really need to
be fast or else we risk atomic update failures. So kill the debug prints
which are slowing things down massively.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Without this Dave's 32bit rhel compiler is annoyed. Don't ask me about
the exact rules for this stuff though, but this should be safe.
Reported-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

I have no idea about the exact rules, but this angered Dave's 32bit
rhel gcc.
Reported-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled.  This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference.  The offending commits are:

        commit fd2d61341bf39d1054256c07d6eddd624ebc4241
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Fri Feb 27 10:12:01 2015 -0800

            drm/i915: Use plane->state->fb in watermark code (v2)

and

        commit 0fda6568
        Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
        Date:   Fri Feb 27 15:12:35 2015 +0000

            drm/i915/skl: Update watermarks for Y tiling

The first commit causes us to use the FB from plane->state->fb rather
than the legacy plane->fb, which is updated a bit later in the process.

The second commit includes a change that now triggers watermark
reprogramming on primary plane enable/disable where we didn't have one
before (which wasn't really correct, but we had been getting lucky
because we always calculated as if the primary plane was on).

Together, these two commits cause the watermark calculation to
(properly) see plane->state->fb = NULL when we're in the process of
disabling the primary plane.  However the existing watermark code
assumes there's always a primary fb and tries to dereference it to find
out pixel format / bpp information.

The fix is to make ILK-style watermark calculation actually check the
true status of primary & cursor planes and adjust our watermark logic
accordingly.

v2: Update unchecked uses of state->fb for other platforms (pnv, skl,
    etc.).  Note that this is just a temporary fix.  Ultimately the
    useful information is going to be computed at check time and stored
    right in the state structures so that we don't have to figure this
    all out while we're supposed to be programming the watermarks.
    (caught by Tvrtko)

v3: Fix a couple copy/paste mistakes in SKL code. (Tvrtko)

v4: Only add FB checks for ILK/SKL codepaths.  Older platforms still use
    intel_crtc_active() and will shortcircuit out of watermark
    calculations before ever trying to dereference the primary plane's
    framebuffer.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: NMichael Leuchtenburg <michael@slashhome.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89388Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must not hold that lock.

Regression from commit ab8d6675
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Mon Feb 2 15:44:15 2015 +0000

    drm/i915: Track old framebuffer instead of object

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
[danvet: Clarify commit message slightly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DDR DVFS introduces massive memory latencies which can't be handled by
the PND deadline stuff. Instead the watermarks will need to be
programmed to compensate for the latency and the deadlines will need to
be programmed to tight fixed values. That means DDR DVFS can only be
enabled if the display FIFOs are large enough, and that pretty much
means we have to manually repartition them to suit the needs of the
moment.

That's a lot of change, so in the meantime let's just disable DDR DVFS
to get the display(s) to be stable.
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>

CHV has a new knob in Punit to select between some memory power savings
modes PM2 and PM5. We can allow the deeper PM5 when maxfifo mode is
enabled, so let's do so in the hopes for moar power savings.

v2: Put the thing into a separate function to avoid churn later
v3: Don't break VLV
Reviewed-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NArun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

PFI credit programming is required when CD clock (related to data flow from
display pipeline to end display) is greater than CZ clock (related to data
flow from memory to display plane). This programming should be done when all
planes are OFF to avoid intermittent hangs while accessing memory even from
different Gfx units (not just display).

If cdclk/czclk >=1, PFI credits could be set as any number. To get better
performance, larger PFI credit can be assigned to PND. Otherwise if
cdclk/czclk<1, the default PFI credit of 8 should be set.

v2:
    - Change log to lower log level instead of DRM_ERROR
    - Change function name to valleyview_program_pfi_credits
    - Move program PFI credits to modeset_init instead of intel_set_mode
    - Change magic numbers to logical constants

[vsyrjala v3:
 - only program in response to cdclk update
 - program the credits also when cdclk<czclk
 - add CHV bits
 v4:
 - Change CHV cdclk<czclk credits to 12 (Vijay)]
Signed-off-by: NVidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: NGajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
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>

Assuming the PND deadline mechanism works reasonably we should do
memory requests as early as possible so that PND has schedule the
requests more intelligently. Currently we're still calculating
the watermarks as if VLV/CHV are identical to g4x, which isn't
the case.

The current code also seems to calculate insufficient watermarks
and hence we're seeing some underruns, especially on high resolution
displays.

To fix it just rip out the current code and replace is with something
that tries to utilize PND as efficiently as possible.

We now calculate the WM watermark to trigger when the FIFO still has
256us worth of data. 256us is the maximum deadline value supoorted by
PND, so issuing memory requests earlier would mean we probably couldn't
utilize the full FIFO as PND would attempt to return the data at
least in at least 256us. We also clamp the watermark to at least 8
cachelines as that's the magic watermark that enabling trickle feed
would also impose. I'm assuming it matches some burst size.

In theory we could just enable trickle feed and ignore the WM values,
except trickle feed doesn't work with max fifo mode anyway, so we'd
still need to calculate the SR watermarks. It seems cleaner to just
disable trickle feed and calculate all watermarks the same way. Also
trickle feed wouldn't account for the 256us max deadline value, thoguh
that may be a moot point in non-max fifo mode sicne the FIFOs are fairly
small.

On VLV max fifo mode can be used with either primary or sprite planes.
So the code now also checks all the planes (apart from the cursor)
when calculating the SR plane watermark.

We don't have to worry about the WM1 watermarks since we're using the
PND deadline scheme which means the hardware ignores WM1 values.

v2: Use plane->state->fb instead of plane->fb
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>

There are some cases like suspend/resume or dpms off/on sequences
that can flush frontbuffer bits. In these cases features that relies
on frontbuffer tracking can start working and user can stop getting
screen updates on fbcon having impression the system is frozen.

So, let's make sure we also invalidate frontbuffer on fbdev blank.

v2: Daniel was right, backtrace didn't show other path than this blank
one so let's make sure frontbuffer bits gets invalidate here instead of
on random write operations that doesn't garantee we track all frontbuffer
writes.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Exchange code comments for one that complains about the
locking, like in set_par.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch implements latest PHY changes in Gain, prop and int co-efficients
based on the vco freq.

v2: Split the original changes into multiple smaller patches based on
review by Ville

v3: Addressed Ville's review comments. Fixed the error introduced in v2.
Clear the old bits before we modify those bits as part of RMW.

v4: TDC target cnt is 10 bits and not 8 bits (Ville)
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.

v2: Split the changes into multiple smaller patches (Ville)
v3: Clear out the old bits before we modify those bits as RMW (Ville)
v4: Reset coarse threshold when M2 fraction is enabled (Ville)
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>