Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 8月, 2012 1 次提交
    • C
      i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard · a51d4ed0
      由 Calvin Walton 提交于 
      This board is incorrectly detected as having an LVDS connector,
resulting in the VGA output (the only available output on the board)
showing the console only in the top-left 1024x768 pixels, and an extra
LVDS connector appearing in X.

It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10
chipset.

I've had this board for about a year, but this is the first time I
noticed the issue because I've been running it headless for most of its
life.
Signed-off-by: NCalvin Walton <calvin.walton@kepstin.ca>
      a51d4ed0
  3. 25 7月, 2012 1 次提交
    • D
      drm/i915/lvds: ditch ->prepare special case · 520c41cf
      由 Daniel Vetter 提交于 
      LVDS is the first output where dpms on/off and prepare/commit don't
perfectly match. Now the idea behind this special case seems to be
that for simple resolution changes on the LVDS we don't need to stop
the pipe, because (at least on newer chips) we can adjust the panel
fitter on the fly.

There are a few problems with the current code though:
- We still stop and restart the pipe unconditionally, because the crtc
  helper code isn't flexible enough.
- We show some ugly flickering, especially when changing crtcs (this
  the crtc helper would actually take into account, but we don't
  implement the encoder->get_crtc callback required to make this work
  properly).

So it doesn't even work as advertised. I agree that it would be nice
to do resolution changes on LVDS (and also eDP) whithout blacking the
screen where the panel fitter allows to do that. But imo we should
implement this as a special case a few layers up in the mode set code,
akin to how we already detect simple framebuffer changes (and only
update the required registers with ->mode_set_base).

Until this is all in place, make our lives easier and just rip it out.

Also note that this seems to fix actual bugs with enabling the lvds
output, see:

http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Giacomo Comes <comes@naic.edu>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NTakashi Iwai <tiwai@suse.de>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      520c41cf
  5. 20 7月, 2012 1 次提交
  7. 05 7月, 2012 1 次提交
  9. 22 6月, 2012 1 次提交
  11. 13 6月, 2012 3 次提交
    • D
      drm/i915: allow pipe A for lvds on gen4 · 0b9f43a0
      由 Daniel Vetter 提交于 
      Given the havoc the missing backlight pipe select code might have
caused, let's try to re-enabled pipe A support for lvds on gen4 hw.
Just to see what all blows up ...

Note though that

commit 4add75c4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Dec 4 17:49:46 2010 +0000

    drm/i915: Allow LVDS to be on pipe A for Ironlake+

claims that this caused tons of spurious wakeups somehow.

More details can be found in the old revert:

commit 12e8ba25
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 7 23:39:28 2010 +0100

    Revert "drm/i915: Allow LVDS on pipe A on gen4+"

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0b9f43a0
    • D
      drm/i915: properly enable the blc controller on the right pipe · 24ded204
      由 Daniel Vetter 提交于 
      On gen4+ we have a bitfield to specify from which pipe the backlight
controller should take it's clock. For PCH split platforms we've
already set these up, but only at initialization time. And without
taking into account the 3rd pipe added with ivb.

For gen4, we've completely ignored these. Although we do restrict lvds
to the 2nd pipe, so this is only a problem on machines where we boot
up with the lvds on the first pipe.

So restructure the code to enable the backlight on the right pipe at
modeset time.

v2: For odd reasons panel_enable_backlight gets called twice in a
modeset, so we can't WARN_ON in there if the backlight controller is
switched on already.

v3: backlight enable can also be called through dpms on, so the check
in there is legit. Update the comment to reflect that.
Tested-By: NKamal Mostafa <kamal@canonical.com>
Bugzilla: https://bugs.launchpad.net/bugs/954661
Cc: Carsten Emde <C.Emde@osadl.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      24ded204
    • D
      drm/i915: clear up backlight #define confusion on gen4+ · 7cf41601
      由 Daniel Vetter 提交于 
      - Regroup definitions for BLC_PWM_CTL so that they're all together and
  and ordered according to the bitfields.

- Add all missing definitions for BLC_PWM_CTL2.

- Use the BLM_ (for backlight modulation) prefix consistently.

- Note that combination mode (i.e. also taking the legacy backlight
  control value from pci config space into account) is gen4 only.

- Move the new registers for PCH-split machines up, they're an almost
  match for the gen4 defitions.  Prefix the special PCH-only bits with
  BLM_PCH_. Also add the pipe C select bit for ivb.

- Rip out the second pair of PCH polarity definitions - they're only
  valid on early (pre-production) ilk silicon.

- Adapt the existing code to use the new definitions. This has the
  nice benefit of killing a magic (1 << 30) left behind be Jesse
  Barnes.

No functional changes in this patch.
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7cf41601
  13. 24 5月, 2012 1 次提交
  15. 03 5月, 2012 1 次提交
  17. 16 4月, 2012 1 次提交
  19. 10 4月, 2012 1 次提交
  21. 03 4月, 2012 1 次提交
  23. 28 3月, 2012 1 次提交
    • D
      drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter · 3bd7d909
      由 Daniel Kurtz 提交于 
      Instead of letting other modules directly access the ->gmbus array,
introduce intel_gmbus_get_adapter() for looking up an i2c_adapter
for a given gmbus port identifier.  This will enable later refactoring
of the gmbus port list.

Note: Before requesting an adapter for a given gmbus port number, the
driver must first check its validity using i2c_intel_gmbus_is_port_valid().
If this check fails, a call to intel_gmbus_get_adapter() will WARN_ON and
return NULL.  This is relevant for parts of the driver that read a port
from VBIOS, which might be improperly initialized and contain an invalid
port.  In these cases, the driver must fall back to using a safer default
port.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3bd7d909
  25. 27 2月, 2012 1 次提交
  27. 15 2月, 2012 1 次提交
  29. 09 2月, 2012 1 次提交
  31. 13 1月, 2012 1 次提交
  33. 17 12月, 2011 1 次提交
  35. 21 10月, 2011 1 次提交
  37. 16 8月, 2011 1 次提交
  39. 09 8月, 2011 2 次提交
  41. 30 7月, 2011 1 次提交
  43. 05 6月, 2011 1 次提交
  45. 10 5月, 2011 1 次提交
  47. 06 4月, 2011 1 次提交
  49. 25 3月, 2011 1 次提交
  51. 16 2月, 2011 1 次提交
  53. 08 2月, 2011 1 次提交
  55. 06 2月, 2011 1 次提交
  57. 19 1月, 2011 2 次提交
  59. 15 1月, 2011 1 次提交
  61. 12 1月, 2011 2 次提交
  63. 06 12月, 2010 1 次提交
  65. 05 12月, 2010 2 次提交
  67. 01 12月, 2010 1 次提交