Skip to content

GitLab

Switch branch/tag
  1. 24 May, 2022 1 commit
  3. 25 Apr, 2022 1 commit
    • Thomas Zimmermann's avatar
      drm/display: Introduce a DRM display-helper module · 1e0f6642
      Thomas Zimmermann authored 
      
Replace the DP-helper module with a display-helper module. The
support for DisplayPort becomes an internal option that drivers
have to select. Update all related Kconfig and Makefile rules.

Besides the existing code for DisplayPort, the new module will
contain helpers for other video-output standards, such as HDMI.
Drivers will have to select their required video-output helpers.

Linking all display-related code into a single module avoids the
proliferation of small kernel modules.

The module parameters drm_dp_cec_unregister_delay, dp_aux_i2c_speed_khz,
and dp_aux_i2c_transfer_size are moving from the drm_dp_helper namespace
to drm_display_helper.

v2:
	* mention module parameters in commit message (Javier)
	* distiguish between display module and DP support in Kconfig
	* update Makefile rules for DP helpers
	* move Kconfig rules into separate file under display/
Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-4-tzimmermann@suse.de
      1e0f6642
  5. 05 Apr, 2022 1 commit
  7. 17 Mar, 2022 1 commit
    • Thomas Zimmermann's avatar
      drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS · 3c338405
      Thomas Zimmermann authored 
      
Fix a number of undefined references to drm_kms_helper.ko in
drm_dp_helper.ko:

  arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_duplicate_state':
  drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to `__drm_atomic_helper_private_obj_duplicate_state'
  arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_delayed_destroy_work':
  drm_dp_mst_topology.c:(.text+0x370c): undefined reference to `drm_kms_helper_hotplug_event'
  arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_up_req_work':
  drm_dp_mst_topology.c:(.text+0x7938): undefined reference to `drm_kms_helper_hotplug_event'
  arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_link_probe_work':
  drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to `drm_kms_helper_hotplug_event'

This happens if panel-edp.ko has been configured with

  DRM_PANEL_EDP=y
  DRM_DP_HELPER=y
  DRM_KMS_HELPER=m

which builds DP helpers into the kernel and KMS helpers sa a module.
Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem.

To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't
make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge
drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers
cannot be selected directly by the user, config symbols should avoid
depending on it anyway.
Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
Fixes: 3755d35e

 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP")
Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
Tested-by: default avatarBrian Masney <bmasney@redhat.com>
Reported-by: default avatarkernel test robot <lkp@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Linux Kernel Functional Testing <lkft@linaro.org>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/478296/
      3c338405
  9. 12 Mar, 2022 1 commit
  11. 20 Feb, 2022 1 commit
  13. 04 Feb, 2022 1 commit
  15. 30 Nov, 2021 1 commit
  17. 17 Oct, 2021 3 commits
  19. 15 Oct, 2021 1 commit
  21. 14 Oct, 2021 1 commit
  23. 10 Oct, 2021 1 commit
  25. 09 Oct, 2021 2 commits
  27. 20 Sep, 2021 1 commit
    • Douglas Anderson's avatar
      drm/panel-edp: Split eDP panels out of panel-simple · 5f04e7ce
      Douglas Anderson authored 
      
The panel-simple driver handles way too much. Let's start trying to
get a handle on it by splitting out the eDP panels. This patch does
this:

1. Start by copying simple-panel verbatim over to a new driver,
   simple-panel-edp.
2. Rename "panel_simple" to "panel_edp" in the new driver.
3. Keep only panels marked with `DRM_MODE_CONNECTOR_eDP` in the new
   driver. Remove those panels from the old driver.
4. Remove all recent "DP AUX bus" stuff from the old driver. The DP
   AUX bus is only possible on DP panels.
5. Remove all DSI / MIPI related functions from the new driver.
6. Remove bus_format / bus_flags from eDP driver. These things don't
   seem to make any sense for eDP panels so let's stop filling in made
   up stuff.

In the end we end up with a bunch of duplicated code for now. Future
patches will try to address _some_ of this duplicated code though some
of it will be unavoidable.

NOTE: This may not actually move all eDP panels over to the new driver
since not all panels were properly marked with
`DRM_MODE_CONNECTOR_eDP`. A future patch will attempt to move wayward
panels I could identify but even so there may be some missed.
Suggested-by: default avatarSam Ravnborg <sam@ravnborg.org>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914132020.v5.7.I0a2f75bb822d17ce06f5b147734764eeb0c3e3df@changeid
      5f04e7ce
  29. 13 Aug, 2021 1 commit
  31. 05 Aug, 2021 1 commit
  33. 31 Jul, 2021 1 commit
  35. 17 Jul, 2021 1 commit
  37. 14 Jul, 2021 1 commit
  39. 14 Jun, 2021 1 commit
  41. 11 Jun, 2021 1 commit
  43. 10 Jun, 2021 1 commit
  45. 20 Apr, 2021 1 commit
    • Douglas Anderson's avatar
      drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare · 3235b0f2
      Douglas Anderson authored 
      
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.

The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):

1. When userspace requests EDID / the panel modes (through an ioctl),
   we power on the panel just enough to read the EDID and then power
   it off.
2. Userspace then turns the panel on.

There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.

Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.

A few notes:
- It seems the existing unprepare() and prepare() are defined to be
  no-ops if called extra times. We'll preserve that behavior but may
  try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
  absolutely relying on the unprepare() to happen instantly that
  simply won't be the case anymore. I'm not aware of anyone relying on
  that behavior, but if there is someone then we'll need to figure out
  how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
  "PM". From memory this is a legit thing to assume these days and we
  don't have to find some fallback to keep working if someone wants to
  build their system without "PM".
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
      3235b0f2
  47. 15 Dec, 2020 1 commit
  49. 07 Dec, 2020 1 commit
  51. 17 Nov, 2020 1 commit
  53. 14 Nov, 2020 1 commit
  55. 19 Oct, 2020 1 commit
  57. 15 Oct, 2020 1 commit
  59. 04 Sep, 2020 2 commits
  61. 18 Aug, 2020 1 commit
  63. 01 Jul, 2020 1 commit
  65. 07 May, 2020 1 commit
  67. 06 May, 2020 1 commit
  69. 08 Apr, 2020 1 commit
  71. 06 Mar, 2020 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7