Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.

Addtional note from Imre:

Currently we keep DC6 enabled during modesets and DPAUX transfers, which
is not allowed according to the specification. This can lead at least to
PLL locking failures, DPAUX timeouts and prevent deeper package power
states (PC9/10). Fix this for now by enabling DC6 only when we know the
above events (modeset, DPAUX) can't happen.

This a temporary solution as some issues are still unsolved as described
in [1] and [2], we'll address those as a follow-up.

[1]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077669.html
[2]
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077787.html

v1: Initial version.

v2: Based on review comment from Daniel,
- created a seperate patch for csr uninitialization set call.

v3: Rebased on top of latest code.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The BIOS can leave the CHV display PHY in some odd state where
some of the LDOs/lanes won't power down fully when unused. This
will trigger a host of asserts that were added in:
30142273 drm/i915: Add CHV PHY LDO power sanity checks
6669e39f drm/i915: Add some CHV DPIO lane power state asserts

To avoid that, skip the asserts until the PHY power well has been
disabled at least once. That will fully reset the PHY, and once
brought back up, the dynamic power down features will work correctly.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to the PCI docs and Rafael, we don't need to be doing explicit
enables and disables in our init and teardown routines, as they're taken
care of by the PCI core.  So drop the pm_runtime_disable() at teardown
and pm_runtime_set_active() at init.

This fixes one failure of the basic-pci-d3-state test on my BYT.

v2: drop extra get_noresume() and put_noidle() (Rafael)

Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: N"Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Another interesting criteria to work dmc as expected is pw1 to be
enabled by driver and dmc will shut it off in its execution
sequence. If already disabled by driver dmc will get confuse and
behave differently than expected found during pc10 entry issue
for skl.

So berfore we disable power-well 1, added check if dmc firmware is
present and driver will not disable power well 1, but for any reason
if firmware is not present of failed to load we can shut off the
power well 1 which will save some power.

As skl is currently fully dependent on dmc to go in lowest possible
power state (dc6) but the same is not applicable for bxt. Display
engine can enter into dc9 without dmc, hence unblocking disable call.

v1: Initial version.

v2: Rebased as per current patch series.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NVathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use WARN_ONCE in a bunch of places and demote a message that would
continually spam us.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

At various points when changing the DPIO lane/phy power states,
construct an expected value of the DISPLAY_PHY_STATUS register
and compare it with the real thing.

To construct the expected value we look at our shadow PHY_CONTROL
register value (which should match what we've just written to the
hardware), and we also need to look at the actual state of the cmn
power wells as a disabled power well causes the relevant LDO status
to be reported as 'on' in DISPLAY_PHY_STATUS.

When initially powering up the PHY it performs various internal
calibrations for which it fully powers up. That means that if we check
for the expetected power state immediately upon releasing cmnreset we
would get the occasional false positive. But we can of course
poll until the expected value appears. It shouldn't be too long so
this shouldn't make modesets substantially longer.

One extra complication is introduced when we cross the streams, ie.
drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
into life by temporaily powering up the lanes in the second channel,
and once the pipe is up and runnign we release the lane power override.
At that point the power state of CL2 has somehow gotten entangled with
the power state of the first channel. That means that constructing the
expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
lane power states in the second channel, CL2 should also be powered
down. But we can use the DPLL enable bit to determine when CL2 should
be alive even if the lanes are powered down. However the power state
of CL2 isn't actually tied in with the DPLL state, but to the state
of the lanes in first channel, so we have to avoid checking the
expected state between shutting down the DPLL and powering down
the lanes in the first channel. So no calling assert_chv_phy_status()
before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
but after the write is a safe time to check.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add some checks that the state of the DPIO lanes is more or less what we
expect based on the overrides.

The hardware only provides two bits per channel indicating whether all
or some of the lanes are powered down, so we can't do an exact check.

