1. 06 2月, 2014 1 次提交
  2. 30 1月, 2014 1 次提交
  3. 20 1月, 2014 1 次提交
  4. 09 1月, 2014 1 次提交
  5. 24 12月, 2013 1 次提交
  6. 18 12月, 2013 1 次提交
  7. 13 12月, 2013 1 次提交
  8. 18 11月, 2013 1 次提交
  9. 06 11月, 2013 1 次提交
  10. 02 11月, 2013 3 次提交
  11. 19 10月, 2013 1 次提交
    • A
      drm/radeon: rework audio option · 108dc8e8
      Alex Deucher 提交于
      In 3.12 I changed audio to be enabled by default,
      but you still had to turn it on via xrandr.  This
      was confusing to users so change it to minic the
      previous behavior:
      
      - audio option is set to -1 (auto) by default which is
        the current 3.12 behavior (audio is enabled but requires
        xrandr to turn it on).
      - if audio = 1, the audio is enabled without needing
        to mess with xrandr (previous behavior)
      - audio = 0 disables audio
      
      It retains the new feature of allowing the user to enable
      audio on the fly with xrandr, but turns audio on
      automatically if radeon.audio=1 is set which is what
      most users expect.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      108dc8e8
  12. 09 10月, 2013 1 次提交
    • D
      drm: kill ->gem_init_object() and friends · 16eb5f43
      David Herrmann 提交于
      All drivers embed gem-objects into their own buffer objects. There is no
      reason to keep drm_gem_object_alloc(), gem->driver_private and
      ->gem_init_object() anymore.
      
      New drivers are highly encouraged to do the same. There is no benefit in
      allocating gem-objects separately.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      16eb5f43
  13. 11 9月, 2013 1 次提交
  14. 02 9月, 2013 1 次提交
  15. 31 8月, 2013 1 次提交
  16. 19 8月, 2013 3 次提交
    • D
      drm: rip out drm_core_has_MTRR checks · 28185647
      Daniel Vetter 提交于
      The new arch_phys_wc_add/del functions do the right thing both with
      and without MTRR support in the kernel. So we can drop these
      additional checks.
      
      David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
      it's now unused, which spurred me to do a bit a better audit of the
      affected drivers. David helped a lot in that. Quoting our mail
      discussion:
      
      On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
      > On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
      >> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
      >>>> -#if __OS_HAS_MTRR
      >>>> -static inline int drm_core_has_MTRR(struct drm_device *dev)
      >>>> -{
      >>>> -       return drm_core_check_feature(dev, DRIVER_USE_MTRR);
      >>>> -}
      >>>> -#else
      >>>> -#define drm_core_has_MTRR(dev) (0)
      >>>> -#endif
      >>>> -
      >>>
      >>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
      >>> it in .driver_features). Any reason to keep it around?
      >>
      >> Yeah, I guess we could rip things out. Which will also force me to
      >> properly audit drivers for the eventual behaviour change this could
      >> entail (in case there's an x86 driver which did not ask for an mtrr,
      >> but iirc there isn't).
      >
      > david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
      > test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
      > fi ; done
      > drivers/gpu/drm/exynos
      > drivers/gpu/drm/gma500
      > drivers/gpu/drm/i2c
      > drivers/gpu/drm/nouveau
      > drivers/gpu/drm/omapdrm
      > drivers/gpu/drm/qxl
      > drivers/gpu/drm/rcar-du
      > drivers/gpu/drm/shmobile
      > drivers/gpu/drm/tilcdc
      > drivers/gpu/drm/ttm
      > drivers/gpu/drm/udl
      > drivers/gpu/drm/vmwgfx
      > david@david-mb ~/dev/kernel/linux $
      >
      > So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
      > But I cannot tell whether they break if we call arch_phys_wc_add/del,
      > anyway. At least nouveau seemed to work here, but it doesn't use AGP
      > or drm_bufs, I guess.
      
      Cool, thanks a lot for stitching together the list of drivers to look
      at. So for real KMS drivers it's the drives responsibility to add an
      mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
      already. Somehow the savage driver also ends up doing that, I have no
      idea why.
      
      Note that gma500 as a pure KMS driver doesn't need MTRR setup since
      the platforms that it supports all support PAT. So no MTRRs needed to
      get wc iomappings.
      
      The mtrr support in the drm core is all for legacy mappings of garts,
      framebuffers and registers. All legacy drivers set the USE_MTRR flag,
      so we're good there.
      
      All in all I think we can really just ditch this
      
      /endquote
      
      v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann
      
      v3: Rebase on top of David Herrmann's agp setup/cleanup changes.
      
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      28185647
    • D
      drm: remove FASYNC support · b0e898ac
      Daniel Vetter 提交于
      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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      b0e898ac
    • D
      drm/radeon: kill firstopen callback for kms driver · d8ed1688
      Daniel Vetter 提交于
      Again, it does nothing.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d8ed1688
  17. 07 8月, 2013 2 次提交
  18. 23 7月, 2013 2 次提交
  19. 18 7月, 2013 1 次提交
  20. 28 6月, 2013 1 次提交
  21. 27 6月, 2013 2 次提交
  22. 17 5月, 2013 1 次提交
  23. 11 4月, 2013 2 次提交
  24. 09 4月, 2013 1 次提交
  25. 08 3月, 2013 1 次提交
  26. 08 2月, 2013 1 次提交
    • A
      drm/radeon: use prime helpers · 1e6d17a5
      Aaron Plattner 提交于
      Simplify the Radeon prime implementation by using the default behavior provided
      by drm_gem_prime_import and drm_gem_prime_export.
      
      v2:
      - Rename functions to radeon_gem_prime_get_sg_table and
        radeon_gem_prime_import_sg_table.
      - Delete the now-unused vmapping_count variable.
      Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      1e6d17a5
  27. 01 2月, 2013 1 次提交
  28. 15 1月, 2013 1 次提交
  29. 04 1月, 2013 1 次提交
    • G
      Drivers: gpu: remove __dev* attributes. · 56550d94
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, and __devexit
      from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56550d94
  30. 20 12月, 2012 1 次提交
  31. 14 12月, 2012 2 次提交