Skip to content
  1. Oct 31, 2013
  2. Oct 09, 2013
  3. Sep 03, 2013
  4. Sep 01, 2013
  5. Aug 29, 2013
  6. Aug 27, 2013
  7. Aug 23, 2013
    • Wolfram Sang's avatar
      i2c: move OF helpers into the core · 687b81d0
      Wolfram Sang authored
      
      
      I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
      that it is much cleaner to have this in the core. This also removes a
      circular dependency between the helpers and the core, and so we can
      finally register child nodes in the core instead of doing this manually
      in each driver. So, fix the drivers and documentation, too.
      
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      687b81d0
  8. Aug 19, 2013
    • David Rheinsberg's avatar
      drm/host1x: stop casting VMA offsets to 32bit · 2bc7b0ca
      David Rheinsberg authored
      
      
      VMA offsets are 64bit so do not cast them to "unsigned int". Also remove
      the (now useless) offset-retrieval helper. The VMA manager provides simple
      enough helpers.
      
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: "Terje Bergström" <tbergstrom@nvidia.com>
      Cc: Arto Merilainen <amerilainen@nvidia.com>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2bc7b0ca
    • Daniel Vetter's avatar
      drm: remove FASYNC support · b0e898ac
      Daniel Vetter authored
      
      
      So I've stumbled over drm_fasync and wondered what it does. Digging
      that up is quite a story.
      
      First I've had to read up on what this does and ended up being rather
      bewildered why peopled loved signals so much back in the days that
      they've created SIGIO just for that ...
      
      Then I wondered how this ever works, and what that strange "No-op."
      comment right above it should mean. After all calling the core fasync
      helper is pretty obviously not a noop. After reading through the
      kernels FASYNC implementation I've noticed that signals are only sent
      out to the processes attached with FASYNC by calling kill_fasync.
      
      No merged drm driver has ever done that.
      
      After more digging I've found out that the only driver that ever used
      this is the so called GAMMA driver. I've frankly never heard of such a
      gpu brand ever before. Now FASYNC seems to not have been the only bad
      thing with that driver, since Dave Airlie removed it from the drm
      driver with prejudice:
      
      commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
      Author: Dave Airlie <airlied@linux.ie>
      Date:   Sun Aug 29 12:04:35 2004 +0000
      
          Drop GAMMA DRM from a great height ...
      
      Long story short, the drm fasync support seems to be doing absolutely
      nothing. And the only user of it was never merged into the upstream
      kernel. And we don't need any fops->fasync callback since the fcntl
      implementation in the kernel already implements the noop case
      correctly.
      
      So stop this particular cargo-cult and rip it all out.
      
      v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
      (somehow I've missed that one in staging). Also drop the reference in
      the drm DocBook. ARM compile-fail reported by Rob Clark.
      
      v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
      patch here.
      
      v4: Actually git add ... tsk.
      
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.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>
      b0e898ac
  9. Aug 07, 2013
  10. Aug 06, 2013
  11. Jul 25, 2013
    • David Rheinsberg's avatar
      drm/gem: convert to new unified vma manager · 0de23977
      David Rheinsberg authored
      
      
      Use the new vma manager instead of the old hashtable. Also convert all
      drivers to use the new convenience helpers. This drops all the
      (map_list.hash.key << PAGE_SHIFT) non-sense.
      
      Locking and access-management is exactly the same as before with an
      additional lock inside of the vma-manager, which strictly wouldn't be
      needed for gem.
      
      v2:
       - rebase on drm-next
       - init nodes via drm_vma_node_reset() in drm_gem.c
      v3:
       - fix tegra
      v4:
       - remove duplicate if (drm_vma_node_has_offset()) checks
       - inline now trivial drm_vma_node_offset_addr() calls
      v5:
       - skip node-reset on gem-init due to kzalloc()
       - do not allow mapping gem-objects with offsets (backwards compat)
       - remove unneccessary casts
      
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: default avatarPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@gmail.com>
      0de23977
  12. Jun 22, 2013
  13. May 25, 2013
  14. May 18, 2013
  15. Apr 22, 2013
Loading