1. 06 Dec, 2012 9 commits
    • 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
  2. 05 Dec, 2012 2 commits
  3. 03 Dec, 2012 4 commits
  4. 30 Nov, 2012 13 commits
  5. 29 Nov, 2012 12 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
    • Daniel Vetter's avatar
      drm/i915: track is_dual_link in intel_lvds · 13c7d870
      Daniel Vetter authored
      Yeah, all users (both the clock selection special cases and the lvds
      pin pair stuff) are still in common code, but this will change.
      
      v2: Rebase on top of Jani Nikula's panel rework.
      
      v3: Incorporate review from Paulo Zanoni:
      - s/__is_dual_link_lvds/compute_is_dual_link_lvds
      - kill dev_priv->lvds_val
      - drop spurious whitespace change
      
      v4: Add a debug printk to display the dual-link status, as suggested
      by Paulo Zanoni in review.
      
      Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v3)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      13c7d870