Skip to content

L
linux
Switch branch/tag
  1. 06 Dec, 2012 10 commits
    • Daniel Vetter's avatar
      drm/i915: use gmbus irq to wait for gmbus idle · 2c438c02
      Daniel Vetter authored 
      GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use the wait_event_timeout helper directly without
jumping through hoops to catch NAKs.

Since gen2/3 don't have gmbus interrupts, handle them separately with
the old wait_for macro.

This shaves another few ms off reading EDID from a hdmi screen on my
testbox here. EDID reading with interrupt driven gmbus is now as fast
as with busy-looping gmbus at 28 ms here (with negligible cpu
overhead).
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2c438c02
    • Daniel Vetter's avatar
      drm/i915: use the gmbus irq for waits · 28c70f16
      Daniel Vetter authored 
      We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
  correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
  hand-roll the wait_event_timeout code so that we wake up every
  jiffie and can check for NAKs. This way we also subsume gmbus
  support for platforms without interrupts (or where those are not
  yet enabled).

The important bit really is to only enable one gmbus interrupt source
at the same time - with that piece of lore figured out, this seems to
work flawlessly.

Ben Widawsky rightfully complained the lack of measurements for the
claimed benefits (especially since the first version was actually
broken and fell back to bit-banging). Previously reading the 256 byte
hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
Given that transfering the 256 bytes over i2c at wire speed takes
20.5ms alone, the reduction in additional overhead is rather nice.

v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
when booting up an hence result in some spurious interrupts. Since we
clear GMBUS4 after every wait and we do gmbus transfer really early in
the setup sequence to detect displays the window is small, but still
be paranoid and clear it properly.

v3: Clarify the comment that gmbus irq generation can only support one
kind of event, why it bothers us and how we work around that limit.

Cc: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      28c70f16
    • Daniel Vetter's avatar
      drm/i915: wire up gmbus irq handler · 515ac2bb
      Daniel Vetter authored 
      Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.

Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as "Test mode").

v2: Wire up the irq handler for vlv and gen4 properly.

v3: i915_enable_pipestat expects the mask bit, not the status bits ... and
for added hilarity those are rather inconsistently named.
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      515ac2bb
    • Daniel Vetter's avatar
      drm/i915: extract gmbus_wait_hw_status · 61168c53
      Daniel Vetter authored 
      The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.

To prepare for this mess, start by extracting the hw status wait
loop into it's own function, consolidate the NAK error handling a
bit. To keep things flexible, pass in the status bit we care about
(in addition to any NAK signalling).

v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted,
Chris Wilson gladly pointed that out for me. To keep things simple,
ignore that case for  now (we only need to idle the gmbus controller
at the end of an entire i2c transaction, not after every message).
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      61168c53
    • Daniel Vetter's avatar
      drm/i915: reorder setup sequence to have irqs for output setup · 52d7eced
      Daniel Vetter authored 
      Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).

v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.

v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.

v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.

v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.

v6: Fixup cleanup sequence, too.
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      52d7eced
    • Daniel Vetter's avatar
      drm/i915: setup the hangcheck timer early · 61bac78e
      Daniel Vetter authored 
      ... together with all the other irq related resources in
intel_irq_init. I've managed to oops in the notify_ring function on my
ilk, presumably because of the powerctx setup call to i915_gpu_idle.

Note that this is only a problem with the reorder irq setup sequence
for irq-driver gmbus/dp aux.
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      61bac78e
    • Daniel Vetter's avatar
      drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv · d83779a9
      Daniel Vetter authored 
      This is for legacy legacy stuff, and checking with the leftover
pipe from the previous loop is propably not what we want. Since
pipe == 2 after the loop ... Then we only assing a variable and do
nothing with it.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d83779a9
    • Daniel Vetter's avatar
      drm/i915: haswell has the same irq handlers as ivb · 4a06e201
      Daniel Vetter authored 
      No need to have the exaxt same code twice.
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4a06e201
    • Mika Kuoppala's avatar
      drm/i915: Add intel_ring_handle_seqno wrap · 498d2ac1
      Mika Kuoppala authored 
      If there are pre-wrap values in semaphore-mbox registers after wrap,
syncing against some after-wrap request will complete immediately.
Fix this by emitting ring commands to set mbox registers to zero
when the wrap happens.

