Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 6月, 2016 2 次提交
    • I
      drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code · 9c8d0b8e
      由 Imre Deak 提交于 
      So far we depended on the HW to dynamically power down unused PHYs and
so we enabled them manually once during driver loading/resuming. There
are indications however that we can achieve better power savings by
manual powering toggling. So make the PHY enabling/disabling to happen
on-demand whenever we need either the corresponding AUX or port
functionality. CHV does this already by enabling the PHY along the
corresponding PHY common lane power wells there, do the same on BXT by
adding virtual power wells for the same purpose.

Also sanity check the common lane power down ack signal from the PHY. Do
this only when the PHY is enabled, since it's not clear at what point
the HW power/clock gates things.

While at it rename broxton_ prefix to bxt_ in related function names to
better align with the SKL code.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      9c8d0b8e
    • I
      drm/i915/bxt: Wait for PHY1 GRC calibration synchronously · e4c49e0f
      由 Imre Deak 提交于 
      A follow-up patch moves the PHY enabling to the power well code where
enabling/disabling the PHYs will happen independently. Because of this
waiting for the GRC calibration in PHY1 asynchronously would need some
additional logic. Instead of adding that let's keep things simple for now
and wait synchronously. My measurements showed that the calibration
takes ~4ms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      e4c49e0f
  3. 30 5月, 2016 1 次提交
  5. 23 5月, 2016 2 次提交
  7. 13 5月, 2016 1 次提交
  9. 09 5月, 2016 1 次提交
  11. 04 5月, 2016 2 次提交
  13. 29 4月, 2016 1 次提交
  15. 27 4月, 2016 2 次提交
  17. 22 4月, 2016 3 次提交
  19. 21 4月, 2016 1 次提交
  21. 19 4月, 2016 1 次提交
    • I
      drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume · bf93ba67
      由 Imre Deak 提交于 
      The driver's VDD on/off logic assumes that whenever the VDD is on we
also hold an AUX power domain reference. Since BIOS can leave the VDD on
during booting and resuming and on DDI platforms we won't take a
corresponding power reference, the above assumption won't hold on those
platforms and an eventual delayed VDD off work will do an extraneous AUX
power domain put resulting in a refcount underflow. Fix this the same
way we did this for non-DDI DP encoders:

commit 6d93c0c4 ("drm/i915: fix VDD state tracking after system
resume")

At the same time call the DP encoder suspend handler the same way as the
non-DDI DP encoders do to flush any pending VDD off work. Leaving the
work running may cause a HW access where we don't expect this (at a point
where power domains are suspended already).

While at it remove an unnecessary function call indirection.

This fixed for me AUX refcount underflow problems on BXT during
suspend/resume.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
      bf93ba67
  23. 15 4月, 2016 5 次提交
  25. 04 4月, 2016 1 次提交
  27. 02 4月, 2016 1 次提交
    • V
      drm/i915: Disable FDI RX before DDI_BUF_CTL · 5b421c57
      由 Ville Syrjälä 提交于 
      Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
FDI RX disable both as step 13 and step 18 in the sequence. But I dug
up an old BUN mail from Art that moved the FDI RX disable to happen
before DDI_BUF_CTL disable. That BUN did not renumber the steps and just
added a note:
"Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."

The BUN described the symptoms of the fixed issue as:
"PCH display underflow and a black screen on the analog CRT port that
happened after a FDI re-train"

I suppose later someone tried to renumber the steps to match, but forgot
to remove the FDI RX disable from its old position in the sequence.

They also forgot to update the note describing what should be done in
case of an FDI training failure. Currently it says:
"To retry FDI training, follow the Disable Sequence steps to Disable FDI,
but skip the steps related to clocks and PLLs (16, 19, and 20), ..."

It should really say "17, 20, and 21" with the current sequence because
those are the steps that deal with PLLs and whatnot, after step 13 became
FDI RX disable. And had the step 18 FDI RX disable been removed, as I
suspect it should have, the note should actually say "17, 19, and 20".

So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable,
as that would appear to be the correct order based on the BUN.

Note that Art has since unconfused the spec, and so this patch should
now match the steps listed in the spec.

v2: Add a note that the spec is now correct

Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456841783-4779-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      5b421c57
  29. 01 4月, 2016 2 次提交
  31. 29 3月, 2016 2 次提交
  33. 21 3月, 2016 1 次提交
  35. 09 3月, 2016 7 次提交
  37. 08 3月, 2016 1 次提交
  39. 07 3月, 2016 1 次提交
  41. 22 2月, 2016 1 次提交
  43. 17 2月, 2016 1 次提交