Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 11月, 2015 10 次提交
  3. 12 11月, 2015 3 次提交
  5. 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
  7. 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
  9. 19 10月, 2015 1 次提交
  11. 06 10月, 2015 1 次提交
  13. 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
  15. 14 9月, 2015 1 次提交
  17. 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
  19. 31 8月, 2015 1 次提交
  21. 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
  23. 05 8月, 2015 2 次提交
  25. 13 7月, 2015 4 次提交
  27. 28 5月, 2015 2 次提交
  29. 20 5月, 2015 1 次提交
  31. 08 5月, 2015 2 次提交
    • 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