Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 11月, 2019 1 次提交
  3. 07 11月, 2019 1 次提交
  5. 28 10月, 2019 1 次提交
  7. 23 8月, 2019 2 次提交
  9. 11 6月, 2019 2 次提交
  11. 04 6月, 2019 1 次提交
    • N
      drm/fb-helper: Remove drm_fb_helper_crtc · d81294af
      由 Noralf Trønnes 提交于 
      struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
use that directly instead and attach it as a modeset array onto
drm_client_dev. drm_fb_helper will use this array to store its modesets
which means it will always initialize a drm_client, but it will not
register the client (callbacks) unless it's the generic fbdev emulation.

Code will later be moved to drm_client, so add code there in a new file
drm_client_modeset.c with MIT license to match drm_fb_helper.c.

The modeset connector array size is hardcoded for the cloned case to avoid
having to pass in a value from the driver. A value of 8 is chosen to err
on the safe side. This means that the max connector argument for
drm_fb_helper_init() and drm_fb_helper_fbdev_setup() isn't used anymore,
a todo entry for this is added.

In pan_display_atomic() restore_fbdev_mode_force() is used instead of
restore_fbdev_mode_atomic() because that one will later become internal
to drm_client_modeset.

Locking order:
1. drm_fb_helper->lock
2. drm_master_internal_acquire
3. drm_client_dev->modeset_mutex

v6: Improve commit message (Sam Ravnborg)

v3:
- Use full drm_client_init/release for the modesets (Daniel Vetter)
- drm_client_for_each_modeset: use lockdep_assert_held (Daniel Vetter)
- Hook up to Documentation/gpu/drm-client.rst (Daniel Vetter)

v2:
- Add modesets array to drm_client (Daniel Vetter)
- Use a new file for the modeset code (Daniel Vetter)
- File has to be MIT licensed (Emmanuel Vadot)
- Add copyrights from drm_fb_helper.c
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531140117.37751-3-noralf@tronnes.org
      d81294af
  13. 14 5月, 2019 2 次提交
  15. 11 4月, 2019 1 次提交
  17. 28 3月, 2019 1 次提交
  19. 27 3月, 2019 2 次提交
  21. 07 3月, 2019 1 次提交
  23. 08 9月, 2018 1 次提交
  25. 04 9月, 2018 1 次提交
  27. 10 7月, 2018 2 次提交
  29. 20 12月, 2017 3 次提交
  31. 05 12月, 2017 1 次提交
  33. 01 11月, 2017 1 次提交
  35. 07 8月, 2017 1 次提交
  37. 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
  39. 06 7月, 2017 1 次提交
  41. 02 3月, 2017 1 次提交
  43. 08 2月, 2017 1 次提交
  45. 03 2月, 2017 2 次提交
  47. 09 1月, 2017 1 次提交
  49. 30 12月, 2016 1 次提交
  51. 14 11月, 2016 1 次提交
  53. 10 10月, 2016 1 次提交
  55. 04 10月, 2016 1 次提交
  57. 19 9月, 2016 1 次提交
  59. 29 8月, 2016 1 次提交
    • A
      drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y · 749cc6f7
      由 Arnd Bergmann 提交于 
      When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
in which some DRM drivers are built-in, but the framebuffer core is a
loadable module. This results in a link error, such as:

drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers'
drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers'
drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers'
Makefile:969: recipe for target 'vmlinux' failed

This changes the compile-time check to IS_REACHABLE, which means we end up
not calling remove_conflicting_framebuffers() in the configuration, which
seems good enough, as we know that no framebuffer driver is loaded by the
time that the built-in DRM driver calls remove_conflicting_framebuffers.

We could alternatively avoid the link error by forcing CONFIG_FB to not
be a module in this case, but that wouldn't change anything at runtime,
and just make the already convoluted set of dependencies worse here.

I could not find out what happens if the fbdev driver gets loaded as
a module after the DRM driver is already initialized, but that is a case
that can happen with or without this patch.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 0a3bfe29 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers")
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829123428.3260105-1-arnd@arndb.de
Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com
      749cc6f7
  61. 24 8月, 2016 1 次提交
  63. 23 8月, 2016 1 次提交