1. 25 Jul, 2011 8 commits
    • Benjamin Herrenschmidt's avatar
      drm/radeon: Writeback endian fixes · df07d699
      Benjamin Herrenschmidt authored
      The writeback ring pointer and IH ring pointer are read using le32_to_cpu
      so we do not want the chip to byteswap them on big-endian.
      
      We still want to byteswap the ring itself and the IBs, so we don't touch
      that but we remove setting of the byteswap bits in CP_RB_RPTR_ADDR and
      IH_CNTL.
      
      In general, for things like that where we control all the accessors easily,
      we are better off doing the swap in SW rather than HW. Paradoxally, it does
      keep the code closer to x86 and avoid using poorly tested HW features.
      
      I also changed the use of RADEON_ to R600_ in a couple of cases to be more
      consistent with the surrounding code.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: default avatarMichel Dänzer <michel@daenzer.net>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      df07d699
    • Benjamin Herrenschmidt's avatar
      drm/radeon: Remove a bunch of useless _iomem casts · a0533fbf
      Benjamin Herrenschmidt authored
      Just defining rdev->rmmio properly in the first place should do
      the trick. In some cases, the cast were also complete dups as
      the original variable was already of the right type.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a0533fbf
    • Alan Cox's avatar
      drm/gem: add support for private objects · 62cb7011
      Alan Cox authored
      These small changes should allow GEM to be used with non shmem objects as
      well as shmem objects. In the GMA500 case it allows the base framebuffer to
      appear as a GEM object and thus acquire a handle and work with KMS.
      
      For i915 it ought to be trivial to get back the wasted memory but putting the
      system fb back into stolen RAM and in general I can imagine it allowing the
      use of GEM and thus KMS with all the older cards that have their framebuffer
      firmly placed in video RAM.
      Signed-off-by: default avatarAlan Cox <alan@linux.intel.com>
      Tested-by: default avatarRob Clark <rob@ti.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      62cb7011
    • Rolf Eike Beer's avatar
      DRM: clean up and document parsing of video= parameter · 04fee895
      Rolf Eike Beer authored
      The video= parameter of the DRM drivers supports some additional flags that
      the normal fb drivers do not have. They also allow to limit these flags to
      specific outputs. Both things were previously undocumented.
      
      Also the parsing of the line had some oddities:
      -A lot of misplaced options were silently ignored or partly rejected instead
       of stopping the parsing immediately
      -The 'R' option is documented to follow the 'M' option if specified. It is not
       documented that 'M' is needed to specify 'R' (also this is the case for normal
       fb drivers). In fact the code is correct for normal fb drivers but wrong for
       DRM ones.
       The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only
       if 'M' is given at all which is not needed for the DRM drivers.
      -the margins option ('m') was parsed but later ignored even if the later
       functions support it.
      -specifying multiple enable options at the same time did not lead to an error.
      -specifying something bogus for horizontal resolution (i.e. other things as
       digits) did not lead to an error but an invalid resolution was used.
      
      If any errors are encountered the position of the faulting string is now
      printed to the user and the complete mode is ignored. This gives much
      more consistent error behaviour.
      
      I also removed some useless assignments and changed the local flag variables
      to be bool.
      Signed-off-by: default avatarRolf Eike Beer <eike-kernel@sf-tec.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      04fee895
    • Ralf Baechle's avatar
      DRM: Radeon: Fix section mismatch. · ee276291
      Ralf Baechle authored
      WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in reference from the function radeon_get_clock_info() to the function .devinit.text:radeon_read_clocks_OF()
      The function radeon_get_clock_info() references
      the function __devinit radeon_read_clocks_OF().
      This is often because radeon_get_clock_info lacks a __devinit
      annotation or the annotation of radeon_read_clocks_OF is wrong.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Cc: dri-devel@lists.freedesktop.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ee276291
    • Tormod Volden's avatar
      drm: really make debug levels match in edid failure code · 0aff47f2
      Tormod Volden authored
      Also disable the ascii dump and remove the literal printing of the
      KERN_ERR macro in the log:
      
         [drm:drm_edid_block_valid] *ERROR* Raw EDID:
         <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      
      v2: Remove the trailing empty line as well.
      Signed-off-by: default avatarTormod Volden <debian.tormod@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0aff47f2
    • Alex Deucher's avatar
      drm/radeon/kms: fix i2c map for rv250/280 · 6dd66633
      Alex Deucher authored
      Those chips have crt2_ddc bus.
      
      Fixes:
      https://bugzilla.kernel.org/show_bug.cgi?id=39672Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6dd66633
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-next' of... · 603f2e6d
      Dave Airlie authored
      Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next
      
      * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
        drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
        drm/nouveau: pass flag to engine fini() method on suspend
        drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
        drm/nv40/gr: rewrite/split context takedown functions
        drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
        drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
        drm/nouveau: Add a quirk for Gigabyte NX86T
        drm/nouveau: do not leak in nv20_graph_create
        drm/nv50/dp: fix hack to work for macbooks booted via EFI
      603f2e6d
  2. 24 Jul, 2011 9 commits
  3. 18 Jul, 2011 1 commit
  4. 15 Jul, 2011 1 commit
  5. 14 Jul, 2011 5 commits
  6. 13 Jul, 2011 7 commits
  7. 12 Jul, 2011 4 commits
    • Keith Packard's avatar
      9aa73a51
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Idling requires waiting for the ring to be empty · a94919ea
      Chris Wilson authored
      ...which is measured by the size and not the amount of space remaining.
      
      Waiting upon size-8, did one of two things. In the common case with more
      than 8 bytes available to write into the ring, it would return
      immediately. Otherwise, it would timeout given the impossible condition
      of waiting for more space than is available in the ring, leading to
      warnings such as:
      
      [drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring
      whilst cleaning up: -16
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      a94919ea
    • Keith Packard's avatar
      Revert "drm/i915: enable rc6 by default" · 05bd4268
      Keith Packard authored
      This reverts commit a51f7a66.
      
      We still have a few Ironlake and Sandybridge machines which fail when
      RC6 is enabled. Better luck next release?
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      05bd4268
    • Keith Packard's avatar
      drm/i915: Clean up i915_driver_load failure path · a7b85d2a
      Keith Packard authored
      i915_driver_load adds a write-combining MTRR region for the GTT
      aperture to improve memory speeds through the aperture. If
      i915_driver_load fails after this, it would not have cleaned up the
      MTRR. This shouldn't cause any problems, except for consuming an MTRR
      register. Still, it's best to clean up completely in the failure path,
      which is easily done by calling mtrr_del if the mtrr was successfully
      allocated.
      
      i915_driver_load calls i915_gem_load which register
      i915_gem_inactive_shrink. If i915_driver_load fails after calling
      i915_gem_load, the shrinker will be left registered. When called, it
      will access freed memory and crash. The fix is to unregister the shrinker in the
      failure path using code duplicated from i915_driver_unload.
      
      i915_driver_load also has some incorrect gotos in the error cleanup
      paths:
      
       * After failing to initialize the GTT (which cannot happen, btw,
         intel_gtt_get returns a fixed (non-NULL) value), it tries to
         free the uninitialized WC IO mapping. Fixed this by changing the
         target from out_iomapfree to out_rmmap
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      Tested-by: default avatarLin Ming <ming.m.lin@intel.com>
      a7b85d2a
  8. 11 Jul, 2011 5 commits