1. 29 Aug, 2013 4 commits
    • Dave Airlie's avatar
      nouveau: add runtime PM support (v0.9) · 5addcf0a
      Dave Airlie authored
      This hooks nouveau up to the runtime PM system to enable
      dynamic power management for secondary GPUs in switchable
      and optimus laptops.
      
      a) rewrite suspend/resume printks to hide them during dynamic s/r
      to avoid cluttering logs
      b) add runtime pm suspend to irq handler, crtc display, ioctl handler,
      connector status,
      c) handle hdmi audio dynamic power on/off using magic register.
      
      v0.5:
      make sure we hit D3 properly
      fix fbdev_set_suspend locking interaction, we only will poweroff if we have no
      active crtcs/fbcon anyways.
      add reference for active crtcs.
      sprinkle mark last busy for autosuspend timeout
      
      v0.6:
      allow more flexible debugging - to avoid log spam
      add option to enable/disable dynpm
      got to D3Cold
      
      v0.7:
      add hdmi audio support.
      
      v0.8:
      call autosuspend from idle, so pci config space access doesn't go straight
      back to sleep, this makes starting X faster.
      only signal usage if we actually handle the irq, otherwise usb keeps us awake.
      fix nv50 display active powerdown
      
      v0.9:
      use masking function to enable hdmi audio
      set busy when we fail to suspend
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      5addcf0a
    • Dave Airlie's avatar
      drm: allow open of dynamic off devices. · 13bb9cc8
      Dave Airlie authored
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      13bb9cc8
    • Dave Airlie's avatar
      snd/hda: add runtime suspend/resume on optimus support (v4) · 246efa4a
      Dave Airlie authored
      Add support for HDMI audio device on VGA cards that powerdown
      to D3cold using non-standard ACPI/PCI infrastructure (optimus).
      
      This does a couple of things to make it work:
      
      a) add a set of power ops for the hdmi domain, and enables them
      via vga_switcheroo when we are a switcheroo controlled card. This
      just replaces the runtime resume operation so that when the card
      is in D3cold the userspace pci config space access via sysfs,
      the vga switcheroon runtime resume gets called first and it calls
      the GPU resume callback before calling the sound card runtime
      resume.
      
      b) standard ACPI/PCI stacks won't put a device into D3cold without
      an ACPI handle, but since the hdmi audio devices on gpus don't have
      an ACPI handle, we need to manually force the device into D3cold
      after suspend from the switcheroo path only.
      
      c) don't try and do runtime s/r when the GPU is off.
      
      d) call runtime suspend/resume during switcheroo suspend/resume
      this is to make sure the runtime stack knows to try and resume
      the hdmi audio device for pci config space access.
      
      v2: fix incorrect runtime call suspend->resume.
      
      v3: rework irq handler to avoid false irq when we are resuming
      but haven't runtime resumed yet, don't bother trying D3cold,
      it won't work, just set it manually ourselves, move runtime s/r
      calls outside the main s/r hook. enable dnyamic pm properly by
      dropping reference.
      
      v4: put back irq handler check just wrap it with cap check
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      246efa4a
    • Dave Airlie's avatar
      gpu/vga_switcheroo: add driver control power feature. (v3) · 0d69704a
      Dave Airlie authored
      For optimus and powerxpress muxless we really want the GPU
      driver deciding when to power up/down the GPU, not userspace.
      
      This adds the ability for a driver to dynamically power up/down
      the GPU and remove the switcheroo from controlling it, the
      switcheroo reports the dynamic state to userspace also.
      
      It also adds 2 power domains, one for machine where the power
      switch is controlled outside the GPU D3 state, so the powerdown
      ordering is done correctly, and the second for the hdmi audio
      device to make sure it can resume for PCI config space accesses.
      
      v1.1: fix build with switcheroo off
      
      v2: add power domain support for radeon and v1 nvidia dsms
      v2.1: fix typo in off case
      
      v3: add audio power domain for hdmi audio + misc audio fixes
      
      v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
      failure also.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0d69704a
  2. 28 Aug, 2013 1 commit
  3. 27 Aug, 2013 3 commits
    • David Herrmann's avatar
      drm: verify vma access in TTM+GEM drivers · acb46527
      David Herrmann authored
      GEM does already a good job in tracking access to gem buffers via handles
      and drm_vma access management. However, TTM drivers currently do not
      verify this during mmap().
      
      TTM provides the verify_access() callback to test this. So fix all drivers
      to actually call into gem+vma to verify access instead of always returning
      0.
      
      All drivers assume that user-space can only get access to TTM buffers via
      GEM handles. So whenever the verify_access() callback is called from
      ttm_bo_mmap(), the buffer must have a valid embedded gem object. This is
      true for all TTM+GEM drivers. But that's why this patch doesn't touch pure
      TTM drivers (ie, vmwgfx).
      
      v2: Switch to drm_vma_node_verify_access() to correctly return -EACCES if
          access was denied.
      
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      acb46527
    • David Herrmann's avatar
      drm/gem: implement vma access management · ca481c9b
      David Herrmann authored
      We implement automatic vma mmap() access management for all drivers using
      gem_mmap. We use the vma manager to add each open-file that creates a
      gem-handle to the vma-node of the underlying gem object. Once the handle
      is destroyed, we drop the open-file again.
      
      This allows us to use drm_vma_node_is_allowed() on _any_ gem object to see
      whether an open-file is granted access. In drm_gem_mmap() we use this to
      verify that unprivileged users cannot guess gem offsets and map arbitrary
      buffers.
      
      Note that this manages access for _all_ gem users (also TTM+GEM), but the
      actual access checks are only done for drm_gem_mmap(). TTM drivers use the
      TTM mmap helpers, which need to do that separately.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ca481c9b
    • David Herrmann's avatar
      drm/vma: add access management helpers · 88d7ebe5
      David Herrmann authored
      The VMA offset manager uses a device-global address-space. Hence, any
      user can currently map any offset-node they want. They only need to guess
      the right offset. If we wanted per open-file offset spaces, we'd either
      need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
      both doesn't really scale, we implement access management in the VMA
      manager itself.
      
      We use an rb-tree to store open-files for each VMA node. On each mmap
      call, GEM, TTM or the drivers must check whether the current user is
      allowed to map this file.
      
      We add a separate lock for each node as there is no generic lock available
      for the caller to protect the node easily.
      
      As we currently don't know whether an object may be used for mmap(), we
      have to do access management for all objects. If it turns out to slow down
      handle creation/deletion significantly, we can optimize it in several
      ways:
       - Most times only a single filp is added per bo so we could use a static
         "struct file *main_filp" which is checked/added/removed first before we
         fall back to the rbtree+drm_vma_offset_file.
         This could be even done lockless with rcu.
       - Let user-space pass a hint whether mmap() should be supported on the
         bo and avoid access-management if not.
       - .. there are probably more ideas once we have benchmarks ..
      
      v2: add drm_vma_node_verify_access() helper
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      88d7ebe5
  4. 24 Aug, 2013 5 commits
    • Rob Clark's avatar
      drm/msm: add basic hangcheck/recovery mechanism · bd6f82d8
      Rob Clark authored
      A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
      could try to be a bit more fancy and restart the next submit after the
      one that got wedged, but for now keep it simple.  This is enough to
      recover things if, for example, the gpu hangs mid way through a piglit
      run.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      bd6f82d8
    • Rob Clark's avatar
      drm/msm: add a3xx gpu support · 7198e6b0
      Rob Clark authored
      Add initial support for a3xx 3d core.
      
      So far, with hardware that I've seen to date, we can have:
       + zero, one, or two z180 2d cores
       + a3xx or a2xx 3d core, which share a common CP (the firmware
         for the CP seems to implement some different PM4 packet types
         but the basics of cmdstream submission are the same)
      
      Which means that the eventual complete "class" hierarchy, once
      support for all past and present hw is in place, becomes:
       + msm_gpu
         + adreno_gpu
           + a3xx_gpu
           + a2xx_gpu
         + z180_gpu
      
      This commit splits out the parts that will eventually be common
      between a2xx/a3xx into adreno_gpu, and the parts that are even
      common to z180 into msm_gpu.
      
      Note that there is no cmdstream validation required.  All memory access
      from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
      to the GPU, there isn't much damage that the GPU can do.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      7198e6b0
    • Rob Clark's avatar
      drm/msm: add register definitions for gpu · 902e6eb8
      Rob Clark authored
      Generated from rnndb files in:
      
      https://github.com/freedreno/envytools
      
      Keep this split out as a separate commit to make it easier to review the
      actual driver.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      902e6eb8
    • Rob Clark's avatar
      drm/msm: basic KMS driver for snapdragon · c8afe684
      Rob Clark authored
      The snapdragon chips have multiple different display controllers,
      depending on which chip variant/version.  (As far as I can tell, current
      devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
      then external to the display controller are HDMI, DSI, etc. blocks which
      may be shared across devices which have different display controller
      blocks.
      
      To more easily add support for different display controller blocks, the
      display controller specific bits are split out into a "kms" module,
      which provides the kms plane/crtc/encoder objects.
      
      The external HDMI, DSI, etc. blocks are part encoder, and part connector
      currently.  But I think I will pull in the drm_bridge patches from
      chromeos tree, and split them into a bridge+connector, with the
      registers that need to be set in modeset handled by the bridge.  This
      would remove the 'msm_connector' base class.  But some things need to be
      double checked to make sure I could get the correct ON/OFF sequencing..
      
      This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
      (part of MDP4 block), and hdmi.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      c8afe684
    • Rob Clark's avatar
      drm/msm: add register definitions · 0cf6c71d
      Rob Clark authored
      Generated from rnndb files in:
      
      https://github.com/freedreno/envytools
      
      Keep this split out as a separate commit to make it easier to review the
      actual driver.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      0cf6c71d
  5. 22 Aug, 2013 1 commit
    • Dave Airlie's avatar
      Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-next · 291d284c
      Dave Airlie authored
      Here's some gma500 unifying and cleanups for drm-next. There is more stuff in
      the pipe for 3.12 but I'd like to get these out of the way first.
      
      * 'gma500-next' of git://github.com/patjak/drm-gma500: (35 commits)
        drm/gma500/cdv: Add and hook up chip op for disabling sr
        drm/gma500/cdv: Add and hook up chip op for watermarks
        drm/gma500: Rename psb_intel_encoder to gma_encoder
        drm/gma500: Rename psb_intel_connector to gma_connector
        drm/gma500: Rename psb_intel_crtc to gma_crtc
        drm/gma500/cdv: Convert to generic set_config()
        drm/gma500/psb: Convert to generic set_config()
        drm/gma500: Add generic set_config() function
        drm/gma500/cdv: Convert to generic save/restore
        drm/gma500/psb: Convert to generic save/restore
        drm/gma500: Add generic crtc save/restore funcs
        drm/gma500: Convert to generic encoder funcs
        drm/gma500: Add generic encoder functions
        drm/gma500/psb: Convert to generic cursor funcs
        drm/gma500/cdv: Convert to generic cursor funcs
        drm/gma500: Add generic cursor functions
        drm/gma500/psb: Convert to generic crtc->destroy
        drm/gma500/mdfld: Use identical generic crtc funcs
        drm/gma500/oak: Use identical generic crtc funcs
        drm/gma500/psb: Convert to gma_crtc_dpms()
        ...
      291d284c
  6. 21 Aug, 2013 21 commits
    • Daniel Vetter's avatar
      drm/prime: Always add exported buffers to the handle cache · d0b2c533
      Daniel Vetter authored
      ... not only when the dma-buf is freshly created. In contrived
      examples someone else could have exported/imported the dma-buf already
      and handed us the gem object with a flink name. If such on object gets
      reexported as a dma_buf we won't have it in the handle cache already,
      which breaks the guarantee that for dma-buf imports we always hand
      back an existing handle if there is one.
      
      This is exercised by igt/prime_self_import/with_one_bo_two_files
      
      Now if we extend the locked sections just a notch more we can also
      plug th racy buf/handle cache setup in handle_to_fd:
      
      If evil userspace races a concurrent gem close against a prime export
      operation we can end up tearing down the gem handle before the dma buf
      handle cache is set up. When handle_to_fd gets around to adding the
      handle to the cache there will be no one left to clean it up,
      effectily leaking the bo (and the dma-buf, since the handle cache
      holds a ref on the dma-buf):
      
      Thread A			Thread B
      
      handle_to_fd:
      
      lookup gem object from handle
      creates new dma_buf
      
      				gem_close on the same handle
      				obj->dma_buf is set, but file priv buf
      				handle cache has no entry
      
      				obj->handle_count drops to 0
      
      drm_prime_add_buf_handle sets up the handle cache
      
      -> We have a dma-buf reference in the handle cache, but since the
      handle_count of the gem object already dropped to 0 no on will clean
      it up. When closing the drm device fd we'll hit the WARN_ON in
      drm_prime_destroy_file_private.
      
      The important change is to extend the critical section of the
      filp->prime.lock to cover the gem handle lookup. This serializes with
      a concurrent gem handle close.
      
      This leak is exercised by igt/prime_self_import/export-vs-gem_close-race
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      d0b2c533
    • Daniel Vetter's avatar
      drm/prime: make drm_prime_lookup_buf_handle static · de9564d8
      Daniel Vetter authored
      ... and move it to the top of the function to avoid a forward
      declaration.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      de9564d8
    • Daniel Vetter's avatar
      drm/prime: Simplify drm_gem_remove_prime_handles · 838cd445
      Daniel Vetter authored
      with the reworking semantics and locking of the obj->dma_buf pointer
      this pointer is always set as long as there's still a gem handle
      around and a dma_buf associated with this gem object.
      
      Also, the per file-priv lookup-cache for dma-buf importing is also
      unified between foreign and native objects.
      
      Hence we don't need to special case the clean any more and can simply
      drop the clause which only runs for foreing objects, i.e. with
      obj->import_attach set.
      
      Note that with this change (actually with the previous one to always
      set up obj->dma_buf even for foreign objects) it is no longer required
      to set obj->import_attach when importing a foreing object. So update
      comments accordingly, too.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      838cd445
    • Daniel Vetter's avatar
      drm/prime: proper locking+refcounting for obj->dma_buf link · 319c933c
      Daniel Vetter authored
      The export dma-buf cache is semantically similar to an flink name. So
      semantically it makes sense to treat it the same and remove the name
      (i.e. the dma_buf pointer) and its references when the last gem handle
      disappears.
      
      Again we need to be careful, but double so: Not just could someone
      race and export with a gem close ioctl (so we need to recheck
      obj->handle_count again when assigning the new name), but multiple
      exports can also race against each another. This is prevented by
      holding the dev->object_name_lock across the entire section which
      touches obj->dma_buf.
      
      With the new scheme we also need to reinstate the obj->dma_buf link at
      import time (in case the only reference userspace has held in-between
      was through the dma-buf fd and not through any native gem handle). For
      simplicity we don't check whether it's a native object but
      unconditionally set up that link - with the new scheme of removing the
      obj->dma_buf reference when the last handle disappears we can do that.
      
      To make it clear that this is not just for exported buffers anymore
      als rename it from export_dma_buf to dma_buf.
      
      To make sure that now one can race a fd_to_handle or handle_to_fd with
      gem_close we use the same tricks as in flink of extending the
      dev->object_name_locking critical section. With this change we finally
      have a guaranteed 1:1 relationship (at least for native objects)
      between gem objects and dma-bufs, even accounting for races (which can
      happen since the dma-buf itself holds a reference while in-flight).
      
      This prevent igt/prime_self_import/export-vs-gem_close-race from
      Oopsing the kernel. There is still a leak though since the per-file
      priv dma-buf/handle cache handling is racy. That will be fixed in a
      later patch.
      
      v2: Remove the bogus dma_buf_put from the export_and_register_object
      failure path if we've raced with the handle count dropping to 0.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      319c933c
    • Daniel Vetter's avatar
      drm/gem: completely close gem_open vs. gem_close races · 20228c44
      Daniel Vetter authored
      The gem flink name holds a reference onto the object itself, and this
      self-reference would prevent an flink'ed object from every being
      freed. To break that loop we remove the flink name when the last
      userspace handle disappears, i.e. when obj->handle_count reaches 0.
      
      Now in gem_open we drop the dev->object_name_lock between the flink
      name lookup and actually adding the handle. This means a concurrent
      gem_close of the last handle could result in the flink name getting
      reaped right inbetween, i.e.
      
      Thread 1		Thread 2
      gem_open		gem_close
      
      flink -> obj lookup
      			handle_count drops to 0
      			remove flink name
      create_handle
      handle_count++
      
      If someone now flinks this object again, we'll get a new flink name.
      
      We can close this race by removing the lock dropping and making the
      entire lookup+handle_create sequence atomic. Unfortunately to still be
      able to share the handle_create logic this requires a
      handle_create_tail function which drops the lock - we can't hold the
      object_name_lock while calling into a driver's ->gem_open callback.
      
      Note that for flink fixing this race isn't really important, since
      racing gem_open against gem_close is clearly a userspace bug. And no
      matter how the race ends, we won't leak any references.
      
      But with dma-buf where the userspace dma-buf fd itself is refcounted
      this is a valid sequence and hence we should fix it. Therefore this
      patch here is just a warm-up exercise (and for consistency between
      flink buffer sharing and dma-buf buffer sharing with self-imports).
      
      Also note that this extension of the critical section in gem_open
      protected by dev->object_name_lock only works because it's now a
      mutex: A spinlock would conflict with the potential memory allocation
      in idr_preload().
      
      This is exercises by igt/gem_flink_race/flink_name.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      20228c44
    • Daniel Vetter's avatar
      drm/gem: switch dev->object_name_lock to a mutex · cd4f013f
      Daniel Vetter authored
      I want to wrap the creation of a dma-buf from a gem object in it,
      so that the obj->export_dma_buf cache can be atomically filled in.
      
      Instead of creating a new mutex just for that variable I've figured
      I can reuse the existing dev->object_name_lock, especially since
      the new semantics will exactly mirror the flink obj->name already
      protected by that lock.
      
      v2: idr_preload/idr_preload_end is now an atomic section, so need to
      move the mutex locking outside.
      
      [airlied: fix up conflict with patch to make debugfs use lock]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      cd4f013f
    • Daniel Vetter's avatar
      drm/prime: clarify logic a bit in drm_gem_prime_fd_to_handle · 84341c28
      Daniel Vetter authored
      if (!ret) implies that ret == 0, so no need to clear it again. And
      explicitly check for ret == 0 to indicate that we're checking an errno
      integer.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      84341c28
    • Daniel Vetter's avatar
      drm/prime: shrink critical section protected by prime lock · bdf655de
      Daniel Vetter authored
      When exporting a gem object as a dma-buf the critical section for the
      per-fd prime lock is just the adding (and in case of errors, removing)
      of the handle to the per-fd lookup cache.
      
      So restrict the critical section to just that part of the function.
      
      This simplifies later reordering.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      bdf655de
    • Daniel Vetter's avatar
      drm/prime: use proper pointer in drm_gem_prime_handle_to_fd · 4332bf43
      Daniel Vetter authored
      Part of the function uses the properly-typed dmabuf variable, the
      other an untyped void *buf. Kill the later.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      4332bf43
    • Daniel Vetter's avatar
      drm/gem: make drm_gem_object_handle_unreference_unlocked static · becee2a5
      Daniel Vetter authored
      No one outside of drm should use this, the official interfaces are
      drm_gem_handle_create and drm_gem_handle_delete. The handle refcounting
      is purely an implementation detail of gem.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      becee2a5
    • Daniel Vetter's avatar
      drm/prime: fix error path in drm_gem_prime_fd_to_handle · 730c4ff9
      Daniel Vetter authored
      handle_unreference only clears up the obj->name and the reference,
      but would leave a dangling handle in the idr. The right thing
      to do is to call handle_delete.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      730c4ff9
    • Daniel Vetter's avatar
      drm/gem: fix up flink name create race · a8e11d1c
      Daniel Vetter authored
      This is the 2nd attempt, I've always been a bit dissatisified with the
      tricky nature of the first one:
      
      http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
      
      The issue is that the flink ioctl can race with calling gem_close on
      the last gem handle. In that case we'll end up with a zero handle
      count, but an flink name (and it's corresponding reference). Which
      results in a neat space leak.
      
      In my first attempt I've solved this by rechecking the handle count.
      But fundamentally the issue is that ->handle_count isn't your usual
      refcount - it can be resurrected from 0 among other things.
      
      For those special beasts atomic_t often suggest way more ordering that
      it actually guarantees. To prevent being tricked by those hairy
      semantics take the easy way out and simply protect the handle with the
      existing dev->object_name_lock.
      
      With that change implemented it's dead easy to fix the flink vs. gem
      close reace: When we try to create the name we simply have to check
      whether there's still officially a gem handle around and if not refuse
      to create the flink name. Since the handle count decrement and flink
      name destruction is now also protected by that lock the reace is gone
      and we can't ever leak the flink reference again.
      
      Outside of the drm core only the exynos driver looks at the handle
      count, and tbh I have no idea why (it's just for debug dmesg output
      luckily).
      
      I've considered inlining the drm_gem_object_handle_free, but I plan to
      add more name-like things (like the exported dma_buf) to this scheme,
      so it's clearer to leave the handle freeing in its own function.
      
      This is exercised by the new gem_flink_race i-g-t testcase, which on
      my snb leaks gem objects at a rate of roughly 1k objects/s.
      
      v2: Fix up the error path handling in handle_create and make it more
      robust by simply calling object_handle_unreference.
      
      v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
      retursn 1 for 0. Oops.
      
      v4: Squash in inlining of drm_gem_object_handle_reference as suggested
      by Dave Airlie and add a note that we now have a testcase.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a8e11d1c
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2013-08-09' of... · 9712def2
      Dave Airlie authored
      Merge tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
      
      Daniel writes:
      New pile of stuff for -next:
      - Cleanup of the old crtc helper callbacks, all encoders are now converted
        to the i915 modeset infrastructure.
      - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is
        prep work to eventually get things going for nuclear pageflips where we
        need to adjust watermarks on the fly.
      - More vm/vma patches from Ben. This refactoring isn't yet fully rolled
        out, we miss the execbuf conversion and some of the low-level
        bind/unbind support code.
      - Convert our hdmi infoframe code to use the new common helper functions
        (Damien). This contains some bugfixes for the common infoframe helpers.
      - Some cruft removal from Damien.
      - Various smaller bits&pieces all over, as usual.
      
      * tag 'drm-intel-next-2013-08-09' of git://people.freedesktop.org/~danvet/drm-intel: (105 commits)
        drm/i915: Fix FB WM for HSW
        drm/i915: expose HDMI connectors on port C on BYT
        drm/i915: fix a limit check in hsw_compute_wm_results()
        drm/i915: unbreak i915_gem_object_ggtt_unbind()
        drm/i915: Make intel_set_mode() static
        drm/i915: Remove intel_modeset_disable()
        drm/i915: Make intel_encoder_dpms() static
        drm/i915: Make i915_hangcheck_elapsed() static
        drm/i915: Fix #endif comment
        drm/i915: Remove i915_gem_object_check_coherency()
        drm/i915: Remove stale prototypes
        drm/i915: List objects allocated from stolen memory in debugfs
        drm/i915: Always call intel_update_sprite_watermarks() when disabling a plane
        drm/i915: Pass plane and crtc to intel_update_sprite_watermarks
        drm/i915: Don't try to disable plane if it's already disabled
        drm/i915: Pass crtc to our update/disable_plane hooks
        drm/i915: Split plane watermark parameters into a separate struct
        drm/i915: Pull some watermarks state into a separate structure
        drm/i915: Calculate max watermark levels for ILK+
        drm/i915: Rename hsw_lp_wm_result to intel_wm_level
        ...
      9712def2
    • Lespiau, Damien's avatar
      drm: Make drm_get_platform_dev() static · 66cc8b6b
      Lespiau, Damien authored
      It's only used in drm_platform.c.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      66cc8b6b
    • Lespiau, Damien's avatar
      15f3b9d9
    • Lespiau, Damien's avatar
      drm: Make drm_fb_cma_describe() static · 2c9c52e8
      Lespiau, Damien authored
      This function is only used in drm_fb_cma_helper.c.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2c9c52e8
    • Lespiau, Damien's avatar
      drm: Remove 2 unused defines · a03eb838
      Lespiau, Damien authored
      These were introduced in the very first DRM commit:
      
        commit f453ba04
        Author: Dave Airlie <airlied@redhat.com>
        Date:   Fri Nov 7 14:05:41 2008 -0800
      
            DRM: add mode setting support
      
            Add mode setting support to the DRM layer.
      
      But are unused.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      a03eb838
    • Lespiau, Damien's avatar
      drm: Make drm_mode_remove() static · 86f422d5
      Lespiau, Damien authored
      It's only used in drm_crtc.c.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      86f422d5
    • Lespiau, Damien's avatar
      drm: Remove drm_mode_list_concat() · 67587e86
      Lespiau, Damien authored
      The last user was removed in
      
        commit 575dc34e
        Author: Dave Airlie <airlied@redhat.com>
        Date:   Mon Sep 7 18:43:26 2009 +1000
      
            drm/kms: remove old std mode fallback code.
      
            The new code adds modes in the helper, which makes more sense
            I disliked the non-driver code adding modes.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      67587e86
    • Lespiau, Damien's avatar
      drm: Remove drm_mode_create_dithering_property() · ddecb10c
      Lespiau, Damien authored
      This was last used by nouveau, replaced by a driver-specific property
      in:
      
        commit de691855
        Author: Ben Skeggs <bskeggs@redhat.com>
        Date:   Mon Oct 17 12:23:41 2011 +1000
      
            drm/nouveau: improve dithering properties, and implement proper auto mode
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      ddecb10c
    • Lespiau, Damien's avatar
      drm: Remove stale prototypes · f51607ac
      Lespiau, Damien authored
      A few prototypes have been left in the headers, their function friends
      long gone.
      Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      f51607ac
  7. 19 Aug, 2013 5 commits
    • Daniel Vetter's avatar
      drm: move dev data clearing from drm_setup to lastclose · f336ab76
      Daniel Vetter authored
      We kzalloc this structure, and for real kms devices we should never
      loose track of things really.
      
      But ums/legacy drivers rely on the drm core to clean up a bit of cruft
      between lastclose and firstopen (i.e. when X is being restarted), so
      keep this around. But give it a clear drm_legacy_ prefix and
      conditionalize the code on !DRIVER_MODESET.
      
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      f336ab76
    • Daniel Vetter's avatar
      drm: remove procfs code, take 2 · cb6458f9
      Daniel Vetter authored
      So almost two years ago I've tried to nuke the procfs code already
      once before:
      
      http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
      
      The conclusion was that userspace drivers (specifically libdrm device
      node detection) stopped relying on procfs in 2001. But after some
      digging it turned out that the drmstat tool in libdrm is still using
      those files (but only when certain options are set). So we've decided
      to keep profcs.
      
      But I when I've started to dig around again what exactly this tool
      does I've noticed that it tries to read the "mem", "vm", and "vma"
      files from procfs. Now as far my git history digging shows "mem" never
      did anything useful (at least in the version that first showed up in
      upstream history in 2004) and the file was remove in
      
      commit 955b12de
      Author: Ben Gamari <bgamari@gmail.com>
      Date:   Tue Feb 17 20:08:49 2009 -0500
      
          drm: Convert proc files to seq_file and introduce debugfs
      
      Which means that for over 4 years drmstat has been broken, and no one
      cared. In my opinion that's proof enough that no one is actually using
      drmstat, and so that we can savely nuke the procfs support from drm.
      
      While at it fix up the error case cleanup for debugfs in drm_get_minor.
      
      v2: Fix dates, libdrm stopped relying on procfs for drm node detection
      in 2001.
      
      v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
      Fengguang Wu.
      
      Cc: kbuild test robot <fengguang.wu@intel.com>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      cb6458f9
    • Daniel Vetter's avatar
      drm: don't call ->firstopen for KMS drivers · 7d14bb6b
      Daniel Vetter authored
      It has way too much potential for driver writers to do stupid things
      like delayed hw setup because the load sequence is somehow racy (e.g.
      the imx driver in staging). So don't call it for modesetting drivers,
      which reduces the complexity of the drm core -> driver interface a
      notch.
      
      v2: Don't forget to update DocBook.
      
      v3: Go with Laurent's slightly more elaborate proposal for the DocBook
      update. Add a few words on top of his diff to elaborate a bit on what
      KMS drivers should and shouldn't do in lastclose. There was already a
      paragraph present talking about restoring properties, I've simply
      extended that one.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      7d14bb6b
    • Daniel Vetter's avatar
      drm/vmwgfx: remove ->firstopen callback · 0faa4a87
      Daniel Vetter authored
      So if we survey kms drivers there's a bunch of things they commonly do
      in ->lastclose
      - delayed processing of vga switcheroo requests (i915, nouveau,
        radeon)
      - force-restoring the fbcon (most)
      - resetting a bunch properties to make fbcon work better (omap)
      - disabling all outputs (vmwgfx)
      
      In short besides the semantically important vga switcheroo stuff they
      all try very hard to keep fbcon working in case X dies.
      
      But none of them try to not do this at driver unload time safe for
      vmwgfx, and digging through logs I couldn't find any reason for why
      vmwgfx is special.
      
      Since ->firstopen has lots of potential for abuse with kms drivers
      (like delaying driver setup to pamper over races in the load sequence)
      it's imo very much worth it to remove this logic so that we can
      stop using the ->firstopen callback for kms drivers.
      
      Also module unloading is rather a debug feature and developers should
      know how to restore the display to a sane configuration.
      
      Cc: Jakob Bornecrantz <jakob@vmware.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0faa4a87
    • Daniel Vetter's avatar
      drm/imx: kill firstopen callback · b5dc0d10
      Daniel Vetter authored
      This thing seems to do some kind of delayed setup. Really, real kms
      drivers shouldn't do that at all. Either stuff needs to be dynamically
      hotplugged or the driver setup sequence needs to be fixed.
      
      This patch here just moves the setup at the very end of the driver
      load callback, with the locking adjusted accordingly.
      
      v2: Also move the corresponding put from ->lastclose to ->unload.
      
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      b5dc0d10