v2: Use __intel_ring_begin to emit ring commands, from
Chris Wilson.
Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a small comment to handle_seqno_wrap.]
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      498d2ac1
    • Mika Kuoppala's avatar
      drm/i915: Split intel_ring_begin · cbcc80df
      Mika Kuoppala authored 
      In preparation for handling ring seqno wrapping, split
intel_ring_begin into helper part which doesn't allocate
seqno.
Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cbcc80df
  3. 05 Dec, 2012 2 commits
  5. 03 Dec, 2012 4 commits
  7. 30 Nov, 2012 13 commits
  9. 29 Nov, 2012 11 commits
    • Luis R. Rodriguez's avatar
      i915: convert struct spinlock to spinlock_t · 99057c81
      Luis R. Rodriguez authored 
      spinlock_t should always be used.

  LD      drivers/gpu/drm/i915/built-in.o
  CHECK   drivers/gpu/drm/i915/i915_drv.c
  CC [M]  drivers/gpu/drm/i915/i915_drv.o
  CHECK   drivers/gpu/drm/i915/i915_dma.c
  CC [M]  drivers/gpu/drm/i915/i915_dma.o
  CHECK   drivers/gpu/drm/i915/i915_irq.c
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  CHECK   drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CHECK   drivers/gpu/drm/i915/i915_suspend.c
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CHECK   drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14:    expected unsigned int [unsigned] [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14:    got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
drivers/gpu/drm/i915/i915_gem.c:3706:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39:    expected restricted gfp_t [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39:    got unsigned int [unsigned] [usertype] mask
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CHECK   drivers/gpu/drm/i915/i915_gem_context.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
  CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
  CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CHECK   drivers/gpu/drm/i915/i915_sysfs.c
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CHECK   drivers/gpu/drm/i915/i915_trace_points.c
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CHECK   drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum transcoder  versus
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum pipe  versus
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_display.o
  CHECK   drivers/gpu/drm/i915/intel_crt.c
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CHECK   drivers/gpu/drm/i915/intel_lvds.c
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CHECK   drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60:    expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60:    got void [noderef] <asn:2>*vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42:    expected void const *<noident>
drivers/gpu/drm/i915/intel_bios.c:726:42:    got unsigned char [noderef] [usertype] <asn:2>*
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CHECK   drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum pipe  versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here
  CHECK   drivers/gpu/drm/i915/intel_dp.c
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
  CHECK   drivers/gpu/drm/i915/intel_hdmi.c
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
  CHECK   drivers/gpu/drm/i915/intel_sdvo.c
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CHECK   drivers/gpu/drm/i915/intel_modes.c
  CC [M]  drivers/gpu/drm/i915/intel_modes.o
  CHECK   drivers/gpu/drm/i915/intel_panel.c
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CHECK   drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/intel_pm.o
  CHECK   drivers/gpu/drm/i915/intel_i2c.c
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
  CHECK   drivers/gpu/drm/i915/intel_fb.c
  CC [M]  drivers/gpu/drm/i915/intel_fb.o
  CHECK   drivers/gpu/drm/i915/intel_tv.c
  CC [M]  drivers/gpu/drm/i915/intel_tv.o
  CHECK   drivers/gpu/drm/i915/intel_dvo.c
  CC [M]  drivers/gpu/drm/i915/intel_dvo.o
  CHECK   drivers/gpu/drm/i915/intel_ringbuffer.c
  CC [M]  drivers/gpu/drm/i915/intel_ringbuffer.o
  CHECK   drivers/gpu/drm/i915/intel_overlay.c
  CC [M]  drivers/gpu/drm/i915/intel_overlay.o
  CHECK   drivers/gpu/drm/i915/intel_sprite.c
  CC [M]  drivers/gpu/drm/i915/intel_sprite.o
  CHECK   drivers/gpu/drm/i915/intel_opregion.c
  CC [M]  drivers/gpu/drm/i915/intel_opregion.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7xxx.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7xxx.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7017.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7017.o
  CHECK   drivers/gpu/drm/i915/dvo_ivch.c
  CC [M]  drivers/gpu/drm/i915/dvo_ivch.o
  CHECK   drivers/gpu/drm/i915/dvo_tfp410.c
  CC [M]  drivers/gpu/drm/i915/dvo_tfp410.o
  CHECK   drivers/gpu/drm/i915/dvo_sil164.c
  CC [M]  drivers/gpu/drm/i915/dvo_sil164.o
  CHECK   drivers/gpu/drm/i915/dvo_ns2501.c
  CC [M]  drivers/gpu/drm/i915/dvo_ns2501.o
  CHECK   drivers/gpu/drm/i915/i915_gem_dmabuf.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_dmabuf.o
  CHECK   drivers/gpu/drm/i915/i915_ioc32.c
  CC [M]  drivers/gpu/drm/i915/i915_ioc32.o
  CHECK   drivers/gpu/drm/i915/intel_acpi.c
  CC [M]  drivers/gpu/drm/i915/intel_acpi.o
  LD [M]  drivers/gpu/drm/i915/i915.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      drivers/gpu/drm/i915/i915.mod.o
  LD [M]  drivers/gpu/drm/i915/i915.ko

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reported-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      99057c81
    • Paulo Zanoni's avatar
      drm/i915: kill intel_dp_link_clock() · 9fa5f652
      Paulo Zanoni authored 
      Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
supports DP_LINK_BW_5_4 and is also used by the other drivers.
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9fa5f652
    • Paulo Zanoni's avatar
      drm/i915: invert the log inside intel_prepare_ddi · 0d536cb4
      Paulo Zanoni authored 
      Do an early return in case we don't have DDI instead of having the
whole function inside an "if" statement.
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0d536cb4
    • Paulo Zanoni's avatar
      drm/i915: add HAS_DDI check · affa9354
      Paulo Zanoni authored 
      And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      affa9354
    • Paulo Zanoni's avatar
      drm/i915: remove Haswell code from ironlake_fdi_pll_enable · 20749730
      Paulo Zanoni authored 
      This function is not called on Haswell anymore.
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      20749730
    • Paulo Zanoni's avatar
      drm/i915: intel_prepare_ddi_buffers should be static · c1f63f9d
      Paulo Zanoni authored 
      It's not even declared on header files.
Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c1f63f9d
    • Daniel Vetter's avatar
      drm/i915: optimize the shmem_pwrite slowpath handling · 8dcf015e
      Daniel Vetter authored 
      Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).

But we only need to do this if we start in the cpu domain and the
object requires flushing for coherency. So don't do the flushing if
the object is coherent anyway or if we've done in-line clfushing
already.

v2: i915_gem_clflush_object already checks whether the object is
coherent and if so, drops the flushing. Hence we don't need to check
that ourselves, simplifying the condition.

v3: Reorder the checks for better clarity (and adjust the comment
accordingly), suggested by Chris Wilson.
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8dcf015e
    • Daniel Vetter's avatar
      drm/i915: simplify shmem pwrite/pread slowpath handling · a39a6805
      Daniel Vetter authored 
      The shmem paths for pwrite/pread used a clever trick to hold onto a
single page when dropping the big dev->struct_mutex for the slowpath.
But this ran the risk of reinstating (or not completely purging) the
backing storage when dropping purgeable objects.

Hence the code needed to keep track of whether it ever dropped the
lock, and if it did, manually check whether it needs to re-purge the
backing storage. But thanks to the pages pin count introduced in

commit a5570178
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:54 2012 +0100

    drm/i915: Pin backing pages whilst exporting through a dmabuf vmap

which allowed us to pin the backing storage and remove that page
reference trick from shmem_pwrite/read in

commit f60d7f0c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:56 2012 +0100

    drm/i915: Pin backing pages for pread

and

commit 755d2218
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:55 2012 +0100

    drm/i915: Pin backing pages for pwrite

we can now abolish this check. The slowpath cleanup completely
disappears from pread, and for pwrite we're only left with the domain
fixup in case someone moved the object out of the cpu domain from
under us. A follow-on patch will optimize that a notch more.
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a39a6805
    • Daniel Vetter's avatar
      drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too · 62810e5a
      Daniel Vetter authored 
      Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      62810e5a
    • Daniel Vetter's avatar
      drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable · fc683091
      Daniel Vetter authored 
      A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode

v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether
we shouldn't add an attached_panel pointer to intel_encoder, to
replace the encoder private ->attached_connector pointers, since
that's essentially what we need.
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fc683091
    • Daniel Vetter's avatar
      drm/i915: add intel_lvds->reg · 7dec0606
      Daniel Vetter authored 
      To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...

v2: Rebase on top of Jani Nikula's panel rework.
Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7dec0606
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7