1. 22 7月, 2014 1 次提交
  2. 10 6月, 2014 2 次提交
  3. 02 6月, 2014 1 次提交
  4. 31 5月, 2014 1 次提交
    • D
      drm/radeon: Resume fbcon last · 18ee37a4
      Daniel Vetter 提交于
      So a few people complained that
      
      commit 177cf92d
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Apr 1 22:14:59 2014 +0200
      
          drm/crtc-helpers: fix dpms on logic
      
      which was merged into 3.15-rc1, broke resume on radeons. Strangely git
      bisect lead everyone to
      
      commit 25f397a4
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Jul 19 18:57:11 2013 +0200
      
          drm/crtc-helper: explicit DPMS on after modeset
      
      which was merged long ago and actually part of 3.14.
      
      Digging deeper I've noticed (again) that the call to
      drm_helper_resume_force_mode in the radeon resume handlers was a no-op
      previously because everything gets shut down on suspend. radeon does
      this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
      But with 177c we now force the dpms state to ON, so suddenly
      resume_force_mode actually forced the crtcs back on.
      
      This is the intention of the change after all, the problem is that
      radeon resumes the fbdev console layer _before_ restoring the display,
      through calling fb_set_suspend. And fbcon does an immediate ->set_par,
      which in turn causes the same forced mode restore to happen.
      
      Two concurrent modeset operations didn't lead to happiness. Fix this
      by delaying the fbcon resume until the end of the readeon resum
      functions.
      
      v2: Fix up a bit of the spelling fail.
      
      References: https://lkml.org/lkml/2014/5/29/1043
      References: https://lkml.org/lkml/2014/5/2/388
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751Tested-by: NKen Moffat <zarniwhoop@ntlworld.com>
      Cc: Alex Deucher <alexdeucher@gmail.com>
      Cc: Ken Moffat <zarniwhoop@ntlworld.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@gmail.com>
      18ee37a4
  5. 06 5月, 2014 1 次提交
  6. 23 4月, 2014 1 次提交
    • D
      drm: Rip out totally bogus vga_switcheroo->can_switch locking · fc8fd40e
      Daniel Vetter 提交于
      So I just wanted to add a new field to struct drm_device and
      accidentally stumbled over something. According to comments
      dev->open_count is protected by dev->count_lock, but that's totally
      not the case. It's protected by drm_global_mutex.
      
      Unfortunately the vga switcheroo callbacks took this comment at face
      value. The problem is that we can't just take the drm_global_mutex
      because:
      - It would lead to a locking inversion with the driver load/unload
        paths.
      - It wouldn't actually protect anything, for that we'd need to wrap
        the entire vga switcheroo code in the drm_global_mutex. And I'm not
        sure whether that would actually solve anything.
      
      What we probably want is a try_to_grab_switcheroo reference kind of
      thing which is used in the driver's ->open callback. Then we could
      move all that ->can_switch madness into the vga switcheroo core where
      it really belongs.
      
      But since that would amount to real work take the easy way out and
      just add a comment. It's definitely not going to make anything worse
      since doing switcheroo state changes while restarting X just isn't
      recommended. Even though the delayed switching code does exactly that.
      
      v2:
      - Simplify the ->can_switch implementations more (Thierry)
      - Fix comment about the dev->open_count locking (Thierry)
      
      Cc: Thierry Reding <treding@nvidia.com>
      Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (v1)
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fc8fd40e
  7. 17 4月, 2014 1 次提交
  8. 03 4月, 2014 1 次提交
  9. 02 4月, 2014 1 次提交
    • M
      drm: Replace crtc fb with primary plane fb (v3) · f4510a27
      Matt Roper 提交于
      Now that CRTC's have a primary plane, there's no need to track the
      framebuffer in the CRTC.  Replace all references to the CRTC fb with the
      primary plane's fb.
      
      This patch was generated by the Coccinelle semantic patching tool using
      the following rules:
      
              @@ struct drm_crtc C; @@
              -   (C).fb
              +   C.primary->fb
      
              @@ struct drm_crtc *C; @@
              -   (C)->fb
              +   C->primary->fb
      
      v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
          moved to a subsequent patch.
      
      v2: Fixup several lingering crtc->fb instances that were missed in the
          first patch iteration.  [Rob Clark]
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      f4510a27
  10. 07 3月, 2014 1 次提交
  11. 03 3月, 2014 2 次提交
  12. 28 2月, 2014 1 次提交
  13. 09 1月, 2014 1 次提交
  14. 08 1月, 2014 1 次提交
  15. 25 12月, 2013 1 次提交
    • A
      drm/radeon/pm: move pm handling into the asic specific code · 6c7bccea
      Alex Deucher 提交于
      We need more control over the ordering of dpm init with
      respect to the rest of the asic.  Specifically, the SMC
      has to be initialized before the rlc and cg/pg.  The pm
      code currently initializes late in the driver, but we need
      it to happen much earlier so move pm handling into the asic
      specific callbacks.
      
      This makes dpm more reliable and makes clockgating work
      properly on CIK parts and should help on SI parts as well.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6c7bccea
  16. 16 11月, 2013 1 次提交
  17. 09 11月, 2013 1 次提交
  18. 02 11月, 2013 3 次提交
  19. 23 9月, 2013 1 次提交
  20. 11 9月, 2013 2 次提交
  21. 31 8月, 2013 1 次提交
  22. 29 8月, 2013 1 次提交
    • D
      gpu/vga_switcheroo: add driver control power feature. (v3) · 0d69704a
      Dave Airlie 提交于
      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: NDave Airlie <airlied@redhat.com>
      0d69704a
  23. 08 8月, 2013 2 次提交
  24. 27 6月, 2013 1 次提交
  25. 26 6月, 2013 2 次提交
  26. 12 6月, 2013 1 次提交
  27. 30 5月, 2013 1 次提交
  28. 29 5月, 2013 2 次提交
  29. 20 5月, 2013 1 次提交
  30. 02 5月, 2013 1 次提交
  31. 24 4月, 2013 1 次提交
  32. 09 4月, 2013 1 次提交