Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 11月, 2020 1 次提交
  3. 21 10月, 2020 1 次提交
    • V
      drm/i915: Reorder hpd init vs. display resume · 4c8d4651
      由 Ville Syrjälä 提交于 
      Currently we call .hpd_irq_setup() directly just before display
resume, and follow it with another call via intel_hpd_init()
just afterwards. Assuming the hpd pins are marked as enabled
during the open-coded call these two things do exactly the
same thing (ie. enable HPD interrupts). Which even makes sense
since we definitely need working HPD interrupts for MST sideband
during the display resume.

So let's nuke the open-coded call and move the intel_hpd_init()
call earlier. However we need to leave the poll_init_work stuff
behind after the display resume as that will trigger display
detection while we're resuming. We don't want that trampling over
the display resume process. To make this a bit more symmetric
we turn this into a intel_hpd_poll_{enable,disable}() pair.
So we end up with the following transformation:
intel_hpd_poll_init() -> intel_hpd_poll_enable()
lone intel_hpd_init() -> intel_hpd_init()+intel_hpd_poll_disable()
.hpd_irq_setup()+resume+intel_hpd_init() -> intel_hpd_init()+resume+intel_hpd_poll_disable()

If we really would like to prevent all *long* HPD processing during
display resume we'd need some kind of software mechanism to simply
ignore all long HPDs. Currently we appear to have that just for
fbdev via ifbdev->hpd_suspended. Since we aren't exploding left and
right all the time I guess that's mostly sufficient.

For a bit of history on this, we first got a mechanism to block
hotplug processing during suspend in commit 15239099 ("drm/i915:
enable irqs earlier when resuming") on account of moving the irq enable
earlier. This then got removed in commit 50c3dc97 ("drm/fb-helper:
Fix hpd vs. initial config races") because the fdev initial config
got pushed to a later point. The second ad-hoc hpd_irq_setup() for
resume was added in commit 0e32b39c ("drm/i915: add DP 1.2 MST
support (v0.7)") to be able to do MST sideband during the resume.
And finally we got a partial resurrection of the hpd blocking
mechanism in commit e8a8fedd ("drm/i915: Block fbdev HPD
processing during suspend"), but this time it only prevent fbdev
from handling hpd while resuming.

v2: Leave the poll_init_work behind
v3: Remove the extra intel_hpd_poll_disable() from display reset (Lyude)
    Add the missing intel_hpd_poll_disable() to display init (Imre)

Cc: Lyude Paul <lyude@redhat.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201013181137.30560-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
      4c8d4651
  5. 20 10月, 2020 1 次提交
  7. 16 10月, 2020 5 次提交
  9. 29 8月, 2020 1 次提交
    • J
      drm/i915/tgl: Fix stepping WA matching · c33298cb
      由 José Roberto de Souza 提交于 
      TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit 96c5a15f
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP stepping
mapping between SKUs and the same stepping revision of GT do not match
the same HW between TGL U/Y and regular TGL.

So it was required to have 2 different macros to check GT WAs while
for Display we are able to use just one macro that uses the right
revids table.

All TGL workarounds checked and updated accordingly.

v2:
- removed TODO to check if WA 14010919138 applies to regular TGL.
- fixed display stepping in regular TGL (Anusha)

BSpec: 52890
BSpec: 55378
BSpec: 44455
Reviewed-by: NAnusha Srivatsa <anusha.srivtsa@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Penne Lee <penne.y.lee@intel.com>
Cc: Guangyao Bai <guangyao.bai@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200827233943.400946-1-jose.souza@intel.com
      c33298cb
  11. 19 8月, 2020 2 次提交
  13. 18 8月, 2020 4 次提交
  15. 03 7月, 2020 1 次提交
  17. 27 6月, 2020 1 次提交
  19. 23 6月, 2020 1 次提交
    • J
      drm/i915/params: switch to device specific parameters · 8a25c4be
      由 Jani Nikula 提交于 
      Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.

The stragglers are:

* i915.force_probe and i915.modeset. Needed before dev_priv is
  available. This is fine because the parameters are read-only and never
  modified.

* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
  I915_STATE_WARN_ON would result in massive and ugly churn. This is
  handled by not exposing the parameter via debugfs, and leaving the
  parameter writable in sysfs. This may be fixed up in follow-up work.

* i915.inject_probe_failure. Only makes sense in terms of the module,
  not the device. This is handled by not exposing the parameter via
  debugfs.

v2: Fix uc i915 lookup code (Michał Winiarski)

Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
      8a25c4be
  21. 10 6月, 2020 1 次提交
    • M
      drm/i915/rkl: RKL uses ABOX0 for pixel transfers · 62afef28
      由 Matt Roper 提交于 
      Rocket Lake uses the same 'abox0' mechanism to handle pixel data
transfers from memory that gen11 platforms used, rather than the
abox1/abox2 interfaces used by TGL/DG1.  For the most part this is a
hardware implementation detail that's transparent to driver software,
but we do have to program a couple of tuning registers (MBUS_ABOX_CTL
and BW_BUDDY registers) according to which ABOX instances are used by a
platform.  Let's track the platform's ABOX usage in the device info
structure and use that to determine which instances of these registers
to program.

As an exception to this rule is that even though TGL/DG1 use ABOX1+ABOX2
for data transfers, we're still directed to program the ABOX_CTL
register for ABOX0; so we'll handle that as a special case.

v2:
 - Store the mask of platform-specific abox registers in the device
   info structure.
 - Add a TLB_REQ_TIMER() helper macro.  (Aditya)

v3:
 - Squash ABOX and BW_BUDDY patches together and use a single mask for
   both of them, plus a special-case for programming the ABOX0 instance
   on all gen12.  (Ville)

Bspec: 50096
Bspec: 49218
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200606025740.3308880-2-matthew.d.roper@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      62afef28
  23. 20 5月, 2020 1 次提交
  25. 19 5月, 2020 1 次提交
  27. 16 5月, 2020 3 次提交
  29. 23 4月, 2020 1 次提交
  31. 21 4月, 2020 3 次提交
  33. 18 4月, 2020 7 次提交
  35. 17 4月, 2020 2 次提交
  37. 16 4月, 2020 1 次提交
  39. 26 3月, 2020 1 次提交
    • J
      drm/i915/display_power: use struct drm_device based logging · 3c4e3870
      由 Jani Nikula 提交于 
      Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.

No functional changes.

Generated using the following semantic patch, originally written by
Wambui Karuga <wambui.karugax@gmail.com>, with manual fixups on top:

@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_NOTE(
+drm_notice(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_NOTE(
+drm_notice(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

Cc: Wambui Karuga <wambui.karugax@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/25e56d1b7df3b1e91024eb969fb839fdcbdcb35e.1584714939.git.jani.nikula@intel.com
      3c4e3870
  41. 02 3月, 2020 1 次提交