1. 06 Jun, 2012 4 commits
  2. 04 Jun, 2012 4 commits
  3. 02 Jun, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: extract object active state flushing code · 30dfebf3
      Daniel Vetter authored
      Both busy_ioctl and the new wait_ioct need to do the same dance (or at
      least should). Some slight changes:
      - busy_ioctl now unconditionally checks for olr. Before emitting a
        require flush would have prevent the olr check and hence required a
        second call to the busy ioctl to really emit the request.
      - the timeout wait now also retires request. Not really required for
        abi-reasons, but makes a notch more sense imo.
      
      I've tested this by pimping the i-g-t test some more and also checking
      the polling behviour of the wait_rendering_timeout ioctl versus what
      busy_ioctl returns.
      
      v2: Too many people complained about unplug, new color is
      flush_active.
      
      v3: Kill the comment about the unplug moniker.
      
      v4: s/un-active/inactive/
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      30dfebf3
  4. 01 Jun, 2012 5 commits
  5. 31 May, 2012 14 commits
  6. 30 May, 2012 12 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
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client · af56e0aa
      Linus Torvalds authored
      Pull ceph updates from Sage Weil:
       "There are some updates and cleanups to the CRUSH placement code, a bug
        fix with incremental maps, several cleanups and fixes from Josh Durgin
        in the RBD block device code, a series of cleanups and bug fixes from
        Alex Elder in the messenger code, and some miscellaneous bounds
        checking and gfp cleanups/fixes."
      
      Fix up trivial conflicts in net/ceph/{messenger.c,osdmap.c} due to the
      networking people preferring "unsigned int" over just "unsigned".
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: (45 commits)
        libceph: fix pg_temp updates
        libceph: avoid unregistering osd request when not registered
        ceph: add auth buf in prepare_write_connect()
        ceph: rename prepare_connect_authorizer()
        ceph: return pointer from prepare_connect_authorizer()
        ceph: use info returned by get_authorizer
        ceph: have get_authorizer methods return pointers
        ceph: ensure auth ops are defined before use
        ceph: messenger: reduce args to create_authorizer
        ceph: define ceph_auth_handshake type
        ceph: messenger: check return from get_authorizer
        ceph: messenger: rework prepare_connect_authorizer()
        ceph: messenger: check prepare_write_connect() result
        ceph: don't set WRITE_PENDING too early
        ceph: drop msgr argument from prepare_write_connect()
        ceph: messenger: send banner in process_connect()
        ceph: messenger: reset connection kvec caller
        libceph: don't reset kvec in prepare_write_banner()
        ceph: ignore preferred_osd field
        ceph: fully initialize new layout
        ...
      af56e0aa