1. 20 Jul, 2012 3 commits
    • Daniel Vetter's avatar
      drm/fb helper: don't call drm_crtc_helper_set_config · d3904754
      Daniel Vetter authored
      Go through the interface vtable instead, because not everyone might be
      using the crtc helper code.
      
      Cc: dri-devel@lists.freedesktop.org
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d3904754
    • Daniel Vetter's avatar
      drm/fb-helper: delay hotplug handling when partially bound · 343065a6
      Daniel Vetter authored
      Ok, this requires quite a dance to actually hit:
      1) We plug in a 2nd screen, enable it in both X and (by vt-switching)
      in the fbcon.
      2) We disable that screen again in with xrandr.
      3) We vt-switch again, so that fbcon displays on the 2nd screen, but X
      on the first screen. This obviously needs a driver that doesn't switch
      off unused functions when regaining the VT.
      3) When X controls the vt, we unplug that screen.
      
      Now drm_fb_helper_hotplug_event we noticed that that some crtcs are
      bound, but because we still have the fbcon on the 2nd screeen we also
      have bound set. Which means the fbcon wrongly assumes it's in control
      of everything an happily disables the output on the 2nd screen, but
      enables its fb on the first screen.
      
      Work around this issue by counting how many crtcs are bound and how
      many are bound to fbcon and assuming that when fbcon isn't bound to
      all of them, it better not touch the output configuration.
      
      Conceptually this is the same as only restoring the fbcon output
      configuration on the driver's ->lastclose, when we're sure that no one
      else is using kms. So this should be consistent with existing kms
      drivers.
      
      Chris has created a separate patch for the intel ddx, but I think we
      should fix this issue here regardless - the fbcon messing with the
      output config while it's not fully in control simply isn't a too
      polite behaviour.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772Tested-by: default avatarMaxim A. Nikulin <M.A.Nikulin@gmail.com>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      343065a6
    • Dave Airlie's avatar
      Merge branch 'next' of git://people.freedesktop.org/~deathsimple/linux into drm-next · b68bdc1b
      Dave Airlie authored
      This contains all the radeon documentation rebased on top of the ib fixes.
      
      * 'next' of git://people.freedesktop.org/~deathsimple/linux:
        drm/radeon: fix SS setup for DCPLL
        drm/radeon: fix up pll selection on DCE5/6
        drm/radeon: start to document evergreen.c
        drm/radeon: start to document the functions r100.c
        drm/radeon: document VM functions in radeon_gart.c (v3)
        drm/radeon: document non-VM functions in radeon_gart.c (v2)
        drm/radeon: document radeon_ring.c (v4)
        drm/radeon: document radeon_fence.c (v2)
        drm/radeon: document radeon_asic.c
        drm/radeon: document radeon_irq_kms.c
        drm/radeon: document radeon_kms.c
        drm/radeon: document radeon_device.c (v2)
        drm/radeon: add rptr save support for r1xx-r5xx
        drm/radeon: update rptr saving logic for memory buffers
        drm/radeon: remove radeon_ring_index()
        drm/radeon: update ib_execute for SI (v2)
        drm/radeon: fix const IB handling v2
        drm/radeon: let sa manager block for fences to wait for v2
        drm/radeon: return an error if there is nothing to wait for
      b68bdc1b
  2. 18 Jul, 2012 19 commits
  3. 17 Jul, 2012 17 commits
  4. 15 Jul, 2012 1 commit
    • Chris Wilson's avatar
      drm: Add colouring to the range allocator · 6b9d89b4
      Chris Wilson authored
      In order to support snoopable memory on non-LLC architectures (so that
      we can bind vgem objects into the i915 GATT for example), we have to
      avoid the prefetcher on the GPU from crossing memory domains and so
      prevent allocation of a snoopable PTE immediately following an uncached
      PTE. To do that, we need to extend the range allocator with support for
      tracking and segregating different node colours.
      
      This will be used by i915 to segregate memory domains within the GTT.
      
      v2: Now with more drm_mm helpers and less driver interference.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@gmail.com>
      6b9d89b4