1. 12 12月, 2012 1 次提交
    • D
      drm/i915: Fixup hpd irq register setup ordering · 20afbda2
      Daniel Vetter 提交于
      For GMCH platforms we set up the hpd irq registers in the irq
      postinstall hook. But since we only enable the irq sources we actually
      need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask
      into account, no hpd interrupt sources is enabled since
      
      commit 52d7eced
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Dec 1 21:03:22 2012 +0100
      
          drm/i915: reorder setup sequence to have irqs for output setup
      
      Wrongly set-up interrupts also lead to broken hw-based load-detection
      on at least GM45, resulting in ghost VGA/TV-out outputs.
      
      To fix this, delay the hotplug register setup until after all outputs
      are set up, by moving it into a new dev_priv->display.hpd_irq_callback.
      We might also move the PCH_SPLIT platforms to such a setup eventually.
      
      Another funny part is that we need to delay the fbdev initial config
      probing until after the hpd regs are setup, for otherwise it'll detect
      ghost outputs. But we can only enable the hpd interrupt handling
      itself (and the output polling) _after_ that initial scan, due to
      massive locking brain-damage in the fbdev setup code. Add a big
      comment to explain this cute little dragon lair.
      
      v2: Encapsulate all the fbdev handling by wrapping the move call into
      intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson.
      
      v3: Applied bikeshed from Jesse Barnes.
      
      v4: Imre Deak noticed that we also need to call intel_hpd_init after
      the drm_irqinstall calls in the gpu reset and resume paths - otherwise
      hotplug will be broken. Also improve the comment a bit about why
      hpd_init needs to be called before we set up the initial fbdev config.
      
      Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      20afbda2
  2. 11 12月, 2012 3 次提交
  3. 10 12月, 2012 2 次提交
  4. 09 12月, 2012 1 次提交
  5. 07 12月, 2012 1 次提交
  6. 06 12月, 2012 24 次提交
    • D
      drm/i915: extract common link_m_n helpers · e69d0bc1
      Daniel Vetter 提交于
      Both the dp and fdi code use the exact same computations (ignore minor
      differences in conversion between bits and bytes).
      
      This makes it even more apparent that we have a _massive_ mess between
      cpu transcoder/fdi link/pch transcoder and pch link settings. And also
      that we have hilarious amounts of confusion between edp and dp
      (despite that they're identical at a link level).
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e69d0bc1
    • D
      drm/i915: drop unnecessary clearing of pch dp transcoder timings · 2f0c2ad1
      Daniel Vetter 提交于
      This has originally been added in
      
      commit 8db9d77b
      Author: Zhenyu Wang <zhenyuw@linux.intel.com>
      Date:   Wed Apr 7 16:15:54 2010 +0800
      
          drm/i915: Support for Cougarpoint PCH display pipeline
      
      probably to combat issues with hw state left behind by the BIOS. And
      indeed, I've checked out that specific revision, and there is no DP
      support yet. So the pch dp transcoder won't be correctly disabled, and
      that's important since it requires a rether special disable dance:
      Just writing 0 to TRANS_DP_CTL won't cut it, since we need to select
      the NONE port when disabling, too.
      
      And indeed, things seem to still work, so let's just remove this.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2f0c2ad1
    • D
      drm/i915: WARN on !crtc in intel_dp_link_down · ff50afe9
      Daniel Vetter 提交于
      This could have happened with the old crtc helper based modeset code,
      but can't happen any longer with the new code.
      
      Hence put in a WARN and adjust the comment. If no one hits this, we
      can eventually remove it (like a few other such cases across our
      code).
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ff50afe9
    • D
      drm/i915: use wait_for_vblank instead of msleep(17) · ab527efc
      Daniel Vetter 提交于
      17 ms is eerily close to 60 Hz ^-1
      
      Unfortunately this goes back to the original DP enabling for ilk, and
      unfortunately does not come with a reason for it's existance attached.
      
      Some closer inspection of the code and DP specs shows that we set the
      idle link pattern before we disable the port. And it seems like that
      the DP spec (or at least our hw) only switch to the idle pattern on
      the next vblank. Hence a vblank wait at this spot makes _much_ more
      sense than a really long wait.
      
      v2: Rebase fixup.
      
      v3: Add comment requested by Paulo Zanoni saying that we don't really
      know what this wait is for.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ab527efc
    • D
      drm/i915: rip out pre-production ilk cpu edp w/a · 1ce17038
      Daniel Vetter 提交于
      While reading docs I've noticed that this special workaround to select
      the 1.6 GHz DP clock only applies to pre-production ilk machines.
      Since the registers we're touching here are rather undocumented and
      might be harmful on later chips, rip it out.
      
      For the Bspec reference of this w/a look in "vol4g CPU Display
      Registers [DevILK]", Section 4.1.7.1 "DP_A—DisplayPort A
      Control Register", "DP_PLL_Frequency_Select".
      
      v2: Keep a debug message as a hint in case something regresses.
      Requested by Chris Wilson.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1ce17038
    • D
      drm/i915: move set_pll_edp to intel_dp.c · ea9b6006
      Daniel Vetter 提交于
      Now that we enable the cpu edp pll in intel_dp->pre_enable and no
      longer in crtc_mode_set, we can also move the modeset part to the
      intel_dp->mode_set callback. Previously this was not possible because
      the encoder ->mode_set callbacks are called after the crtc mode set
      callback.
      
      v2: Rebase on top of copy&pasted hsw crtc_mode_set.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ea9b6006
    • D
      drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set · ed7ef439
      Daniel Vetter 提交于
      Especially getting rid of all things lvds is ... great!
      
      v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.
      
      v3:
      - handle DP ports correctly (spoted by Paulo)
      - don't leave {} behind for a single-line block (again spotted by
        Paulo)
      - kill another if (IBX || CPT) block
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ed7ef439
    • P
      drm/i915: be less verbose when handling gmbus/aux irqs · 36dacf5b
      Paulo Zanoni 提交于
      Having 9500 lines repeated on dmesg does not help me at all.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36dacf5b
    • D
      drm/i915: Remove duplicate and unused register #defines in i915_reg.h · 6ef6a450
      Dexuan Cui 提交于
      TRANS_DP_VIDEO_AUDIO is not used at all.
      The other 3 has duplicated #defines.
      Signed-off-by: NDexuan Cui <dexuan.cui@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6ef6a450
    • D
      drm/i915: use _NOTRACE for gmbus/dp aux wait loops · ef04f00d
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ef04f00d
    • D
      drm/i915: irq-drive the dp aux communication · 9ee32fea
      Daniel Vetter 提交于
      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: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9ee32fea
    • D
      drm/i915: wire up do aux channel done interrupt · ce99c256
      Daniel Vetter 提交于
      Doesn't do anything yet than call dp_aux_irq_handler.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ce99c256
    • D
      drm/i915: use gmbus irq to wait for gmbus idle · 2c438c02
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2c438c02
    • D
      drm/i915: use the gmbus irq for waits · 28c70f16
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      28c70f16
    • D
      drm/i915: wire up gmbus irq handler · 515ac2bb
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      515ac2bb
    • D
      drm/i915: extract gmbus_wait_hw_status · 61168c53
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      61168c53
    • D
      drm/i915: reorder setup sequence to have irqs for output setup · 52d7eced
      Daniel Vetter 提交于
      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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      52d7eced
    • D
      drm/i915: setup the hangcheck timer early · 61bac78e
      Daniel Vetter 提交于
      ... 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: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      61bac78e
    • D
      drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv · d83779a9
      Daniel Vetter 提交于
      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: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d83779a9
    • D
      drm/i915: haswell has the same irq handlers as ivb · 4a06e201
      Daniel Vetter 提交于
      No need to have the exaxt same code twice.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4a06e201
    • M
      drm/i915: Add intel_ring_handle_seqno wrap · 498d2ac1
      Mika Kuoppala 提交于
      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: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add a small comment to handle_seqno_wrap.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      498d2ac1
    • M
      drm/i915: Split intel_ring_begin · cbcc80df
      Mika Kuoppala 提交于
      In preparation for handling ring seqno wrapping, split
      intel_ring_begin into helper part which doesn't allocate
      seqno.
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cbcc80df
    • M
      drm/i915: Fix debugfs seqno info print to use uint · 43a7b924
      Mika Kuoppala 提交于
      seqno's are u32 so print accordingly
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      43a7b924
    • M
      drm/i915: Add debugfs entry to read/write next_seqno · 40633219
      Mika Kuoppala 提交于
      This is needed for testing seqno wrapping. Be careful to not bump next_seqno
      more than 0x7FFFFFFF at a time (between some handled requests) as
      i915_seqno_passed() can't handle bigger difference in between.
      
      v2: Address review comments from Chris Wilson.
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Squash in fixup to properly remove the debugfs file on driver
      unload again.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      40633219
  7. 04 12月, 2012 4 次提交
  8. 01 12月, 2012 4 次提交