Re: [DMC_BUGFIX_SKL_V2 0/5] pc10 entry fixes for skl.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



After discussions with Art, Ville and others internally on how DC5/6
should normally work and existing open issues related to the HW
automatic DC5/6 functionality, I have the following understanding.

In the future we will require the firmware for any display side runtime
power management (and possibly some power savings during system power
states like S0ix and S3), so in the following we can ignore the case
when the firmware is not available.

Normally we need to run the BSpec display init sequence only when
loading the driver and resuming from S4 if the BIOS hasn't done so
already. PW1 and CDCLK is enabled as part of this sequence and will be
toggled by the DMC firmware on demand, so we must not toggle these
manually during runtime, since that would race with the FW. The same
goes goes for other resources enabled/reset in the init sequence: PCH
reset handshake, DBUF, Misc IO. The manual controls are DC5, DC6 and PW2
which the driver needs to toggle based on the active outputs. We also
need to disable DC5/6 while doing modeset and according to our tests
DPAUX transfers.

When HW enters DC6 and the GT side is idle too (in RC6) the system as a
whole can enter a deeper power state (PC9/10).

Due to a HW issue atm we cannot rely on the HW transitioning
automatically to DC6 and we need to use a manual way instead. We do this
by keeping DC6 disabled all the time and running a special
deinitialization sequence when both the display and GT side is idle, and
the reverse when something becomes active. (that is in the driver's
runtime suspend/resume hooks).

Currently the driver is not following the normal HW assisted flow, since
it toggles DBUF, CDCLK and PW1 manually during runtime. It also lacks
the manual sequence to enable PC9/10.

This patchset solves some of the above issues, by removing the manual
CDCLK and PW1 control and disabling DC6. This will solve some of the
stability issues, but leave PC9/10 disabled. As a follow-up we need to
- move the rest of the display init/uninit sequence out of the
power_well/suspend/resume path and call it only during driver loading/S4
resume as necessary
- add separate DC5/DC6 power wells
- add the manual sequence to enable PC9/10
- add a module parameter to enable either HW assisted DC6, or the manual
way, or disable DC6
- disable DC5/6 during modeset and other places like DPAUX as needed

I'll comment on the individual patches based on the above. I think with
those addressed we could merge this patchset and do the rest as a
follow-up.

--Imre

On ke, 2015-08-26 at 01:36 +0530, Animesh Manna wrote:
> The following patches helps to solve PC10 entry issue for SKL.
> Detailed description about the changes done to solve the issue
> is mentioned in commit message of each patch.
> 
> v1: http://lists.freedesktop.org/archives/intel-gfx/2015-August/072870.html
> 
> v2: Based on review comments from Daniel, changes made in the current version.
> 
> DMC redesign patch series has dependencies with current patch series. Need
> to rework on few patches, planning to send after initial review feedback
> of the current patch series.
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/072921.html
>  
> 
> Animesh Manna (5):
>   drm/i915/skl: Added a check for the hardware status of csr fw before
>     loading.
>   drm/i915/skl Remove the call for csr uninitialization from suspend
>     path
>   drm/i915/skl: Making DC6 entry is the last call in suspend flow.
>   drm/i915/skl: Do not disable cdclk PLL if csr firmware is present
>   drm/i915/skl: Block disable call for pw1 if dmc firmware is present.
> 
>  drivers/gpu/drm/i915/i915_drv.c         | 19 +++++++++++++------
>  drivers/gpu/drm/i915/intel_csr.c        |  9 +++++++++
>  drivers/gpu/drm/i915/intel_display.c    | 14 ++++++++++----
>  drivers/gpu/drm/i915/intel_drv.h        |  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 31 ++++++++++++++++---------------
>  5 files changed, 50 insertions(+), 25 deletions(-)
> 


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux