OSDN Git Service
Sean Paul [Sat, 2 Oct 2021 15:45:41 +0000 (11:45 -0400)]
Revert "drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
399190e70816886e2bca1f3f3bc3d9c544af88e7.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-15-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:40 +0000 (11:45 -0400)]
Revert "drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
4c048437ef7adb2d81fe4ddc5c04179126eefcf2.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-14-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:39 +0000 (11:45 -0400)]
Revert "drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
7c5f2eecc21f44fba1b1f13ce09c2533db9d781a.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-13-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:38 +0000 (11:45 -0400)]
Revert "drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
6b92e77156c5adf6606c8ad825c71404417d88af.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-12-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:37 +0000 (11:45 -0400)]
Revert "drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
a2cd9947d99b54c959fce20dc19d81af53f4674e.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-11-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:36 +0000 (11:45 -0400)]
Revert "drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
9b8c437ef1a5f34686fc96b391c201a80f1a2ea0.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-10-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:35 +0000 (11:45 -0400)]
Revert "drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
26723c3d6b930775f9a85521d09655c533a839e6.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-9-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:34 +0000 (11:45 -0400)]
Revert "drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
6067fddc1a4fdf155787ab6182c192e4b360b73c.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-8-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:33 +0000 (11:45 -0400)]
Revert "drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
6aa2daae589b63e8b39fe6f7f2b59fb3063efa05.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-7-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:32 +0000 (11:45 -0400)]
Revert "drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
fd49ef52e2db015ce69ad02bab0702489d141a41.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-6-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:31 +0000 (11:45 -0400)]
Revert "drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
746826bcf8fdf682668ff1c415d6b91dbf5858be.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-5-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:30 +0000 (11:45 -0400)]
Revert "drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2"
This reverts commit
984c9949f1c4cf36c35aa2de5ee2b65c39379fd9.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-4-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:29 +0000 (11:45 -0400)]
Revert "drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
4f9e860e6ad65ff4ea8ce165a1407d96ff1b2211.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-3-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:28 +0000 (11:45 -0400)]
Revert "drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()"
This reverts commit
299f040e855b69c29522cde446777902381a07f5.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-2-sean@poorly.run
Sean Paul [Sat, 2 Oct 2021 15:45:27 +0000 (11:45 -0400)]
Revert "drm: cleanup: remove drm_modeset_(un)lock_all()"
This reverts commit
8d813d1a535c8c7503a5f4061654a73026be8c5e.
This patchset breaks on intel platforms and was previously NACK'd by
Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Fernando Ramos <greenfoo@u92.eu>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-1-sean@poorly.run
Noralf Trønnes [Wed, 29 Sep 2021 19:12:01 +0000 (21:12 +0200)]
drm/gud: Add GUD_PIXEL_FORMAT_RGB888
Add support for the RGB888 pixel format.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-7-noralf@tronnes.org
Noralf Trønnes [Wed, 29 Sep 2021 19:12:00 +0000 (21:12 +0200)]
drm/gud: Add GUD_PIXEL_FORMAT_RGB332
Add support for the RGB332 pixel format.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-6-noralf@tronnes.org
Noralf Trønnes [Wed, 29 Sep 2021 19:11:59 +0000 (21:11 +0200)]
drm/gud: Add GUD_PIXEL_FORMAT_R8
Add support for 8-bit greyscale format.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-5-noralf@tronnes.org
Noralf Trønnes [Wed, 29 Sep 2021 19:11:58 +0000 (21:11 +0200)]
drm/format-helper: Add drm_fb_xrgb8888_to_rgb888()
Add XRGB8888 emulation support for devices that can only do RGB888.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-4-noralf@tronnes.org
Noralf Trønnes [Wed, 29 Sep 2021 19:11:57 +0000 (21:11 +0200)]
drm/format-helper: Add drm_fb_xrgb8888_to_rgb332()
Add XRGB8888 emulation support for devices that can only do RGB332.
v2:
- Support Big Endian (Daniel)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-3-noralf@tronnes.org
Noralf Trønnes [Wed, 29 Sep 2021 19:11:56 +0000 (21:11 +0200)]
drm/fourcc: Add R8 to drm_format_info
Add an entry in drm_format_info for the existing format DRM_FORMAT_R8.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-2-noralf@tronnes.org
Melissa Wen [Thu, 30 Sep 2021 16:19:56 +0000 (17:19 +0100)]
drm/v3d: add multiple syncobjs support
Using the generic extension from the previous patch, a specific multisync
extension enables more than one in/out binary syncobj per job submission.
Arrays of syncobjs are set in struct drm_v3d_multisync, that also cares
of determining the stage for sync (wait deps) according to the job
queue.
v2:
- subclass the generic extension struct (Daniel)
- simplify adding dependency conditions to make understandable (Iago)
v3:
- fix conditions to consider single or multiples in/out_syncs (Iago)
- remove irrelevant comment (Iago)
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ffd8b2e3dd2e0c686db441a0c0a4a0181ff85328.1633016479.git.mwen@igalia.com
Melissa Wen [Thu, 30 Sep 2021 16:18:50 +0000 (17:18 +0100)]
drm/v3d: add generic ioctl extension
Add support to attach generic extensions on job submission. This patch
is third prep work to enable multiple syncobjs on job submission. With
this work, when the job submission interface needs to be extended to
accommodate a new feature, we will use a generic extension struct where
an id determines the data type to be pointed. The first application is
to enable multiples in/out syncobj (next patch), but the base is
already done for future features. Therefore, to attach a new feature,
a specific extension struct should subclass drm_v3d_extension and
update the list of extensions in a job submission.
v2:
- remove redundant elements to subclass struct (Daniel)
v3:
- add comment for v3d_get_extensions
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed53b1cd7e3125b76f18fe3fb995a04393639bc6.1633016479.git.mwen@igalia.com
Melissa Wen [Thu, 30 Sep 2021 16:17:39 +0000 (17:17 +0100)]
drm/v3d: alloc and init job in one shot
Move job memory allocation to v3d_job_init function. This aim to facilitate
error handling in job initialization, since cleanup steps are similar for
all (struct v3d_job)-based types of job involved in a command submission.
To generalize v3d_job_init(), this change takes into account that all job
structs have the first element a struct v3d_job (bin, render, tfu, csd) or
it is a v3d_job itself (clean_job) for pointer casting.
v3:
- explicitly init job as NULL (Iago)
- fix pm failure handling on v3_job_init (Iago)
Suggested-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4d12e07bd334d2cddb51cabd359e99edde595619.1633016479.git.mwen@igalia.com
Melissa Wen [Thu, 30 Sep 2021 16:15:22 +0000 (17:15 +0100)]
drm/v3d: decouple adding job dependencies steps from job init
Prep work to enable a job to wait for more than one syncobj before
start. Also get rid of old checkpatch warnings in the v3d_gem file.
No functional changes.
Signed-off-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/825f5fdd540b0aa2eb57bd5ff93c0777808b108c.1633016479.git.mwen@igalia.com
Rob Clark [Mon, 20 Sep 2021 22:57:59 +0000 (15:57 -0700)]
drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()
For the brave new world of bridges not creating their own connectors, we
need to implement the max clock limitation via bridge->mode_valid()
instead of connector->mode_valid().
v2: Drop unneeded connector->mode_valid()
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920225801.227211-3-robdclark@gmail.com
Fernando Ramos [Fri, 24 Sep 2021 06:43:24 +0000 (08:43 +0200)]
doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup
The previous commits do exactly what this entry in the TODO file asks
for, thus we can remove it now as it is no longer applicable.
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-18-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:23 +0000 (08:43 +0200)]
drm: cleanup: remove drm_modeset_(un)lock_all()
Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no
longer used anywhere and can be removed.
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-17-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:22 +0000 (08:43 +0200)]
drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-16-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:21 +0000 (08:43 +0200)]
drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-15-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:20 +0000 (08:43 +0200)]
drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
While the previous commit was a simple "search and replace", this time I
had to do a bit of refactoring as only one call to
DRM_MODESET_LOCK_ALL_BEGIN() is allowed inside one same function.
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-14-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:19 +0000 (08:43 +0200)]
drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-13-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:18 +0000 (08:43 +0200)]
drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-12-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:17 +0000 (08:43 +0200)]
drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-11-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:16 +0000 (08:43 +0200)]
drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-10-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:15 +0000 (08:43 +0200)]
drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-9-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:14 +0000 (08:43 +0200)]
drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-8-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:13 +0000 (08:43 +0200)]
drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-7-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:12 +0000 (08:43 +0200)]
drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-6-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:11 +0000 (08:43 +0200)]
drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-5-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:10 +0000 (08:43 +0200)]
drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-4-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:09 +0000 (08:43 +0200)]
drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-3-greenfoo@u92.eu
Fernando Ramos [Fri, 24 Sep 2021 06:43:08 +0000 (08:43 +0200)]
drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN()
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos <greenfoo@u92.eu>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-2-greenfoo@u92.eu
Simon Ser [Fri, 3 Sep 2021 13:00:32 +0000 (13:00 +0000)]
drm/lease: allow empty leases
This can be used to create a separate DRM file description, thus
creating a new GEM handle namespace.
My use-case is wlroots. The library splits responsibilities between
separate components: the GBM allocator creates buffers, the GLES2
renderer uses EGL to import them and render to them, the DRM
backend imports the buffers and displays them. wlroots has a
modular architecture, and any of these components can be swapped
and replaced with something else. For instance, the pipeline can
be set up so that the DRM dumb buffer allocator is used instead of
GBM and the Pixman renderer is used instead of GLES2. Library users
can also replace any of these components with their own custom one.
DMA-BUFs are used to pass buffer references across components. We
could use GEM handles instead, but this would result in pain if
multiple GPUs are in use: wlroots copies buffers across GPUs as
needed. Importing a GEM handle created on one GPU into a completely
different GPU will blow up (fail at best, mix unrelated buffers
otherwise).
Everything is fine if all components use Mesa. However, this isn't
always desirable. For instance when running with DRM dumb buffers
and the Pixman software renderer it's unfortunate to depend on GBM
in the DRM backend just to turn DMA-BUFs into FB IDs. GBM loads
Mesa drivers to perform an action which has nothing driver-specific.
Additionally, drivers will fail the import if the 3D engine can't
use the imported buffer, for instance amdgpu will refuse to import
DRM dumb buffers [1]. We might also want to be running with a Vulkan
renderer and a Vulkan allocator in the future, and GBM wouldn't be
welcome in this setup.
To address this, GBM can be side-stepped in the DRM backend, and
can be replaced with drmPrimeFDToHandle calls. However because of
GEM handle reference counting issues, care must be taken to avoid
double-closing the same GEM handle. In particular, it's not
possible to share a DRM FD with GBM or EGL and perform some
drmPrimeFDToHandle calls manually.
So wlroots needs to re-open the DRM FD to create a new GEM handle
namespace. However there's no guarantee that the file-system
permissions will be set up so that the primary FD can be opened
by the compsoitor. On modern systems seatd or logind is a privileged
process responsible for doing this, and other processes aren't
expected to do it. For historical reasons systemd still allows
physically logged in users to open primary DRM nodes, but this
doesn't work on non-systemd setups and it's desirable to lock
them down at some point.
Some might suggest to open the render node instead of re-opening
the primary node. However some systems don't have a render node
at all (e.g. no GPU, or a split render/display SoC).
Solutions to this issue have been discussed in [2]. One solution
would be to open the magic /proc/self/fd/<fd> file, but it's a
Linux-specific hack (wlroots supports BSDs too). Another solution
is to add support for re-opening a DRM primary node to seatd/logind,
but they don't support it now and really haven't been designed for
this (logind would need to grow a completely new API, because it
assumes unique dev_t IDs). Also this seems like pushing down a
kernel limitation to user-space a bit too hard.
Another solution is to allow creating empty DRM leases. The lessee
FD would have its own GEM handle namespace, so wouldn't conflict
wth GBM/EGL. It would have the master bit set, but would be able
to manage zero resources. wlroots doesn't intend to share this FD
with any other process.
All in all IMHO that seems like a pretty reasonable solution to the
issue at hand.
Note, I've discussed with Jonas Ådahl and Mutter plans to adopt a
similar design in the future.
Example usage in wlroots is available at [3]. IGT test available
at [4].
[1]: https://github.com/swaywm/wlroots/issues/2916
[2]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
[3]: https://github.com/swaywm/wlroots/pull/3158
[4]: https://patchwork.freedesktop.org/series/94323/
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Keith Packard <keithp@keithp.com>
Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210903130000.1590-2-contact@emersion.fr
Arnd Bergmann [Mon, 27 Sep 2021 14:28:02 +0000 (16:28 +0200)]
drm: fb_helper: fix CONFIG_FB dependency
With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_alloc_fbi':
(.text+0x10cc): undefined reference to `framebuffer_alloc'
Tighten the dependency so it is only allowed in the case that DRM can
link against FB.
Fixes:
f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
Link: https://lore.kernel.org/all/20210721152211.2706171-1-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927142816.2069269-1-arnd@kernel.org
Christian König [Tue, 15 Jun 2021 11:12:33 +0000 (13:12 +0200)]
dma-buf: fix and rework dma_buf_poll v7
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
makes only sense if you grab the reference first and then check the sequence
values.
Then we should always also wait for the exclusive fence.
It's also good practice to keep the reference around when installing callbacks
to fences you don't own.
And last the whole implementation was unnecessary complex and rather hard to
understand which could lead to probably unexpected behavior of the IOCTL.
Fix all this by reworking the implementation from scratch. Dropping the
whole RCU approach and taking the lock instead.
Only mildly tested and needs a thoughtful review of the code.
Pushing through drm-misc-next to avoid merge conflicts and give the code
another round of testing.
v2: fix the reference counting as well
v3: keep the excl fence handling as is for stable
v4: back to testing all fences, drop RCU
v5: handle in and out separately
v6: add missing clear of events
v7: change coding style as suggested by Michel, drop unused variables
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
CC: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210720131110.88512-1-christian.koenig@amd.com
Fangzhi Zuo [Mon, 27 Sep 2021 19:23:24 +0000 (15:23 -0400)]
drm/dp: Add Additional DP2 Headers
Include FEC, DSC, Link Training related headers.
Change since v2
- Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927192324.5428-1-Jerry.Zuo@amd.com
Maxime Ripard [Tue, 28 Sep 2021 18:13:33 +0000 (20:13 +0200)]
drm/bridge: Add stubs for devm_drm_of_get_bridge when OF is disabled
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://patchwork.freedesktop.org/patch/msgid/20210928181333.1176840-1-maxime@cerno.tech
Matthew Auld [Wed, 29 Sep 2021 13:26:29 +0000 (14:26 +0100)]
drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE
In commit:
commit
667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directly
mappable through TTM(this also extends to userptr). In the next patch we
want to introduce a shmem_tt backend, which should follow all the
existing rules with TTM_PAGE_FLAG_EXTERNAL, since it will need to handle
swapping itself, but with the above mapping restriction lifted.
v2(Christian):
- Don't OR together EXTERNAL and EXTERNAL_MAPPABLE in the definition
of EXTERNAL_MAPPABLE, just leave it the caller to handle this
correctly, otherwise we might encounter subtle issues.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929132629.353541-3-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Wed, 29 Sep 2021 13:26:28 +0000 (14:26 +0100)]
drm/ttm: add some kernel-doc for TTM_TT_FLAG_*
Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist.
v2(Christian):
- Add a note that FLAG_SWAPPED shouldn't need to be touched by drivers.
- Mention what FLAG_POPULATED does.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929132629.353541-2-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Wed, 29 Sep 2021 13:26:27 +0000 (14:26 +0100)]
drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
v2(Christian):
- Rename these to TTM_TT_FLAGS_*
- Fix up all the holes in the flag values
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929132629.353541-1-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 27 Sep 2021 11:41:05 +0000 (12:41 +0100)]
drm/ttm: remove TTM_PAGE_FLAG_NO_RETRY
No longer used it seems.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-4-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 27 Sep 2021 11:41:04 +0000 (12:41 +0100)]
drm/ttm: move ttm_tt_{add, clear}_mapping into amdgpu
Now that setting page->index shouldn't be needed anymore, we are just
left with setting page->mapping, and here it looks like amdgpu is the
only user, where pointing the page->mapping at the dev_mapping is used
to verify that the pages do indeed belong to the device, if userspace
later tries to touch them.
v2(Christian):
- Drop the functions altogether and just inline modifying
the page->mapping
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-3-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 27 Sep 2021 11:41:03 +0000 (12:41 +0100)]
drm/ttm: stop setting page->index for the ttm_tt
In commit:
commit
58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom <thellstrom@vmware.com>
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
we started setting the page->mapping and page->index to point to the
virtual address space, if the pages were faulted with TTM. Apparently
this was needed for core-mm to able to reverse lookup the virtual
address given the struct page, and potentially unmap it from the page
tables. However as pointed out by Thomas, since we are now using
PFN_MAP, instead of say PFN_MIXED, this should no longer be the case.
There was also apparently some usecase in vmwgfx which needed this for
dirty tracking, but that also doesn't appear to be the case anymore, as
pointed out by Thomas.
We still need keep the page->mapping for now, since that is still needed
for different reasons, but we try to address that in the next patch.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-2-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 27 Sep 2021 11:41:02 +0000 (12:41 +0100)]
drm/ttm: stop calling tt_swapin in vm_access
In commit:
commit
09ac4fcb3f255e9225967c75f5893325c116cdbe
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date: Thu Jul 13 17:01:16 2017 -0400
drm/ttm: Implement vm_operations_struct.access v2
we added the vm_access hook, where we also directly call tt_swapin for
some reason. If something is swapped-out then the ttm_tt must also be
unpopulated, and since access_kmap should also call tt_populate, if
needed, then swapping-in will already be handled there.
If anything, calling tt_swapin directly here would likely always fail
since the tt->pages won't yet be populated, or worse since the tt->pages
array is never actually cleared in unpopulate this might lead to a nasty
uaf.
Fixes:
09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-1-matthew.auld@intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:24 +0000 (16:20 -0700)]
drm/virtio: implement context init: advertise feature to userspace
This advertises the context init feature to userspace, along with
a mask of supported capabilities.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-13-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:23 +0000 (16:20 -0700)]
drm/virtio: implement context init: add virtio_gpu_fence_event
Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event
to the DRM file descriptor when a fence on a specific ring is
signaled.
One difference is the event is not exposed via the UAPI -- this is
because host responses are on a shared memory buffer of type
BLOB_MEM_GUEST [this is the common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Nicholas Verne <nverne@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-12-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:22 +0000 (16:20 -0700)]
drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
For the Sommelier guest Wayland proxy, it's desirable for the
DRM fd to be pollable in response to an host compositor event.
This can also be used by the 3D driver to poll events on a CPU
timeline.
This enables the DRM fd associated with a particular 3D context
to be polled independent of KMS events. The parameter
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable
rings.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Nicholas Verne <nverne@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-11-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:21 +0000 (16:20 -0700)]
drm/virtio: implement context init: allocate an array of fence contexts
We don't want fences from different 3D contexts (virgl, gfxstream,
venus) to be on the same timeline. With explicit context creation,
we can specify the number of ring each context wants.
Execbuffer can specify which ring to use.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-10-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:20 +0000 (16:20 -0700)]
drm/virtio: implement context init: stop using drv->context when creating fence
The plumbing is all here to do this. Since we always use the
default fence context when allocating a fence, this makes no
functional difference.
We can't process just the largest fence id anymore, since it's
it's associated with different timelines. It's fine for fence_id
260 to signal before 259. As such, process each fence_id
individually.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-9-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:19 +0000 (16:20 -0700)]
drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to virtio_gpu_fence_alloc
These were defined in the previous commit. We'll need these
parameters when allocating a dma_fence. The use case for this
is multiple synchronizations timelines.
The maximum number of timelines per 3D instance will be 32. Usually,
only 2 are needed -- one for CPU commands, and another for GPU
commands.
As such, we'll need to specify these parameters when allocating a
dma_fence.
vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-8-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:18 +0000 (16:20 -0700)]
drm/virtio: implement context init: track {ring_idx, emit_fence_info} in virtio_gpu_fence
Each fence should be associated with a [fence ID, fence_context,
seqno]. The seqno number is just the fence id.
To get the fence context, we add the ring_idx to the 3D context's
base_fence_ctx. The ring_idx is between 0 and 31, inclusive.
Each 3D context will have it's own base_fence_ctx. The ring_idx will
be emitted to host userspace, when emit_fence_info is true.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-7-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Anthoine Bourgeois [Tue, 21 Sep 2021 23:20:17 +0000 (16:20 -0700)]
drm/virtio: implement context init: support init ioctl
This implements the context initialization ioctl. A list of params
is passed in by userspace, and kernel driver validates them. The
only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID.
If the context has already been initialized, -EEXIST is returned.
This happens after Linux userspace does dumb_create + followed by
opening the Mesa virgl driver with the same virtgpu instance.
However, for most applications, 3D contexts will be explicitly
initialized when the feature is available.
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-6-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Anthoine Bourgeois [Tue, 21 Sep 2021 23:20:16 +0000 (16:20 -0700)]
drm/virtio: implement context init: probe for feature
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT.
Create a new DRM_INFO(..) line since the current one is getting
too long.
Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-5-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:15 +0000 (16:20 -0700)]
drm/virtio: implement context init: track valid capabilities in a mask
The valid capability IDs are between 1 to 63, and defined in the
virtio gpu spec. This is used for error checking the subsequent
patches. We're currently only using 2 capability IDs, so this
should be plenty for the immediate future.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-4-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:14 +0000 (16:20 -0700)]
drm/virtgpu api: create context init feature
This change allows creating contexts of depending on set of
context parameters. The meaning of each of the parameters
is listed below:
1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID
This determines the type of a context based on the capability set
ID. For example, the current capsets:
VIRTIO_GPU_CAPSET_VIRGL
VIRTIO_GPU_CAPSET_VIRGL2
define a Gallium, TGSI based "virgl" context. We only need 1 capset
ID per context type, though virgl has two due a bug that has since
been fixed.
The use case is the "gfxstream" rendering library and "venus"
renderer.
gfxstream doesn't do Gallium/TGSI translation and mostly relies on
auto-generated API streaming. Certain users prefer gfxstream over
virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also
required for Vulkan emulation. The maximum capset ID is 63.
The goal is for guest userspace to choose the optimal context type
depending on the situation/hardware.
2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS
This tells the number of independent command rings that the context
will use. This value may be zero and is inferred to be zero if
VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards
compatibility for virgl, which has one big giant command ring for all
commands.
The maxiumum number of rings is 64. In practice, multi-queue or
multi-ring submission is used for powerful dGPUs and virtio-gpu
may not be the best option in that case (see PCI passthrough or
rendernode forwarding).
3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK
This is a mask of ring indices for which the DRM fd is pollable.
For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask
may be:
[ring idx] | [1 << ring_idx] | final mask
-------------------------------------------
0 1 1
1 2 3
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Acked-by: Nicholas Verne <nverne@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-3-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Gurchetan Singh [Tue, 21 Sep 2021 23:20:13 +0000 (16:20 -0700)]
virtio-gpu api: multiple context types with explicit initialization
This feature allows for each virtio-gpu 3D context to be created
with a "context_init" variable. This variable can specify:
- the type of protocol used by the context via the capset id.
This is useful for differentiating virgl, gfxstream, and venus
protocols by host userspace.
- other things in the future, such as the version of the context.
In addition, each different context needs one or more timelines, so
for example a virgl context's waiting can be independent on a
gfxstream context's waiting.
VIRTIO_GPU_FLAG_INFO_RING_IDX is introduced to specific to tell the
host which per-context command ring (or "hardware queue", distinct
from the virtio-queue) the fence should be associated with.
The new capability sets (gfxstream, venus etc.) are only defined in
the virtio-gpu spec and not defined in the header.
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Lingfeng Yang <lfy@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-2-gurchetansingh@chromium.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
yangcong [Tue, 14 Sep 2021 03:22:51 +0000 (11:22 +0800)]
drm/panel: support for BOE and INX video mode panel
Support for these two panels fits in nicely with the existing
panel-boe-tv101wum-nl6 driver as suggested by Sam [1].
This is an incell IC, TDDI use time division multiplexing.
Init code effect touch sensing.The main things
we needed to handle were:
a) These panels need slightly longer delays in two places. Since these
new delays aren't much longer, let's just unconditionally increase
them for the driver.
b) These panel use video BURST mode
[1] https://lore.kernel.org/r/YSPAseE6WD8dDRuz@ravnborg.org/
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
[dianders: fix whitespace issues reported by dim apply-branch]
[dianders: inx,=>innolux,]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914032252.3770756-4-yangcong5@huaqin.corp-partner.google.com
yangcong [Tue, 14 Sep 2021 03:22:52 +0000 (11:22 +0800)]
dt-bindings: boe, tv101wum-n16: Add compatible for boe tv110c9m-ll3 and inx hj110iz-01a
Add bindings documentation for boe tv110c9m-ll3, inx hj110iz-01a panel.
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
[dianders: inx,=>innolux,]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914032252.3770756-5-yangcong5@huaqin.corp-partner.google.com
yangcong [Tue, 14 Sep 2021 03:22:49 +0000 (11:22 +0800)]
drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail
The auo,b101uan08.3 panel (already supported by this driver) has
a 3.3V rail that needs to be turned on. For previous users of
this panel this voltage was directly output by pmic. On a new
user (the not-yet-upstream sc7180-trogdor-mrbland board) we need
to turn the 3.3V rail on. Add support in the driver for this.
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914032252.3770756-2-yangcong5@huaqin.corp-partner.google.com
yangcong [Tue, 14 Sep 2021 03:22:50 +0000 (11:22 +0800)]
dt-bindings: drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V rail
The auo,b101uan08.3 panel (already supported by this driver) has
a 3.3V rail that needs to be turned on. For previous users of
this panel this voltage was directly output by pmic. On a new
user (the not-yet-upstream sc7180-trogdor-mrbland board) we need
to turn the 3.3V rail on.
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914032252.3770756-3-yangcong5@huaqin.corp-partner.google.com
Maxime Ripard [Tue, 14 Sep 2021 10:17:24 +0000 (12:17 +0200)]
drm/vc4: hdmi: Actually check for the connector status in hotplug
The drm_helper_hpd_irq_event() documentation states that this function
is "useful for drivers which can't or don't track hotplug interrupts for
each connector." and that "Drivers which support hotplug interrupts for
each connector individually and which have a more fine-grained detect
logic should bypass this code and directly call
drm_kms_helper_hotplug_event()". This is thus what we ended-up doing.
However, what this actually means, and is further explained in the
drm_kms_helper_hotplug_event() documentation, is that
drm_kms_helper_hotplug_event() should be called by drivers that can
track the connection status change, and if it has changed we should call
that function.
This underlying expectation we failed to provide is that the caller of
drm_kms_helper_hotplug_event() should call drm_helper_probe_detect() to
probe the new status of the connector.
Since we didn't do it, it meant that even though we were sending the
notification to user-space and the DRM clients that something changed we
never probed or updated our internal connector status ourselves.
This went mostly unnoticed since the detect callback usually doesn't
have any side-effect. Also, if we were using the DRM fbdev emulation
(which is a DRM client), or any user-space application that can deal
with hotplug events, chances are they would react to the hotplug event
by probing the connector status eventually.
However, now that we have to enable the scrambler in detect() if it was
enabled it has a side effect, and an application such as Kodi or
modetest doesn't deal with hotplug events. This resulted with a black
screen when Kodi or modetest was running when a screen was disconnected
and then reconnected, or switched off and on.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-3-maxime@cerno.tech
Maxime Ripard [Tue, 14 Sep 2021 10:17:23 +0000 (12:17 +0200)]
drm/probe-helper: Create a HPD IRQ event helper for a single connector
The drm_helper_hpd_irq_event() function is iterating over all the
connectors when an hotplug event is detected.
During that iteration, it will call each connector detect function and
figure out if its status changed.
Finally, if any connector changed, it will notify the user-space and the
clients that something changed on the DRM device.
This is supposed to be used for drivers that don't have a hotplug
interrupt for individual connectors. However, drivers that can use an
interrupt for a single connector are left in the dust and can either
reimplement the logic used during the iteration for each connector or
use that helper and iterate over all connectors all the time.
Since both are suboptimal, let's create a helper that will only perform
the status detection on a single connector.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-2-maxime@cerno.tech
Maxime Ripard [Tue, 14 Sep 2021 10:17:22 +0000 (12:17 +0200)]
drm/probe-helper: Document drm_helper_hpd_irq_event() return value
The documentation of the drm_helper_hpd_irq_event() function didn't
document the value that function was returning. Add that part as well.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-1-maxime@cerno.tech
Christian König [Thu, 23 Sep 2021 12:47:57 +0000 (14:47 +0200)]
drm/msm: allow compile_test on !ARM
MSM is one of the few drivers which won't even compile
test on !ARM platforms.
Looking into this a bit more it turned out that there is
actually not that much missing to at least let the driver
compile on x86 as well.
So this patch replaces the use of phys_to_page() with the
open coded version and provides a dummy for of_drm_find_bridge().
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924071759.22659-2-christian.koenig@amd.com
Douglas Anderson [Mon, 27 Sep 2021 14:41:22 +0000 (07:41 -0700)]
drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and
not 0, 2, 3) we were getting a kernel doc warning that looked like
this:
include/drm/drm_edid.h:530: warning:
Function parameter or member 'vend_chr_1' not described in 'drm_edid_encode_panel_id'
include/drm/drm_edid.h:530: warning:
Excess function parameter 'vend_chr_3' description in 'drm_edid_encode_panel_id'
Fix it.
Fixes:
7d1be0a09fa6 ("drm/edid: Fix EDID quirk compile error on older compilers")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210927074104.1.Ibf22f2a0b75287a5d636c0570c11498648bf61c6@changeid
Douglas Anderson [Tue, 21 Sep 2021 15:28:01 +0000 (08:28 -0700)]
drm/print: Add deprecation notes to DRM_...() functions
It's hard for someone (like me) who's not following closely to know
what the suggested best practices are for error printing in DRM
drivers. Add some hints to the header file.
In general, my understanding is that:
* When possible we should be using a `struct drm_device` for logging
and recent patches have tried to make it more possible to access a
relevant `struct drm_device` in more places.
* For most cases when we don't have a `struct drm_device`, we no
longer bother with DRM-specific wrappers on the dev_...() functions
or pr_...() functions and just encourage drivers to use the normal
functions.
* For debug-level functions where we might want filtering based on a
category we'll still have DRM-specific wrappers, but we'll only
support passing a `struct drm_device`, not a `struct
device`. Presumably most of the cases where we want the filtering
are messages that happen while the system is in a normal running
state (AKA not during probe time) and we should have a `struct
drm_device` then. If we absolutely can't get a `struct drm_device`
then these functions begrudgingly accept NULL for the `struct
drm_device` and hopefully the awkwardness of having to manually pass
NULL will keep people from doing this unless absolutely necessary.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
Douglas Anderson [Fri, 24 Sep 2021 14:53:21 +0000 (07:53 -0700)]
drm/edid: Fix EDID quirk compile error on older compilers
Apparently some compilers [1] cannot handle doing math on dereferenced
string constants at compile time. This has led to reports [2] of
compile errors like:
In file included from drivers/gpu/drm/drm_edid.c:42:0:
./include/drm/drm_edid.h:525:2: error: initializer element is not constant
((((u32)((vend)[0]) - '@') & 0x1f) << 26 | \
Go back to the syntax I used in v4 of the patch series [3] that added
this code instead of what landed (v5). This syntax is slightly uglier
but should be much more compatible with varied compilers.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18
[2] https://lore.kernel.org/r/874kaabdt5.fsf@intel.com/
[3] https://lore.kernel.org/r/
20210909135838.v4.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid/
Fixes:
d9f91a10c3e8 ("drm/edid: Allow querying/working with the panel ID from the EDID")
Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reported-by: Srikanth Myakam <smyakam@microsoft.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924075317.1.I1e58d74d501613f1fe7585958f451160d11b8a98@changeid
Yang Yingliang [Fri, 24 Sep 2021 09:40:40 +0000 (17:40 +0800)]
drm/gma500: Fix wrong pointer passed to PTR_ERR()
PTR_ERR() should access the value just tested by IS_ERR(),
otherwise the wrong error code will be returned.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes:
c2f17e60cbe1 ("drm/gma500: Embed struct drm_device in struct drm_psb_private")
Reported-by: Hulk Robot <hulkci@huawei.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210924094040.3631675-1-yangyingliang@huawei.com
Maxime Ripard [Fri, 10 Sep 2021 10:11:58 +0000 (12:11 +0200)]
drm/mipi-dsi: Create devm device attachment
MIPI-DSI devices need to call mipi_dsi_attach() when their probe is done
to attach against their host.
However, at removal or when an error occurs, that attachment needs to be
undone through a call to mipi_dsi_detach().
Let's create a device-managed variant of the attachment function that
will automatically detach the device at unbind.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-5-maxime@cerno.tech
Maxime Ripard [Fri, 10 Sep 2021 10:11:57 +0000 (12:11 +0200)]
drm/mipi-dsi: Create devm device registration
Devices that take their data through the MIPI-DSI bus but are controlled
through a secondary bus like I2C have to register a secondary device on
the MIPI-DSI bus through the mipi_dsi_device_register_full() function.
At removal or when an error occurs, that device needs to be removed
through a call to mipi_dsi_device_unregister().
Let's create a device-managed variant of the registration function that
will automatically unregister the device at unbind.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-4-maxime@cerno.tech
Maxime Ripard [Fri, 10 Sep 2021 10:11:56 +0000 (12:11 +0200)]
drm/bridge: Document the probe issue with MIPI-DSI bridges
Interactions between bridges, panels, MIPI-DSI host and the component
framework are not trivial and can lead to probing issues when
implementing a display driver. Let's document the various cases we need
too consider, and the solution to support all the cases.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-3-maxime@cerno.tech
Maxime Ripard [Fri, 10 Sep 2021 10:11:55 +0000 (12:11 +0200)]
drm/bridge: Add documentation sections
The bridge documentation overview is quite packed already, and we'll add
some more documentation that isn't part of an overview at all.
Let's add some sections to the documentation to separate each bits.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210910101218.1632297-2-maxime@cerno.tech
Philip Chen [Tue, 21 Sep 2021 18:06:17 +0000 (11:06 -0700)]
drm/bridge: parade-ps8640: Add support for AUX channel
Implement the first version of AUX support, which will be useful as
we expand the driver to support varied use cases.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
[dianders: whitespace fixes reported by dim apply-branch]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921110556.v6.2.I1d6ea362dc76efa77cca2b46253d31b7651eaf17@changeid
Philip Chen [Tue, 21 Sep 2021 18:06:16 +0000 (11:06 -0700)]
drm/bridge: parade-ps8640: Use regmap APIs
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs,
which will simplify the future update on ps8640 driver.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
[dianders: whitespace fixes reported by dim apply-branch]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921110556.v6.1.I2351df94f18d5d8debc22d4d100f36fac560409a@changeid
Thomas Zimmermann [Mon, 20 Sep 2021 14:10:51 +0000 (16:10 +0200)]
drm/gma500: Managed device release
Set up a clean-up action to automatically release device resources
during driver shutdown. Remove manual release code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-6-tzimmermann@suse.de
Thomas Zimmermann [Mon, 20 Sep 2021 14:10:50 +0000 (16:10 +0200)]
drm/gma500: Remove dev_priv branch from unload function
The value of dev_priv in psb_driver_unload() is always non-zero. Remove
the respective test.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-5-tzimmermann@suse.de
Thomas Zimmermann [Mon, 20 Sep 2021 14:10:49 +0000 (16:10 +0200)]
drm/gma500: Embed struct drm_device in struct drm_psb_private
Embed struct drm_device in struct drm_psb_private. Replace the use
of dev_private by an upcast operation. Switch to managed release of
struct drm_psb_private.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-4-tzimmermann@suse.de
Thomas Zimmermann [Mon, 20 Sep 2021 14:10:48 +0000 (16:10 +0200)]
drm/gma500: Disable PCI device during shutdown
Use managed disablement of PCI devices via pcim_device_enable().
Disables the PCI device and simplifies error rollback in probe
function.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-3-tzimmermann@suse.de
Thomas Zimmermann [Mon, 20 Sep 2021 14:10:47 +0000 (16:10 +0200)]
drm/gma500: Replace references to dev_private with helper function
Replace most references to struct drm_device.dev_private with the new
helper function to_drm_psb_private(). The only references left are in
assignments and the helper itself.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210920141051.30988-2-tzimmermann@suse.de
Thomas Zimmermann [Thu, 16 Sep 2021 18:16:01 +0000 (20:16 +0200)]
drm/vboxvideo: Use managed interfaces for framebuffer write combining
Replace arch_phys_wc_add() with the rsp managed function. Allows for
removing the cleanup code for memory management
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-6-tzimmermann@suse.de
Thomas Zimmermann [Thu, 16 Sep 2021 18:16:00 +0000 (20:16 +0200)]
drm/mgag200: Use managed interfaces for framebuffer write combining
Replace arch_phys_wc_add() and arch_io_reserve_memtype_wc() with
the rsp managed functions. Allows for removing the cleanup code
for memory management
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-5-tzimmermann@suse.de
Thomas Zimmermann [Thu, 16 Sep 2021 18:15:59 +0000 (20:15 +0200)]
drm/ast: Use managed interfaces for framebuffer write combining
Replace arch_phys_wc_add() and arch_io_reserve_memtype_wc() with
the rsp managed functions. Allows for removing the cleanup code
for memory management
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-4-tzimmermann@suse.de
Thomas Zimmermann [Thu, 16 Sep 2021 18:15:58 +0000 (20:15 +0200)]
lib: devres: Add managed arch_io_reserve_memtype_wc()
Add devm_arch_io_reserve_memtype_wc() as managed wrapper around
arch_io_reserve_memtype_wc(). Useful for several graphics drivers
that set framebuffer memory to write combining.
v2:
* fix typo in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-3-tzimmermann@suse.de
Thomas Zimmermann [Thu, 16 Sep 2021 18:15:57 +0000 (20:15 +0200)]
lib: devres: Add managed arch_phys_wc_add()
Add devm_arch_phys_wc_add() as managed wrapper around arch_phys_wc_add().
Useful for several graphics drivers that set framebuffer memory to write
combining.
v2:
* fix typo in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210916181601.9146-2-tzimmermann@suse.de
Ville Syrjälä [Wed, 15 Sep 2021 14:23:00 +0000 (17:23 +0300)]
drm: Fix scaling_mode docs
Fix the bad copy-pasta in the scaling_mode docs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210915142300.15631-1-ville.syrjala@linux.intel.com
Reviewed-by: Simon Ser <contact@emersion.fr>
Maxime Ripard [Fri, 17 Sep 2021 18:09:25 +0000 (20:09 +0200)]
drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c
By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge()
introduces a circular dependency between the modules drm (where
devm_drm_of_get_bridge() ends up) and drm_kms_helper (where
devm_drm_panel_bridge_add() is).
Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus
drm_kms_helper.
Fixes:
87ea95808d53 ("drm/bridge: Add a function to abstract away panels")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210917180925.2602266-1-maxime@cerno.tech
Lukas Bulwahn [Tue, 21 Sep 2021 12:21:46 +0000 (14:21 +0200)]
MAINTAINERS: fix typo in DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
Commit
ebd8cbf1fb96 ("drm/panel: s6d27a1: Add driver for Samsung S6D27A1
display panel") introduces a new section DRM DRIVER FOR SAMSUNG S6D27A1
PANELS with a minor typo in one of its file entries.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: driver/gpu/drm/panel/panel-samsung-s6d27a1.c
So, repair the entry and make get_maintainer.pl happy.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921122146.13132-1-lukas.bulwahn@gmail.com
Souptick Joarder [Mon, 7 Jun 2021 18:48:36 +0000 (00:18 +0530)]
drm/rockchip: remove of_match_ptr() from analogix dp driver
Kernel test robot throws below warning when CONFIG_OF
is not set.
>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:457:34:
warning: unused variable 'rockchip_dp_dt_ids' [-Wunused-const-variable]
static const struct of_device_id rockchip_dp_dt_ids[] = {
Fixed it by removing of_match_ptr().
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210607184836.3502-1-jrdr.linux@gmail.com
Souptick Joarder [Mon, 7 Jun 2021 19:08:00 +0000 (00:38 +0530)]
drm/rockchip: remove of_match_ptr() from vop_driver_dt_match
kernel test robot throws warning when CONFIG_OF not set.
>> drivers/gpu/drm/rockchip/rockchip_vop_reg.c:1038:34:
warning: unused variable 'vop_driver_dt_match' [-Wunused-const-variable]
static const struct of_device_id vop_driver_dt_match[] = {
Fixed it by removing of_match_ptr().
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210607190800.3992-1-jrdr.linux@gmail.com