Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 3月, 2013 5 次提交
    • D
      Revert "drm/i915: write backlight harder" · b1289371
      由 Daniel Vetter 提交于 
      This reverts commit cf0a6584.

Turns out that cargo-culting breaks systems. Note that we can't revert
further, since

commit 770c1231
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Aug 11 08:56:42 2012 +0200

    drm/i915: Fix blank panel at reopening lid

fixed a regression in 3.6-rc kernels for which we've never figured out
the exact root cause. But some further inspection of the backlight
code reveals that it's seriously lacking locking. And especially the
asle backlight update is know to get fired (through some smm magic)
when writing specific backlight control registers. So the possibility
of suffering from races is rather real.

Until those races are fixed I don't think it makes sense to try
further hacks. Which sucks a bit, but sometimes that's how it is :(

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941Tested-by: NTakashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b1289371
    • P
      drm/i915: don't disable the power well yet · 2124b72e
      由 Paulo Zanoni 提交于 
      We're still not 100% ready to disable the power well, so don't disable
it for now. When we disable it we break the audio driver (because some
of the audio registers are on the power well) and machines with eDP on
port D (because it doesn't use TRANSCODER_EDP).

Also, instead of just reverting the code, add a Kernel option to let
us disable it if we want. This will allow us to keep developing and
testing the feature while it's not enabled.

This fixes problems caused by the following commit:
  commit d6dd9eb1
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Tue Jan 29 16:35:20 2013 -0200
       drm/i915: dynamic Haswell display power well support

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Mengdong Lin <mengdong.lin@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2124b72e
    • D
      Revert "drm/i915: set TRANSCODER_EDP even earlier" · bba2181c
      由 Daniel Vetter 提交于 
      This reverts commit cc464b2a.

The reason is that Takashi Iwai reported a regression bisected to this
commit:

http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html

His machine has eDP on port D (usual desktop all-in-on setup), which
intel_dp.c identifies as an eDP panel, but the hsw ddi code
mishandles.

Closer inspection of the code reveals that haswell_crtc_mode_set also
checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
that doesn't make much sense (since there's no edp on the pch), but
what this function _really_ checks is whether that edp connector is on
port A or port D. It's just that on ilk-ivb port D was on the pch ...

So that explains why this seemingly innocent change killed eDP on port
D. Furthermore it looks like everything else accidentally works, since
we've never enabled eDP on port D support for hsw intentionally (e.g.
we still register the HDMI output for port D in that case).