Additionally, CL2 powering down before we can check it adds another
twist. To work around this we simply check for the 0 value of the
CL2 register (which is what we get when it's powered down) and
adjust our expectations.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.

In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.

Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.

This patch also fix the DDI-E hotplug function.
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We can choose to leave the display PHY CL2 powerdown up to some hardware
signals, or we can force it. The BXT code forces the nonexistent CL2 in
the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
some extra power by disabling some extra logic in CL1, or something.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CHV has supports some form of automagic clock gating for the
DPIO SUS clock. We can simply enable the magic bits and the
hardware should take care of the rest.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

Ville's extended explanation from the review thread:

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

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

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

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

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

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

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

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

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

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

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

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

Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV,
and having VGA mode enabled causes some problems for CHV. So let's just
pull the code to configure those bits into the disp2d well enable hook.
With the DPLL disable code also fixed to leave those bits alone we
should now have a consistent DPLL state all the time even if the DPLL
is disabled.

This also neatly removes some duplicated code between the VLV and
CHV codepaths.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

dev_priv->chv_phy_control is protected by the power_domains->lock
elsewhere, so also grab it when initializing chv_phy_control.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similar to the ->enable vfunc in patch "drm/i915: Extract a
intel_power_well_enable() function".

v2 (from Paulo):
  - Same s/i915_/intel_/ bikeshed as the previous patch.
  - Update the commit hash.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need a bit book keeping around power wells' ops->enable(), namely a
nice debug message and updating hw_enabled. Let's introduce a
intel_power_well_enable() function to make sure all the callers do the
same things.

v2 (from Paulo):
  - s/i915_power_well_enable/intel_power_well_enable/ since everything
    else on this file uses intel_ instead of i915_.
  - Fix typo in commit message.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We do the exact same steps around the disp2d/pipe A power well
enable/disable on VLV and CHV. Refactor the shared code into
some helpers.

Note that this means we now call vlv_power_sequencer_reset() before
turning off the power well, whereas before we did it after. That
doesn't matter though since vlv_power_sequencer_reset() just resets
the power sequencer software tracking and doesn't touch the hardware
at all.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pipe A power well is the "disp2d" well on CHV and pipe B and C wells
don't even exist. Thereforce we can remove the checks for pipe A vs.
others and just assume it's always pipe A.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep things
as similar as possible between them.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Expecting CHV power wells to be just an extended versions of the VLV
power wells, a bunch of commented out power wells were added in
anticipation when Punit folks would implement it all. Turns out they
never did, and instead CHV has fewer power wells than VLV. Rip out all
the #if 0'ed junk that's not needed.

v2: Rename the "pipe-a" well to "display" to match VLV
    Clarify the pipe A power well relationship to pipes B and C (Deepak)
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Not sure which LDO programming sequence delay should be used for the CHV
PHY, but the spec says that 600ns is "Used by default for initial
bringup", and the BIOS seems to use that, so let's do the same.
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch fix spelling typo in intel_runtime_pm.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With recent hardware/firmware there don't appear to be any glitches
on the other PHY when we toggle the cmnreset for the other PHY. So
detangle the cmnlane power wells from one another and let them be
controlled independently.

This reverts commit 3dd7b974.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontaneosly during
modeset. When this happens during a modeset things go south and the
display doesn't light up.

I've managed to hit the problemn when toggling HDMI on port D on and
off. When things get corrupted the display doesn't light up, but as soon
as I manually write the correct value to the register the display comes
up.

First I was suspicious that we ourselves accidentally overwrite it with
garbage, but didn't catch anything with the reg_rw tracepoint. Also I
sprinkled check all over the modeset path to see exactly when the
corruption happens, and eg. the read back value was fine just before
intel_dp_set_m(), and corrupted immediately after it. I also made my
check function repair the register value whenever it was wrong, and with
this approach the corruption repeated several times during the modeset
operation, always seeming to trigger in the same exact calls to the
check function, while other calls to the function never caught anything.

So far I've not seen this problem occurring when carefully avoiding all
read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck
or an actual workaround, but we can hope it works. So let's avoid reading
the register and instead track the desired value of the register in dev_priv.

v2: Read out the power well state to determine initial register value
v3: Use DPIO_CHx names instead of raw numbers
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The specs tell us to ungate PG1 and Misc I/O at display init. We'll use
the PLLS power domain to ensure those two power wells are up.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Warn if the conditions to enter or exit DC6 are not satisfied such
as support for runtime PM, state of power well, CSR loading etc.

v2: Removed camelcase in functions and variables.

v3: Do some minimal check to assert if CSR program is not loaded.

v4:
1] Correct the check for backlight-disabling in assert_can_enable_dc6().
2] Check csr.loaded = false before disabling DC6 and simplify other checks.

v5:
1] Remove checks for DC5 state from assert_can_enable_dc6 function as DC5 is no
   longer enabled before enabling DC6.
2] Correct the check for CSR-loading in assert_can_disable_dc6 function as CSR must
   be loaded for context restore to happen on DC6 disabling.

v6:
1] It's okay to explicitly disable DC6 during driver-load/resume even though it might
   already be disabled and so don't warn about it.

v7: Rebase to latest.

v8: Sqashed the patch from Imre -
[PATCH] drm/i915/skl: avoid false CSR fw not loaded WARN during driver load/resume

v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)

v10: During initialization added a early return before disabling DC5. (Animesh)

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch just implements the basic enable and disable
functions of DC6 state which is needed for SKL platform.

Its important to load SKL CSR program before calling enable.

