1. 08 7月, 2016 12 次提交
  2. 14 6月, 2016 5 次提交
  3. 07 6月, 2016 2 次提交
  4. 02 6月, 2016 1 次提交
  5. 31 5月, 2016 1 次提交
    • L
      vga_switcheroo: Add helper for deferred probing · b00e5334
      Lukas Wunner 提交于
      So far we've got one condition when DRM drivers need to defer probing
      on a dual GPU system and it's coded separately into each of the relevant
      drivers. As suggested by Daniel Vetter, deduplicate that code in the
      drivers and move it to a new vga_switcheroo helper. This yields better
      encapsulation of concepts and lets us add further checks in a central
      place. (The existing check pertains to pre-retina MacBook Pros and an
      additional check is expected to be needed for retinas.)
      
      One might be tempted to check deferred probing conditions in
      vga_switcheroo_register_client(), but this is usually called fairly late
      during driver load. The GPU is fully brought up and ready for switching
      at that point. On boot the ->probe hook is potentially called dozens of
      times until it finally succeeds, and each time we'd repeat bringup and
      teardown of the GPU, lengthening boot time considerably and cluttering
      logfiles. A separate helper is therefore needed which can be called
      right at the beginning of the ->probe hook.
      
      Note that amdgpu currently does not call this helper as the AMD GPUs
      built into MacBook Pros are only supported by radeon so far.
      
      v2: This helper could eventually be used by audio clients as well,
          so rephrase kerneldoc to refer to "client" instead of "GPU"
          and move the single existing check in an if block specific
          to PCI_CLASS_DISPLAY_VGA devices. Move documentation on
          that check from kerneldoc to a comment. (Daniel Vetter)
      
      v3: Mandate in kerneldoc that registration of client shall only
          happen after calling this helper. (Daniel Vetter)
      
      v4: Rebase on 412c8f7d ("drm/radeon: Return -EPROBE_DEFER when
          amdkfd not loaded")
      
      v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are
          matched as well. (Emil Velikov)
      
      v6: The if-condition referring to PCI_BASE_CLASS_DISPLAY may be
          considered a functional change. Move to a separate commit to
          keep this a pure refactoring change. (Emil Velikov, Jani Nikula)
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/575885fd440c2b13c3f19ddf44360cfbbff35f50.1464685538.git.lukas@wunner.de
      b00e5334
  6. 24 5月, 2016 1 次提交
  7. 21 5月, 2016 1 次提交
    • D
      drm: Nuke ->vblank_disable_allowed · fcee5906
      Daniel Vetter 提交于
      This was added in
      
      commit 0a3e67a4
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Tue Sep 30 12:14:26 2008 -0700
      
          drm: Rework vblank-wait handling to allow interrupt reduction.
      
      to stay backwards-compatible with old UMS code that didn't even tell
      the kernel when it did a modeset, so that the kernel could
      save/restore vblank counters. At worst this means vblanks will be
      somewhat funky on a setup that very likely no one still runs.
      
      So let's just nuke it.
      
      Plan B would be to set it unconditionally in drm_vblank_init for kms
      drivers, instead of in each driver separately. So if this patch breaks
      anything please only restore the hunks in drmP.h and drm_irq.c, plus
      add a check for DRIVER_MODESET in drm_vblank_init.
      
      Stumbled over this in a discussion on irc with Chris.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Mark Yao <mark.yao@rock-chips.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Philipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fcee5906
  8. 19 5月, 2016 1 次提交
    • A
      drm: remove unused dev variables · c6740c9c
      Arnd Bergmann 提交于
      After drm_gem_object_lookup() was changed along with all its callers,
      we have several drivers that have unused variables:
      
      drm/armada/armada_crtc.c: In function 'armada_drm_crtc_cursor_set':
      drm/armada/armada_crtc.c:900:21: error: unused variable 'dev' [-Werror=unused-variable]
      drm/nouveau/nouveau_gem.c: In function 'validate_init':
      drm/nouveau/nouveau_gem.c:371:21: error: unused variable 'dev' [-Werror=unused-variable]
      drm/nouveau/nv50_display.c: In function 'nv50_crtc_cursor_set':
      drm/nouveau/nv50_display.c:1308:21: error: unused variable 'dev' [-Werror=unused-variable]
      drm/radeon/radeon_cs.c: In function 'radeon_cs_parser_relocs':
      drm/radeon/radeon_cs.c:77:21: error: unused variable 'ddev' [-Werror=unused-variable]
      
      This fixes all the instances I found with ARM randconfig builds so far.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: a8ad0bd8 ("drm: Remove unused drm_device from drm_gem_object_lookup()")
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1463587653-3035181-6-git-send-email-arnd@arndb.de
      c6740c9c
  9. 17 5月, 2016 1 次提交
  10. 16 5月, 2016 1 次提交
  11. 13 5月, 2016 1 次提交
  12. 05 5月, 2016 11 次提交
  13. 04 5月, 2016 2 次提交