1. 31 May, 2012 4 commits
  2. 30 May, 2012 11 commits
    • Paulo Zanoni's avatar
      drm/i915: add some barriers when changing DIPs · 9d9740f0
      Paulo Zanoni authored
      On IVB and older, we basically have two registers: the control and the
      data register. We write a few consecutitve times to the control
      register, and we need these writes to arrive exactly in the specified
      order.
      
      Also, when we're changing the data register, we need to guarantee that
      anything written to the control register already arrived (since
      changing the control register can change where the data register
      points to). Also, we need to make sure all the writes to the data
      register happen exactly in the specified order, and we also *can't*
      read the data register during this process, since reading and/or
      writing it will change the place it points to.
      
      So invoke the "better safe than sorry" rule and just be careful and
      put barriers everywhere :)
      
      On HSW we still have a control register that we write many times, but
      we have many data registers.
      Demanded-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9d9740f0
    • Paulo Zanoni's avatar
      drm/i915: remove comment about HSW HDMI DIPs · c30b6110
      Paulo Zanoni authored
      HSW support is now just like all the other generations: we send AVI
      and SPD InfoFrames. There are other DIPs for HSW, but there are other
      DIPs for the previous generations too. For each gen, we can see which
      DIPs are missing by looking at the 'set_infoframes' function: we
      explicitly disable the DIPs we're not using.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c30b6110
    • Paulo Zanoni's avatar
      drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI · b659c3db
      Paulo Zanoni authored
      The register that controls the HDMI port can be used to control the
      sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
      is one of those: HDMI ports that can't be used in sDVO mode don't even
      have this bit defined in their specifications.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b659c3db
    • Paulo Zanoni's avatar
      drm/i915: don't write 0 to DIP control at HDMI init · 9d32d165
      Paulo Zanoni authored
      At this time, the HDMI port is enabled, and the DIP control register
      specification says we need to disable the port *before* disabling the
      DIPs. Also, while doing this we risk telling the HW to send the AVI
      DIPs once (not every VSync), which really seems to confuse the HW and
      trigger bugs where the DIPs are not sent.
      
      This code was here just to set the DIP register to a 'known state'
      before using it, but since now the set_infoframes functions already
      set the control registers to a known state, this code can go away.
      
      Also, the previous code disables *all* the DIP registers for *each*
      HDMI port, so we end disabling each DIP register more than once.
      
      This patch solves a problem I can reproduce on my IVB machine. When I
      boot it with just a single HDMI monitor, the AVI InfoFrames are not
      sent. With this patch, the InfoFrames are sent. Previously, I wrote a
      patch to 'touch the DIP registers after we enable the HDMI port' to
      solve this same problem, but that patch doesn't seem to be needed
      anymore after this patch.
      
      All this patch does is revert a chunk of the following commit:
      
          commit 64a8fc01
          Author: Jesse Barnes <jbarnes@virtuousgeek.org>
          Date:   Thu Sep 22 11:16:00 2011 +0530
      
              drm/i915: fix ILK+ infoframe support
      
      So bugs that can be bisected to that commit may be fixed now.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9d32d165
    • Paulo Zanoni's avatar
      drm/i915: disable DIP while changing the port · 72b78c9d
      Paulo Zanoni authored
      The register specification says we need to do this.
      
      V2: Only write the register if the port is enabled.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72b78c9d
    • Paulo Zanoni's avatar
      drm/i915: explicitly disable the DIPs we're not using · 0dd87d20
      Paulo Zanoni authored
      From this point on, the 'set_infoframe' functions always set the DIP
      registers to a known state, so anything done will always be undone at
      the modeset.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0dd87d20
    • Paulo Zanoni's avatar
      drm/i915: don't wait for vblank while writing InfoFrames · 5cde2a62
      Paulo Zanoni authored
      This function is called when the pipe is disabled, so it always gets
      the 50ms timeout.
      
      This function is called once for each InfoFrame, so we actually get a
      100ms timeout. Will be more if we add more InfoFrames.
      
      Also, the spec says we need to "wait for a VSync to ensure completion
      of any pending DIP transmissions", not for a VBlank. OTOH, the
      register documentation suggests that the DIPs are sent *during* the
      VSync, so shouldn't we be waiting until *after* the VSync to ensure
      all DIPs are sent?
      
      So this wait_for_vblank seems, besides useless, totally wrong.
      
      If we ever want to change some specific InfoFrame on-the-fly (outside
      of the modeset code), the code that changes the InfoFrame will have to
      do the waiting itself, and properly.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5cde2a62
    • Paulo Zanoni's avatar
      drm/i915: enable DIP before enabling each InfoFrame · 822974ae
      Paulo Zanoni authored
      So the write_infoframe function can assume the DIP is on.
      
      V2: Be more defensive and add WARN().
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      822974ae
    • Paulo Zanoni's avatar
      drm/i915: only set the HDMI port on the DIP once · f278d972
      Paulo Zanoni authored
      Not once for each InfoFrame. Now we have a function that allows us to
      do this.
      
      [danvet: Paulo clarified on irc that a later bugfix patch needs this
      cleanup.]
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f278d972
    • Paulo Zanoni's avatar
      drm/i915: properly alternate between DVI and HDMI · 0c14c7f9
      Paulo Zanoni authored
      This solves problems that happen when you alternate between HDMI and
      DVI on the same port. I can reproduce these problems using DP->HDMI
      and DP->DVI adapters on a DP port.
      
      When you first plug HDMI and then plug DVI, you need to stop sending
      DIPs, even if the port is in DVI mode (see the HDMI register spec). If
      you don't stop sending DIPs, you'll see a pink vertical line on the
      left side of the screen, some modes will give you a black screen, some
      modes won't work correctly.
      
      When you first plug DVI and then plug HDMI, you need to properly
      enable the DIPs, otherwise the HW won't send them. After spending a
      lot of time investigating this, I concluded that if the DIPs are
      disabled, we should not write to the DIP register again because when
      we do this, we also set the AVI InfoFrame frequency to "once", and
      this seems to really confuse our hardware. Since this problem was not
      exactly easy to debug, I'm adopting the defensive behavior and not
      just avoing the "disable twice" sequence, but also explicitly
      selecting the AVI InfoFrame and setting its frequency to a correct
      one.
      
      Also, move the "is_dvi" check from intel_set_infoframe to the
      set_infoframes functions since now they're going to be the first ones
      to deal with the DIP registers.
      
      This patch adds the code to fix the problem, but it depends on the
      removal of some code that can't be removed right now and will come
      later in the patch series. The patch that we need is:
        - drm/i915: don't write 0 to DIP control at HDMI init
      
      [danvet: Paulo clarified that this additional patch is only required
      to make the fix complete, this patch here alone doesn't introduce a
      regression but only partially solves the problem of randomly clearing
      the dip registers.]
      
      V2: Be even more defensive by selecting AVI and setting its frequency
      outside the "is_dvi" check.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0c14c7f9
    • Paulo Zanoni's avatar
      drm/i915: add set_infoframes to struct intel_hdmi · 687f4d06
      Paulo Zanoni authored
      We need a function that is able to fully 'set' the state of the DIP
      registers to a known state.
      
      Currently, we have the write_infoframe function that is called twice:
      once for AVI and once for SPD. The problem is that write_infoframe
      tries to keep the state of the DIP register as it is, changing only
      the minimum necessary bits. The second problem is that
      write_infoframe does twice (once for each time it is called) some
      work that should be done only once (like waiting for vblank and
      setting the port). If we add even more DIPs, it will do even more
      repeated work.
      
      This patch only adds the infrastructure keeping the code behavior the
      same as before.
      
      v2: add static keywords
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      687f4d06
  3. 25 May, 2012 5 commits
    • Chris Wilson's avatar
      drm/i915/hdmi: Fix reg values for g4x_hdmi_connected · eeafaaca
      Chris Wilson authored
      Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the
      separate HDMI registers where introduced with the first PCH) and so
      g4x_hdmi_connected() never selected the right bit and always returned
      disconnected.
      
      Regression in
      
      commit 8ec22b21
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri May 11 18:01:34 2012 +0100
      
          drm/i915/hdmi: Query the live connector status bit for G4x
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Tested-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      eeafaaca
    • Ben Widawsky's avatar
      drm/i915: s/i915_wait_request/i915_wait_seqno/g · 199b2bc2
      Ben Widawsky authored
      Wait request is poorly named IMO. After working with these functions for
      some time, I feel it's much clearer to name the functions more
      appropriately.
      
      Of course we must update the callers to use the new name as well.
      
      This leaves room within our namespace for a *real* wait request function
      at some point.
      
      Note to maintainer: this patch is optional.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      199b2bc2
    • Ben Widawsky's avatar
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky authored
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      ioctl.
      
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      
      v4: check for 0 timeout after olr check to allow polling (Chris)
      
      v5: Updated the comment. (Chris)
      
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      23ba4fd0
    • Ben Widawsky's avatar
      drm/i915: improve i915_wait_request_begin trace · f3fd3768
      Ben Widawsky authored
      The trace events adds whether or not the wait was blocking. Blocking in
      this case means to hold struct_mutex (ie. no new work can be submitted
      during the wait). The information is inherently racy.
      
      The blocking information is racy since mutex_is_locked doesn't check
      that the current thread holds the lock. The only other option would be
      to pass the boolean information of whether or not the class was blocking
      down through the stack which is less desirable.
      
      v2: Don't do a trace event per loop. (Chris)
      Only get blocking/non-blocking info (Chris)
      
      v3: updated comment in code as well as commit msg (Daniel)
      Add "(NB)" to trace information to remind us in 6 months (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f3fd3768
    • Ben Widawsky's avatar
      drm/i915: timeout parameter for seqno wait · 5c81fe85
      Ben Widawsky authored
      Insert a wait parameter in the code so we can possibly timeout on a
      seqno wait if need be. The code should be functionally the same as
      before because all the callers will continue to retry if an arbitrary
      timeout elapses.
      
      We'd like to have nanosecond granularity, but the only way to do this is
      with hrtimer, and that doesn't fit well with the needs of this code.
      
      v2: Fix rebase error (Chris)
      Return proper time even in wedged + signal case (Chris + Ben)
      Use timespec constructs (Ben)
      Didn't take Daniel's advice regarding the Frankenstein-ness of the
        function. I did try his advice, but in the end I liked the way the
        original code looked, better.
      
      v3: Make wakeups far less frequent for infinite waits (Chris)
      
      v4: Remove dummy_wait variable (Daniel)
      Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
      Added a couple of warnings (Ben)
      
      v5: Remove warnings (Daniel)
      Use more accurate time diff for default case (Daniel)
      Bikeshed for setting the return timespec in timeout case (Daniel)
      s/jiffies/time in one of the comments
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5c81fe85
  4. 22 May, 2012 2 commits
  5. 21 May, 2012 6 commits
    • Chris Wilson's avatar
    • Chris Wilson's avatar
      drm/i915/hdmi: Query the live connector status bit for G4x · 8ec22b21
      Chris Wilson authored
      Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
      whether the connector is active prior to attempting to retrieve the EDID.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8ec22b21
    • Chris Wilson's avatar
      drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x · 084b612e
      Chris Wilson authored
      Note that gen3 is the only platform where we've got the bit
      definitions right, hence the workaround of disabling sdvo hotplug
      support on i945g/gm is not due to misdiagnosis of broken hotplug irq
      handling ...
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
      wondered about while reviewing.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      084b612e
    • Chris Wilson's avatar
      drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 · 10f76a38
      Chris Wilson authored
      The status bits corresponding to the interrupt enable bits are the
      "live" hotplug status bits, and reflect the current status of the port
      (high for a detected connection, low for a disconnect). The actual bits
      corresponding to the interrupt source are elsewhere. The actual event is
      then determined by a combination of the interrupt flag and the current
      live status (if the interrupt is active, but the current status is not,
      then we have detected a disconnect.)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      10f76a38
    • Chris Wilson's avatar
      drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq · adca4730
      Chris Wilson authored
      Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set
      it during post-install, and nor do we wish to enable unwanted hotplug
      events.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      adca4730
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2012-05-20' of... · f15b4ca2
      Dave Airlie authored
      Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
      
      Daniel wrote:
      
      The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly
      bugfixes:
      - last few patches for basic hsw enabling (Eugeni, infoframe support by
       Paulo)
      - Fix up infoframe support, we've hopefully squashed all the cargo-culting
       in there (Paulo). Among all the issues, this finally fixes some of the
       infoframe regressions seen on g4x and snb systems.
      - Fixup sdvo infoframe support, this fixes a regression from 2.6.37.
      - Correctly enable semaphores on snb, we've enabled it already for 3.5,
       but the dmar check was slightly wrong.
      - gen6 irq fixlets from Chris.
      - disable gmbus on i830, the hw seems to be simply broken.
      - fix up the pch pll fallout (Chris & me).
      - for_each_ring macro from Chris - I've figured I'll merge this now to
       avoid backport pain.
      - complain when the rps state isn't what we expect (Chris). Note that this
       is shockingly easy to hit and hence pretty much will cause a regression
       report. But it only tells us that the gpu turbo state got out of whack,
       a problem we know off since a long time (it cause the gpu to get stuck a
       a fixed frequency, usually the lowest one). Chris is working on a fix,
       but we haven't yet found a magic formula that works perfectly (only
       patches that massively reduce the frequency of this happening).
      - MAINTAINERS patch, I'm now officially the guy to beat up."
      
      * tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits)
        drm/i915: IBX has a fixed pch pll to pch pipe mapping
        drm/i915: implement hsw_write_infoframe
        drm/i915: small hdmi coding style cleanups
        drm/i915: fixup infoframe support for sdvo
        drm/i915: Enable the PCH PLL for all generations after link training
        drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
        drm/i915: don't clobber the pipe param in sanitize_modesetting
        drm/i915: disable gmbus on i830
        drm/i915: Replace the feature tests for BLT/BSD with ring init checks
        drm/i915: Check whether the ring is initialised prior to dispatch
        drm/i915: Introduce for_each_ring() macro
        drm/i915: Assert that the transcoder is indeed off before modifying it
        drm/i915: hook Haswell devices in place
        drm/i915: prepare HDMI link for Haswell
        drm/i915: move HDMI structs to shared location
        drm/i915: add WR PLL programming table
        drm/i915: add support for DDI-controlled digital outputs
        drm/i915: detect digital outputs on Haswell
        drm/i915: program iCLKIP on Lynx Point
        drm/i915: program WM_LINETIME on Haswell
        ...
      f15b4ca2
  6. 20 May, 2012 5 commits
  7. 19 May, 2012 7 commits