DC6 is a deeper power saving state where hardware dynamically
disables power well 0 and saves the associated registers.
DC6 can be entered when software allows it, the conditions
for DC5 are met, and the PCU allows DC6.
DC6 cannot be used if the backlight is being driven from the
display utility pin.

Its better to configure display engine to have power well 2
disabled before getting into DC6 enable function. Hence rpm
framework will ensure to check status of power well 2 and DC5
before calling skl_enable_dc6.

v2: Replace HAS_ with IS_ check as per Daniel's review comments

v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register
before setting them as per Satheesh's review comments.

v4: No need to call gen9_disable_dc5 inside enable sequence of
DC6, as its already take care above.

v5: call POSTING_READ for every write to a register to ensure that
its written immediately.
Call intel_prepare_ddi during DC6 exit as it's required on low-power exit.

v6: Protect DC6-enabling-disabling functionality with locks to synchronize
with CSR-loading code.

v7: Remove grabbing CSR-related mutex in skl_enable/disable_dc6 functions as
    deferred DC5-enabling functionality is now removed.

v8: Remove 'Disabling DC5' from the debug comment during DC6 enabling as when
    DC6 is allowed, DC5 is not programmed at all.

v9:
- Rebase to latest.
- Move all DC6-related functions from intel_display.c to intel_runtime_pm.c.

v10: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add triggers for DC6 as per details provided in skl_enable_dc6
and skl_disable_dc6 implementations.

Also Call POSTING_READ for every write to a register to ensure
it is written to immediately

v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in previous patches.

v2:
1] Remove check for backlight disabled as it should be the case by that time.
2] Mark DC5 as disabled when enabling DC6.
3] Return from DC5-disabling function early if DC5 is already be disabled which can happen
   due to DC6-enabling earlier.
3] Ensure CSR firmware is loaded after resume from DC6 as corresponding memory contents won't
   be retained after runtime-suspend.
4] Ensure that CSR isn't identified as loaded before CSR-loading program is called during
   runtime-resume.

v3: Rebase to latest
Modified as per review comments from Imre and after discussion with Art:
1] DC6 should be preferably enabled when PG2 is disabled by SW as the check for PG1 being
   disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled respectively.
   This helps save more power, especially in the case when display is disabled but GT is
   enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL.
2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is already enabled.
3] Move CSR-load-status setting code from intel_runtime_suspend function to a new function.

v4:
1] Enable/disable DC6 only when toggling the power-well using a newly defined macro ENABLE_DC6.

v5:
1] Load CSR on system resume too as firmware may be lost on system suspend preventing
   enabling DC5, DC6.
2] DDI buffers shouldn't be programmed during driver-load/resume as it's already done
   during modeset initialization then and also that the encoder list is still uninitialized by
   then. Therefore, call intel_prepare_ddi function right after disabling DC6 but outside
   skl_disable_dc6 function and not during driver-load/resume.

v6:
1] Rebase to latest.
2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to intel_runtime_pm.c.

v7:
1) Refactored the code for removing the warning got from checkpatch.
2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)

v8:
- Reverted the changes done in v7.
- Removed the condition check in skl_prepare_resune(). (Animesh)

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Warn if the conditions to enter or exit DC5 are not satisfied such
as support for runtime PM, state of power well, CSR loading etc.

v2: Removed camelcase in functions and variables.

v3: Do some minimal check to assert if CSR program is not loaded.

v4:
1] Used an appropriate function lookup_power_well() to identify power well,
instead of using a magic number which can change in future.
2] Split the conditions further in assert_can_enable_DC5() and added more checks.
3] Removed all WARNs from assert_can_disable_DC5 as they were unnecessary and added two
   new ones.
4] Changed variable names as updated in earlier patches.

v5:
1] Change lookup_power_well function to take an int power well id.
2] Define a new intel_display_power_well_is_enabled helper function to check whether a
   particular power well is enabled.
3] Use CSR-related mutex in assert_csr_loaded function.

v6: Remove use of dc5_enabled variable as it's no longer needed.

v7:
1] Rebase to latest.
2] Move all DC5-related functions from intel_display.c to intel_runtime_pm.c.

v8: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)

v9: Modified below changes based on review comments from Imre.
- Moved intel_display_power_well_is_enabled() to intel_runtime_pm.c.
- Removed mutex lock from assert_csr_loaded(). (Animesh)

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch just implements the basic enable and disable
functions of DC5 state which is needed for both SKL and BXT.

Its important to load respective CSR program before calling
enable, which anyways will happen as CSR program is executed
during boot.

DC5 is a power saving state where hardware dynamically disables
power well 1 and the CDCLK PLL and saves the associated registers.

DC5 can be entered when software allows it, power well 2 is
disabled, and hardware detects that all pipes are disabled
or pipe A is enabled with PSR active.

