1. 20 Jan, 2013 15 commits
    • Chris Wilson's avatar
      drm/i915: Only insert the mb() before updating the fence parameter · d0a57789
      Chris Wilson authored
      With a fence, we only need to insert a memory barrier around the actual
      fence alteration for CPU accesses through the GTT. Performing the
      barrier in flush-fence was inserting unnecessary and expensive barriers
      for never fenced objects.
      
      Note removing the barriers from flush-fence, which was effectively a
      barrier before every direct access through the GTT, revealed that we
      where missing a barrier before the first access through the GTT. Lack of
      that barrier was sufficient to cause GPU hangs.
      
      v2: Add a couple more comments to explain the new barriers
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d0a57789
    • Daniel Vetter's avatar
      drm/i915: clear up wedged transitions · 1f83fee0
      Daniel Vetter authored
      We have two important transitions of the wedged state in the current
      code:
      
      - 0 -> 1: This means a hang has been detected, and signals to everyone
        that they please get of any locks, so that the reset work item can
        do its job.
      
      - 1 -> 0: The reset handler has completed.
      
      Now the last transition mixes up two states: "Reset completed and
      successful" and "Reset failed". To distinguish these two we do some
      tricks with the reset completion, but I simply could not convince
      myself that this doesn't race under odd circumstances.
      
      Hence split this up, and add a new terminal state indicating that the
      hw is gone for good.
      
      Also add explicit #defines for both states, update comments.
      
      v2: Split out the reset handling bugfix for the throttle ioctl.
      
      v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase
      error which prevented this patch from actually compiling.
      
      v4: To unify the wedged state with the reset counter, keep the
      reset-in-progress state just as a flag. The terminally-wedged state is
      now denoted with a big number.
      
      v5: Add a comment to the reset_counter special values explaining that
      WEDGED & RESET_IN_PROGRESS needs to be true for the code to be
      correct.
      
      v6: Fixup logic errors introduced with the wedged+reset_counter
      unification. Since WEDGED implies reset-in-progress (in a way we're
      terminally stuck in the dead-but-reset-not-completed state), we need
      ensure that we check for this everywhere. The specific bug was in
      wait_for_error, which would simply have timed out.
      
      v7: Extract an inline i915_reset_in_progress helper to make the code
      more readable. Also annote the reset-in-progress case with an
      unlikely, to help the compiler optimize the fastpath. Do the same for
      the terminally wedged case with i915_terminally_wedged.
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1f83fee0
    • Daniel Vetter's avatar
      drm/i915: fix reset handling in the throttle ioctl · 308887aa
      Daniel Vetter authored
      While auditing the code I've noticed one place (the throttle ioctl)
      which does not yet wait for the reset handler to complete and doesn't
      properly decode the wedge state into -EAGAIN/-EIO. Fix this up by
      calling the right helpers. This might explain the oddball "my
      compositor just died in a successfull gpu reset" reports. Or maybe not, since
      current mesa doesn't use this ioctl to throttle command submission.
      
      The throttle ioctl doesn't take the struct_mutex, so to avoid busy-looping
      with -EAGAIN while a reset is in process, check for errors first and wait
      for the handler to complete if a reset is pending by calling
      i915_gem_wait_for_error.
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      308887aa
    • Daniel Vetter's avatar
      drm/i915: move wedged to the other gpu error handling stuff · 33196ded
      Daniel Vetter authored
      And to make Ben Widawsky happier, use the gpu_error instead of
      the entire device as the argument in some functions.
      
      Drop the outdated comment on ->wedged for now, a follow-up patch will
      change the semantics and add a proper comment again.
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      33196ded
    • Daniel Vetter's avatar
      drm/i915: extract hangcheck/reset/error_state state into substruct · 99584db3
      Daniel Vetter authored
      This has been sprinkled all over the place in dev_priv. I think
      it'd be good to also move all the code into a separate file like
      i915_gem_error.c, but that's for another patch.
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      99584db3
    • Daniel Vetter's avatar
      drm/i915: move dev_priv->mm out of line · 4b5aed62
      Daniel Vetter authored
      Tha one is really big, since it contains tons of comments explaining
      how things work. Which is nice ;-)
      Reviewed-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4b5aed62
    • Ben Widawsky's avatar
      agp/intel: Add gma_bus_addr · e5c65377
      Ben Widawsky authored
      It is no longer used in the i915 code, so isolate it from the shared
      struct.
      
      This was originally part of:
      commit 0e275518f325418d559c05327775bff894b237f7
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Mon Jan 14 13:35:33 2013 -0800
      
          agp/intel: decouple more of the agp-i915 sharing
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      
      That commit had some other hunks which can't be used due to issues
      Daniel found in previous commits.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: drop squash notice from the commit since it's imo ok to keep
      this one separate.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e5c65377
    • Ben Widawsky's avatar
      drm/i915: Needs_dmar, not · 8d2e6308
      Ben Widawsky authored
      The reasoning behind our code taking two paths depending upon whether or
      not we may have been configured for IOMMU isn't clear to me. It should
      always be safe to use the pci mapping functions as they are designed to
      abstract the decision we were handling in i915.
      
      Aside from simpler code, removing another member for the intel_gtt
      struct is a nice motivation.
      
      I ran this by Chris, and he wasn't concerned about the extra kzalloc,
      and memory references vs. page_to_phys calculation in the case without
      IOMMU.
      
      v2: Update commit message
      
      v3: Remove needs_dmar addition from Zhenyu upstream
      
      This reverts (and then other stuff)
      commit 20652097
      Author: Zhenyu Wang <zhenyuw@linux.intel.com>
      Date:   Thu Dec 13 23:47:47 2012 +0800
      
          drm/i915: Fix missed needs_dmar setting
      
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: Squash in follow-up fix to remove the bogus hunk which
      deleted the dma_mask configuration for gen6+.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8d2e6308
    • Ben Widawsky's avatar
      drm/i915: Remove scratch page from shared · 9c61a32d
      Ben Widawsky authored
      We already had a mapping in both (minus the phys_addr in AGP).
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9c61a32d
    • Ben Widawsky's avatar
      drm/i915: Cut out the infamous ILK w/a from AGP layer · a81cc00c
      Ben Widawsky authored
      And, move it to where the rest of the logic is.
      
      There is some slight functionality changes. There was extra paranoid
      checks in AGP code making sure we never do idle maps on gen2 parts. That
      was not duplicated as the simple PCI id check should do the right thing.
      
      v2: use IS_GEN5 && IS_MOBILE check instead. For now, this is the same as
      IS_IRONLAKE_M but is more future proof. The workaround docs hint that
      more than one platform may be effected, but we've never seen such a
      platform in the wild. (Rodrigo, Daniel)
      
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a81cc00c
    • Ville Syrjälä's avatar
      drm/i915: Provide the quantization range in the AVI infoframe · abedc077
      Ville Syrjälä authored
      The AVI infoframe is able to inform the display whether the source is
      sending full or limited range RGB data.
      
      As per CEA-861 [1] we must first check whether the display reports the
      quantization range as selectable, and if so we can set the approriate
      bits in the AVI inforframe.
      
      [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
      
      v2: Give the Q bits better names, add spec chapter information
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      abedc077
    • Ville Syrjälä's avatar
      drm/edid: Add drm_rgb_quant_range_selectable() · b1edd6a6
      Ville Syrjälä authored
      drm_rgb_quant_range_selectable() will report whether the monitor
      claims to support for RGB quantization range selection.
      
      The information can be found in the CEA Video capability block.
      
      v2: s/quantzation/quantization/ in the comment
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: default avatarDavid Airlie <airlied@linux.ie>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b1edd6a6
    • Ville Syrjälä's avatar
      drm/i915: Add "Automatic" mode for the "Broadcast RGB" property · 55bc60db
      Ville Syrjälä authored
      Add a new "Automatic" mode to the "Broadcast RGB" range property.
      When selected the driver automagically selects between full range and
      limited range output.
      
      Based on CEA-861 [1] guidelines, limited range output is selected if the
      mode is a CEA mode, except 640x480. Otherwise full range output is used.
      Additionally DVI monitors should most likely default to full range
      always.
      
      As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
      otherwise will follow CEA-861 rules.
      
      NOTE: The default value for the property will now be "Automatic"
      so some people may be affected in case they're relying on the
      current full range default.
      
      [1] CEA-861-E - 5.1 Default Encoding Parameters
      [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
      
      v2: Use has_hdmi_sink to check if a HDMI monitor is present
      v3: Add information about relevant spec chapters
      Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      55bc60db
    • Ville Syrjälä's avatar
      drm/i915: Fix RGB color range property for PCH platforms · 3685a8f3
      Ville Syrjälä authored
      The RGB color range select bit on the DP/SDVO/HDMI registers
      disappeared when PCH was introduced, and instead a new PIPECONF bit
      was added that performs the same function.
      
      Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
      it in the encoder mode_fixup if limited color range is requested.
      Set the the PIPECONF bit 13 based on the flag.
      
      Experimentation showed that simply toggling the bit while the pipe is
      active doesn't work. We need to restart the pipe, which luckily already
      happens.
      
      The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
      although it doesn't seem to do any harm in practice.
      
      TODO:
      - the PIPECONF bit too seems to have disappeared from HSW. Need a
        volunteer to test if it's just a documentation issue or if it's really
        gone. If the bit is gone and no easy replacement is found, then I suppose
        we may need to use the pipe CSC unit to perform the range compression.
      
      v2: Use mode private_flags instead of intel_encoder virtual functions
      v3: Moved the intel_dp color_range handling after bpc check to help
          later patches
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800Reviewed-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3685a8f3
    • Ben Widawsky's avatar
      drm/i915: Remove use of gtt_mappable_entries · 93d18799
      Ben Widawsky authored
      Mappable_end, ie. size is almost always what you want as opposed to the
      number of entries. Since we already have that information, we can scrap
      the number of entries and only calculate it when needed.
      
      If gtt_start is !0, this will have slightly different behavior. This
      difference can only occur in DRI1, and exists when we try to kick out
      the firmware fb. The new code seems like a bugfix to me.
      
      The other case where we've changed the behavior is during init we check
      the mappable region against our current known upper and lower limits
      (64MB, and 512MB). This now matches the comment, and makes things more
      convenient after removing gtt_mappable_entries.
      
      Also worth noting is the setting of mappable_end is taken out of setup
      because we do it earlier now in the DRI2 case and therefore need to add
      that tiny hunk to support the DRI1 IOCTL.
      
      v2: Move up mappable end to before legacy AGP init
      
      v3: Add the dev_priv inclusion here from previous rebase error in patch
      5
      
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      [danvet: squash in fix for a printk format flag mismatch warning.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      93d18799
  2. 17 Jan, 2013 19 commits
  3. 10 Jan, 2013 1 commit
  4. 09 Jan, 2013 5 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · 5c49985c
      Linus Torvalds authored
      Pull ARM fixes from Russell King.
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: 7616/1: cache-l2x0: aurora: Use writel_relaxed instead of writel
        ARM: 7615/1: cache-l2x0: aurora: Invalidate during clean operation with WT enable
        ARM: 7614/1: mm: fix wrong branch from Cortex-A9 to PJ4b
        ARM: 7612/1: imx: Do not select some errata that depends on !ARCH_MULTIPLATFORM
        ARM: 7611/1: VIC: fix bug in VIC irqdomain code
        ARM: 7610/1: versatile: bump IRQ numbers
        ARM: 7609/1: disable errata work-arounds which access secure registers
        ARM: 7608/1: l2x0: Only set .set_debug on PL310 r3p0 and earlier
      5c49985c
    • Linus Torvalds's avatar
      Merge tag 'edac_fixes_for_3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp · 57a0c1e2
      Linus Torvalds authored
      Pull EDAC fixes from Borislav Petkov:
       "Two error path fixes causing a crash and a Kconfig fix for an issue
        which spilled all EDAC suboptions into the 'Device Drivers' menu."
      
      * tag 'edac_fixes_for_3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
        EDAC: Cleanup device deregistering path
        EDAC: Fix EDAC Kconfig menu
        EDAC: Fix kernel panic on module unloading
      57a0c1e2
    • Linus Torvalds's avatar
      mm: reinstante dropped pmd_trans_splitting() check · e53289c0
      Linus Torvalds authored
      The check for a pmd being in the process of being split was dropped by
      mistake by commit d10e63f2 ("mm: numa: Create basic numa page
      hinting infrastructure"). Put it back.
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Debugged-by: default avatarHillf Danton <dhillf@gmail.com>
      Acked-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Cc: Kirill Shutemov <kirill@shutemov.name>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e53289c0
    • Marc Dionne's avatar
      cred: Remove tgcred pointer from struct cred · 08c097fc
      Marc Dionne authored
      Commit 3a50597d ("KEYS: Make the session and process keyrings
      per-thread") removed the definition of the thread_group_cred structure,
      but left a now unused pointer in struct cred.
      Signed-off-by: default avatarMarc Dionne <marc.c.dionne@gmail.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      08c097fc
    • Linus Torvalds's avatar
      Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 974b3358
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "People are back from the holiday breaks, and it shows.  Here are a
        bunch of fixes for a number of platforms:
         - A couple of small fixes for Nomadik
         - A larger set of changes for kirkwood/mvebu
           - uart driver selection, dt clocks, gpio-poweroff fixups, a few
             __init annotation fixes and some error handling improvement in
             their xor dma driver.
         - i.MX had a couple of minor fixes (and a critical one for flexcan2
           clock setup)
         - MXS has a small board fix and a framebuffer bugfix
         - A set of fixes for Samsung Exynos, fixing default bootargs and some
           Exynos5440 clock issues
         - A set of OMAP changes including PM fixes and a few sparse warning
           fixups
      
        All in all a bit more positive code delta than we'd ideally want to
        see here, mostly from the OMAP PM changes, but nothing overly crazy."
      
      * tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (44 commits)
        ARM: clps711x: Fix bad merge of clockevents setup
        ARM: highbank: save and restore L2 cache and GIC on suspend
        ARM: highbank: add a power request clear
        ARM: highbank: fix secondary boot and hotplug
        ARM: highbank: fix typos with hignbank in power request functions
        ARM: dts: fix highbank cpu mpidr values
        ARM: dts: add device_type prop to cpu nodes on Calxeda platforms
        ARM: mx5: Fix MX53 flexcan2 clock
        ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array
        pinctrl: mvebu: make pdma clock on dove mandatory
        ARM: Dove: Add pinctrl clock to DT
        dma: mv_xor: fix error handling for clocks
        dma: mv_xor: fix error handling of mv_xor_channel_add()
        arm: mvebu: Add missing ; for cpu node.
        arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces
        arm: mvebu: Armada XP MV78230 has two cores, not one
        clk: mvebu: Remove inappropriate __init tagging
        ARM: Kirkwood: Use fixed-regulator instead of board gpio call
        ARM: Kirkwood: Fix missing sdio clock
        ARM: Kirkwood: Switch TWSI1 of 88f6282 to DT clock providers
        ...
      974b3358