1. 18 11月, 2015 1 次提交
  2. 12 11月, 2015 3 次提交
  3. 11 11月, 2015 1 次提交
    • V
      drm/i915: Kill intel_runtime_pm_disable() · 18a04a73
      Ville Syrjälä 提交于
      intel_runtime_pm_disable() takes an extra rpm reference which combined
      with the one we leak from intel_display_set_init_power() leaves the
      usage count at <original>+1 after the driver has been unloaded.
      The original ref is dropped explicitly in intel_runtime_pm_enable().
      So the next time we load the driver we can no longer do runtime PM ever.
      
      This used to work, but
      commit 292b990e ("drm/i915: Update power domains on readout.")
      broke things by not dropping the init power domain during fbdev
      teardown. Based on the comment in intel_power_domains_fini(), the
      way it used to to work wasn't intentional. As in we weren't supposed
      to drop the init power during driver unload. And since we no longer
      do, we now leak an extra rpm reference.
      
      So fix things by throwing intel_runtime_pm_disable() to the bin, so
      that the only leaked reference comes from the init power domain.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Fixes: 292b990e ("drm/i915: Update power domains on readout.")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      18a04a73
  4. 29 10月, 2015 1 次提交
    • R
      drm/i915/kbl: Introduce Kabylake platform defition. · ef11bdb3
      Rodrigo Vivi 提交于
      Kabylake is a Intel® Processor containing Intel® HD Graphics
      following Skylake.
      
      It is Gen9p5, so it inherits everything from Skylake.
      
      Let's start by adding the platform separated from Skylake
      but reusing most of all features, functions etc. Later we
      rebase the PCI-ID patch without is_skylake=1
      so we don't replace what original Author did there.
      
      Few IS_SKYLAKEs if statements are not being covered by this patch
      on purpose:
         - Workarounds: Kabylake is derivated from Skylake H0 so no
           		  W/As apply here.
         - GuC: A following patch removes Kabylake support with an
           	  explanation: No firmware available yet.
         - DMC/CSR: Done in a separated patch since we need to be carefull
           	      and load the version for revision 7 since
      	      Kabylake is Skylake H0.
      
      v2: relative cleaner commit message and added the missed
          IS_KABYLAKE to intel_i2c.c as pointed out by Jani.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ef11bdb3
  5. 19 10月, 2015 1 次提交
  6. 06 10月, 2015 1 次提交
  7. 30 9月, 2015 2 次提交
    • J
      drm/i915: fixup runtime PM handling v2 · 165ed87c
      Jesse Barnes 提交于
      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>
      165ed87c
    • A
      drm/i915/skl: Block disable call for pw1 if dmc firmware is present. · 08aef7ca
      Animesh Manna 提交于
      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>
      08aef7ca
  8. 14 9月, 2015 1 次提交
  9. 01 9月, 2015 2 次提交
    • V
      drm/i915: Add CHV PHY LDO power sanity checks · 30142273
      Ville Syrjälä 提交于
      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>
      30142273
    • V
      drm/i915: Add some CHV DPIO lane power state asserts · 6669e39f
      Ville Syrjälä 提交于
      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>
      6669e39f
  10. 31 8月, 2015 1 次提交
  11. 26 8月, 2015 6 次提交
    • V
      drm/i915: Force CL2 off in CHV x1 PHY · 3e288786
      Ville Syrjälä 提交于
      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>
      3e288786
    • V
      drm/i915: Enable DPIO SUS clock gating on CHV · ee279218
      Ville Syrjälä 提交于
      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>
      ee279218
    • V
      drm/i915: Trick CL2 into life on CHV when using pipe B with port B · b0b33846
      Ville Syrjälä 提交于
      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>
      b0b33846
    • V
      drm/i915: Implement PHY lane power gating for CHV · e0fce78f
      Ville Syrjälä 提交于
      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>
      e0fce78f
    • V
      drm/i915: Move DPLL ref/cri/VGA mode frobbing to the disp2d well enable · 5a8fbb7d
      Ville Syrjälä 提交于
      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>
      5a8fbb7d
    • V
      drm/i915: Add locking around chv_phy_control_init() · 770effb1
      Ville Syrjälä 提交于
      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>
      770effb1
  12. 05 8月, 2015 2 次提交
  13. 13 7月, 2015 4 次提交
  14. 28 5月, 2015 2 次提交
  15. 20 5月, 2015 1 次提交
  16. 08 5月, 2015 10 次提交
    • V
      Revert "drm/i915: Hack to tie both common lanes together on chv" · 71849b67
      Ville Syrjälä 提交于
      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>
      71849b67
    • V
      drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV · 70722468
      Ville Syrjälä 提交于
      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>
      70722468
    • D
      drm/i915/skl: Make the Misc I/O power well part of the PLLS domain · 6222709d
      Damien Lespiau 提交于
      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>
      6222709d
    • D
    • S
      drm/i915/skl: Assert the requirements to enter or exit DC6. · 93c7cb6c
      Suketu Shah 提交于
      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>
      93c7cb6c
    • A
      Implement enable/disable for Display C6 state · 74b4f371
      A.Sunil Kamath 提交于
      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>
      74b4f371
    • S
      drm/i915/skl: Add DC6 Trigger sequence. · f75a1985
      Suketu Shah 提交于
      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>
      f75a1985
    • S
      drm/i915/skl: Assert the requirements to enter or exit DC5. · 5aefb239
      Suketu Shah 提交于
      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>
      5aefb239
    • A
      drm/i915/skl: Implement enable/disable for Display C5 state. · 6b457d31
      A.Sunil Kamath 提交于
      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>
      6b457d31
    • S
      drm/i915/skl: Add DC5 Trigger Sequence · dc174300
      Suketu Shah 提交于
      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>
      dc174300
  17. 16 4月, 2015 1 次提交