Its better to configure display engine to have power well 2 disabled before
getting into DC5 enable function. Hence rpm framework will have to
ensure to check status of power well 2 before calling gen9_enable_dc5.

Rather dc5 entry criteria should be decided based on power well 2 status.
If disabled, then call gen9_enable_dc5.

v2: Replace HAS_ with IS_ check as per Daniel's review comments

v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register
before setting them as per Satheesh's review comments.

v4: call POSTING_READ for every write to a register to ensure that
its written immediately.

v5: Modified as per review comments from Imre.
- Squashed register definitions into this patch.
- Finetuned comments and functions.

v6:
Avoid redundant writes in gen9_set_dc_state_debugmask_memory_up function.

v7:
- Rebase to latest.
- Move all runtime PM functions defined in intel_display.c to
  intel_runtime_pm.c.

v8: Rebased to drm-intel-nightly. (Animesh)

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add triggers as per expectations mentioned in gen9_enable_dc5
and gen9_disable_dc5 patch.

Also call POSTING_READ for every write to a register to ensure that
its written immediately.

v1: Remove POSTING_READ calls as they've already been added in previous patches.

v2: Rebase to move all runtime pm specific changes to intel_runtime_pm.c file.

Modified as per review comments from Imre:
1] Change variable name 'dc5_allowed' to 'dc5_enabled' to correspond to relevant
   functions.
2] Move the check dc5_enabled in skl_set_power_well() to disable DC5 into
   gen9_disable_DC5 which is a more appropriate place.
3] Convert checks for 'pm.dc5_enabled' and 'pm.suspended' in skl_set_power_well()
   to warnings. However, removing them for now as they'll be included in a future patch
   asserting DC-state entry/exit criteria.
4] Enable DC5, only when CSR firmware is verified to be loaded. Create new structure
   to track 'enabled' and 'deferred' status of DC5.
5] Ensure runtime PM reference is obtained, if CSR is not loaded, to avoid entering
   runtime-suspend and release it when it's loaded.
6] Protect necessary CSR-related code with locks.
7] Move CSR-loading call to runtime PM initialization, as power domains needed to be
   accessed during deferred DC5-enabling, are not initialized earlier.

v3: Rebase to latest.

Modified as per review comments from Imre:
1] Use blocking wait for CSR-loading to finish to enable DC5  for simplicity, instead of
   deferring enabling DC5 until CSR is loaded.
2] Obtain runtime PM reference during CSR-loading initialization itself as deferred DC5-
   enabling is removed and release it at the end of CSR-loading functionality.
3] Revert calling CSR-loading functionality to the beginning of i915 driver-load
   functionality to avoid any delay in loading.
4] Define another variable to track whether CSR-loading failed and use it to avoid enabling
   DC5 if it's true.
5] Define CSR-load-status accessor functions for use later.

v4:
1] Disable DC5 before enabling PG2 instead of after it.
2] DC5 was being mistaken enabled even when CSR-loading timed-out. Fix that.
3] Enable DC5-related functionality using a macro.
4] Remove dc5_enabled tracking variable and its use as it's not needed now.

v5:
1] Mark CSR failed to load where necessary in finish_csr_load function.
2] Use mutex-protected accessor function to check if CSR loaded instead of directly
   accessing the variable.
3] Prefix csr_load_status_get/set function names with intel_.

v6: rebase to latest.
v7: Rebase on top of nightly (Damien)
v8: Squashed the patch from Imre - added csr helper pointers to simplify the code. (Imre)
v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
v10: Added a enum for different csr states, suggested by Imre. (Animesh)

v11: Based on review comments from Imre, Damien and Daniel following changes done
- enum name chnaged to csr_state (singular form).
- FW_UNINITIALIZED used as zeroth element in enum csr_state.
- Prototype changed for helper function(set/get csr status), using enum csr_state instead of bool.

v12: Based on review comment from Imre, introduced bool fw_loaded local to finish_csr_load() which helps
calling once to set the csr status. The same flag used to fail RPM if find any issue during
firmware loading.

Issue: VIZ-2819
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NSuketu Shah <suketu.j.shah@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Modified as per review comments from Imre
- Mention enabling instead of allowing in the debug trace and
  remove unnecessary comments.

v3:
- Rebase to latest.
- Move DC9-related functions from intel_display.c to intel_runtime_pm.c.

v4: (imre)
- remove DC5 disabling, it's a nop at this point
- squashed in Suketu's "Assert the requirements to enter or exit DC9"
  patch
- remove check for RUNTIME_PM from assert_can_enable_dc9, it's not a
  dependency

Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> (v3)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add BXT power domains

v2: Use DOMAIN_PLLS instead of a new CDCLK one, whitespace fixes
    (Damien)
v3: add VGA, TRANSCODER_A power domains (imre)

Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
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>