1. 25 9月, 2018 1 次提交
  2. 11 9月, 2018 1 次提交
    • D
      drm/fb: Stop leaking physical address · 6be8f3bd
      Daniel Vetter 提交于
      For buffer sharing, use dma-buf instead. We can't set smem_start to 0
      unconditionally since that's used by the fbdev mmap default
      implementation. And we have plenty of userspace which would like to
      keep that working.
      
      This might break legit userspace - if it does we need to look at a
      case-by-cases basis how to handle that. Worst case I expect overrides
      for only specific drivers, since anything remotely modern should be
      using dma-buf/prime now (which is about 7 years old now for DRM
      drivers).
      
      This issue was uncovered because Noralf's rework to implement a
      generic fb_probe also implements it's own fb_mmap callback. Which
      means smem_start didn't have to be set anymore, which blew up some
      blob in userspace rather badly.
      Acked-by: NSean Paul <seanpaul@chromium.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: David Airlie <airlied@linux.ie>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180822085405.10787-4-daniel.vetter@ffwll.ch
      6be8f3bd
  3. 10 9月, 2018 1 次提交
  4. 10 7月, 2018 2 次提交
  5. 05 7月, 2018 2 次提交
  6. 12 6月, 2018 1 次提交
  7. 29 5月, 2018 1 次提交
  8. 11 5月, 2018 1 次提交
  9. 16 3月, 2018 1 次提交
  10. 20 12月, 2017 4 次提交
  11. 07 12月, 2017 1 次提交
  12. 05 12月, 2017 1 次提交
  13. 29 11月, 2017 1 次提交
  14. 23 11月, 2017 1 次提交
  15. 01 11月, 2017 3 次提交
  16. 14 10月, 2017 1 次提交
  17. 02 9月, 2017 1 次提交
  18. 07 8月, 2017 1 次提交
  19. 04 8月, 2017 1 次提交
  20. 03 8月, 2017 1 次提交
  21. 26 7月, 2017 1 次提交
    • D
      drm/fb-helper: Support deferred setup · ca91a275
      Daniel Vetter 提交于
      FB helper code falls back to a 1024x768 mode if no outputs are connected
      or don't report back any modes upon initialization. This can be annoying
      because outputs that are added to FB helper later on can't be used with
      FB helper if they don't support a matching mode.
      
      The fallback is in place because VGA connectors can happen to report an
      unknown connection status even when they are in fact connected.
      
      Some drivers have custom solutions in place to defer FB helper setup
      until at least one output is connected. But the logic behind these
      solutions is always the same and there is nothing driver-specific about
      it, so a better alterative is to fix the FB helper core and add support
      for all drivers automatically.
      
      This patch adds support for deferred FB helper setup. It checks all the
      connectors for their connection status, and if all of them report to be
      disconnected marks the FB helper as needing deferred setup. Whet setup
      is deferred, the FB helper core will automatically retry setup after a
      hotplug event, and it will keep trying until it succeeds.
      
      v2: Rebase onto my entirely reworked fbdev helper locking. One big
      difference is that this version again drops&reacquires the fbdev lock
      (which is now fb_helper->lock, but before this patch series it was
      mode_config->mutex), because register_framebuffer must be able to
      recurse back into fbdev helper code for the initial screen setup.
      
      v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
      return, I've fumbled that in the deferred setup case (Liviu).
      
      v4: I was blind, redo this all. __drm_fb_helper_initial_config
      shouldn't need to reacquire fb_helper->lock, that just confuses
      callers. I myself got confused by kernel_fb_helper_lock and somehow
      thought it's the same as fb_helper->lock. Tsk.
      
      Also simplify the logic a bit (we don't need two functions to probe
      connectors), we can stick much closer to the existing code. And update
      some comments I've spotted that are outdated.
      
      v5: Don't pass -EAGAIN to drivers, it's just an internal error code
      (Liviu).
      
      v6: Add _and_unlock suffix to clarify locking (Maarten)
      
      Cc: Liviu Dudau <liviu@dudau.co.uk>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thierry Reding <treding@nvidia.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@intel.com>
      Reviewed-by: NLiviu Dudau <liviu@dudau.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ca91a275
  22. 14 7月, 2017 1 次提交
  23. 06 7月, 2017 11 次提交