1. 06 Dec, 2012 13 commits
    • Daniel Vetter's avatar
      drm/i915: use _NOTRACE for gmbus/dp aux wait loops · ef04f00d
      Daniel Vetter authored
      Less clutter in the traces. And in both cases we yell rather loud
      into the logs if we time out. Patch suggested by Chris Wilson.
      
      v2: Annotate another I915_READ in dp_aux to be consistent - we filter
      out all register io in wait_for and similar loops. Chris also
      suggested to mark all dp_aux register access as _NOTRACE, but I think
      we should keep all functionally relevant access around, and filter
      unneeded bits in userspace after the trace is captured.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ef04f00d
    • Daniel Vetter's avatar
      drm/i915: irq-drive the dp aux communication · 9ee32fea
      Daniel Vetter authored
      At least on the platforms that have a dp aux irq and also have it
      enabled - vlvhsw should have one, too. But I don't have a machine to
      test this on. Judging from docs there's no dp aux interrupt for gm45.
      
      Also, I only have an ivb cpu edp machine, so the dp aux A code for
      snb/ilk is untested.
      
      For dpcd probing when nothing is connected it slashes about 5ms of cpu
      time (cpu time is now negligible), which agrees with 3 * 5 400 usec
      timeouts.
      
      A previous version of this patch increases the time required to go
      through the dp_detect cycle (which includes reading the edid) from
      around 33 ms to around 40 ms. Experiments indicated that this is
      purely due to the irq latency - the hw doesn't allow us to queue up
      dp aux transactions and hence irq latency directly affects throughput.
      gmbus is much better, there we have a 8 byte buffer, and we get the
      irq once another 4 bytes can be queued up.
      
      But by using the pm_qos interface to request the lowest possible cpu
      wake-up latency this slowdown completely disappeared.
      
      Since all our output detection logic is single-threaded with the
      mode_config mutex right now anyway, I've decide not ot play fancy and
      to just reuse the gmbus wait queue. But this would definitely prep the
      way to run dp detection on different ports in parallel
      
      v2: Add a timeout for dp aux transfers when using interrupts - the hw
      _does_  prevent this with the hw-based 400 usec timeout, but if the
      irq somehow doesn't arrive we're screwed. Lesson learned while
      developing this ;-)
      
      v3: While at it also convert the busy-loop to wait_for_atomic, so that
      we don't run the risk of an infinite loop any more.
      
      v4: Ensure we have the smallest possible irq latency by using the
      pm_qos interface.
      
      v5: Add a comment to the code to explain why we frob pm_qos. Suggested
      by Chris Wilson.
      
      v6: Disable dp irq for vlv, that's easier than trying to get at docs
      and hw.
      
      v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the
      dp aux registers aren't at a fixed offset any more, but can be on the
      PCH while the DP port is on the cpu die.
      
      Reviewed-by: Imre Deak <imre.deak@intel.com> (v6)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9ee32fea
    • Daniel Vetter's avatar
      drm/i915: wire up do aux channel done interrupt · ce99c256
      Daniel Vetter authored
      Doesn't do anything yet than call dp_aux_irq_handler.
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ce99c256
    • 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
  2. 05 Dec, 2012 2 commits
  3. 03 Dec, 2012 4 commits
  4. 30 Nov, 2012 13 commits
  5. 29 Nov, 2012 8 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