But in retrospective I also don't like that this leaks highly platform
specific details into common code, and the reason is that the drm
vblank layer sucks. So instead I think we should:
- move the cpu_transcoder into the dynamic pipe_config tracking (once
  that's merged).
- fix up the drm vblank layer to finally deal with kms crtc objects
  instead of int pipes.

v2: Pimp commit message with the better diagnosis as discussed with
Paulo on irc.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bba2181c
    • T
      KMS: fix EDID detailed timing frame rate · c19b3b0f
      由 Torsten Duwe 提交于 
      When KMS has parsed an EDID "detailed timing", it leaves the frame rate
zeroed.  Consecutive (debug-) output of that mode thus yields 0 for
vsync.  This simple fix also speeds up future invocations of
drm_mode_vrefresh().

While it is debatable whether this qualifies as a -stable fix I'd apply
it for consistency's sake; drm_helper_probe_single_connector_modes()
does the same thing already for all probed modes.

Cc: stable@vger.kernel.org
Signed-off-by: NTorsten Duwe <duwe@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c19b3b0f
    • T
      KMS: fix EDID detailed timing vsync parsing · 16dad1d7
      由 Torsten Duwe 提交于 
      EDID spreads some values across multiple bytes; bit-fiddling is needed
to retrieve these.  The current code to parse "detailed timings" has a
cut&paste error that results in a vsync offset of at most 15 lines
instead of 63.

See

   http://en.wikipedia.org/wiki/EDID

and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why
that needs to be a left shift.

Cc: stable@vger.kernel.org
Signed-off-by: NTorsten Duwe <duwe@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      16dad1d7
  3. 21 3月, 2013 1 次提交
    • J
      drm/mgag200: Bug fix: Modified pll algorithm for EH project · 260b3f12
      由 Julia Lemire 提交于 
      While testing the mgag200 kms driver on the HP ProLiant Gen8, a
bug was seen.  Once the bootloader would load the selected kernel,
the screen would go black.  At first it was assumed that the
mgag200 kms driver was hanging.  But after setting up the grub
serial output, it was seen that the driver was being loaded
properly.  After trying serval monitors, one finaly displayed
the message "Frequency Out of Range".  By comparing the kms pll
algorithm with the previous mgag200 xorg driver pll algorithm,
discrepencies were found.  Once the kms pll algorithm was
modified, the expected pll values were produced.  This fix was
tested on several monitors of varying native resolutions.
Signed-off-by: NJulia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      260b3f12
  5. 20 3月, 2013 1 次提交
    • J
      drm/i915: stop using GMBUS IRQs on Gen4 chips · c12aba5a
      由 Jiri Kosina 提交于 
      Commit 28c70f16 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.

It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.

Typically this results in the spurious interrupt source getting
disabled:

[    9.636345] irq 16: nobody cared (try booting with the "irqpoll" option)
[    9.637915] Pid: 4157, comm: ifup Tainted: GF            3.9.0-rc2-00341-g08637024 #422
[    9.639484] Call Trace:
[    9.640731]  <IRQ>  [<ffffffff8109b40d>] __report_bad_irq+0x1d/0xc7
[    9.640731]  [<ffffffff8109b7db>] note_interrupt+0x15b/0x1e8
[    9.640731]  [<ffffffff810999f7>] handle_irq_event_percpu+0x1bf/0x214
[    9.640731]  [<ffffffff81099a88>] handle_irq_event+0x3c/0x5c
[    9.640731]  [<ffffffff8109c139>] handle_fasteoi_irq+0x7a/0xb0
[    9.640731]  [<ffffffff8100400e>] handle_irq+0x1a/0x24
[    9.640731]  [<ffffffff81003d17>] do_IRQ+0x48/0xaf
[    9.640731]  [<ffffffff8142f1ea>] common_interrupt+0x6a/0x6a
[    9.640731]  <EOI>  [<ffffffff8142f952>] ? system_call_fastpath+0x16/0x1b
[    9.640731] handlers:
[    9.640731] [<ffffffffa000d771>] usb_hcd_irq [usbcore]
[    9.640731] [<ffffffffa0306189>] yenta_interrupt [yenta_socket]
[    9.640731] Disabling IRQ #16

The really curious thing is now that irq 16 is _not_ the interrupt for
the i915 driver when using MSI, but it _is_ the interrupt when not
using MSI. So by all indications it seems like gmbus is able to
generate a legacy (shared) interrupt in MSI mode on some
configurations. I've tried to reproduce this and the differentiating
thing seems to be that on unaffected systems no other device uses irq
16 (which seems to be the non-MSI intel gfx interrupt on all gm45).

I have no idea how that even can happen.

To avoid tempting this elephant into a rage, just disable gmbus
interrupt support on gen 4.

v2: Improve the commit message with exact details of what's going on.
Also add a comment in the code to warn against this particular
elephant in the room.

v3: Move the comment explaing how gen4 blows up next to the definition
of HAS_GMBUS_IRQ to keep the code-flow straight. Suggested by Chris
Wilson.

Signed-off-by: Jiri Kosina <jkosina@suse.cz> (v1)
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
References: https://lkml.org/lkml/2013/3/8/325Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c12aba5a
  7. 19 3月, 2013 2 次提交
  9. 18 3月, 2013 13 次提交
  11. 16 3月, 2013 5 次提交
  13. 14 3月, 2013 2 次提交
  15. 11 3月, 2013 4 次提交
  17. 08 3月, 2013 7 次提交