OSDN Git Service
Ville Syrjälä [Tue, 28 Feb 2023 21:36:10 +0000 (23:36 +0200)]
drm/edid: Fix csync detailed mode parsing
Remove the bogus csync check and replace it with something that:
- triggers for all forms of csync, not just the basic analog variant
- actually populates the mode csync flags so that drivers can
decide what to do with the mode
Originally the code tried to outright reject csync, but that
apparently broke some bogus LCD monitor that claimed to have
a detailed mode that uses analog csync, despite also claiming
the monitor only support separate sync:
https://bugzilla.redhat.com/show_bug.cgi?id=540024
Potentially that monitor should just be quirked or something.
Anyways, what we are dealing with now is some kind of funny i915
JSL machine with eDP where the panel claims to support a sensible
60Hz separate sync mode, and a 50Hz mode with bipolar analog
csync. The 50Hz mode does not work so we want to not use it.
Easiest way is to just correctly flag it as csync and the driver
will reject it.
TODO: or should we just reject any form of csync (or at least
the analog variants) for digital display interfaces?
v2: Grab digital csync polarity from hsync polarity bit (Jani)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230228213610.26283-1-ville.syrjala@linux.intel.com
Thomas Zimmermann [Tue, 21 Feb 2023 15:57:45 +0000 (16:57 +0100)]
drm/ast: Rename to_ast_private() to to_ast_device()
The helper to_ast_private() now upcasts to struct ast_device. Rename
it accordingly. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-5-tzimmermann@suse.de
Thomas Zimmermann [Tue, 21 Feb 2023 15:57:44 +0000 (16:57 +0100)]
drm/ast: Rename struct ast_private to struct ast_device
The data structure struct ast_private represents an AST device. Its
name comes from the time when it was allocated and stored separately
in struct drm_device.dev_private. The DRM device is now embedded, so
rename struct ast_private to struct ast_device.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-4-tzimmermann@suse.de
Thomas Zimmermann [Tue, 21 Feb 2023 15:57:43 +0000 (16:57 +0100)]
drm/ast: Rework definition of I/O read and write helpers
Ast defines a number of I/O helpers for accessing hardware. Only 4 of
the many generated functions are actually used. Replace the respective
generator macros with those 4 functions. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-3-tzimmermann@suse.de
Thomas Zimmermann [Tue, 21 Feb 2023 15:57:42 +0000 (16:57 +0100)]
drm/ast: Remove little-endianism from I/O helpers
Replace one call to ast_io_write16() with two calls to ast_io_write8()
in ast_set_index_reg(). The combined 16-bit-wide write of an index
register and the corresponding data register only works on little-
endian systems. Write both registers independent from each other.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230221155745.27484-2-tzimmermann@suse.de
Maíra Canal [Thu, 2 Feb 2023 11:19:44 +0000 (08:19 -0300)]
drm/vc4: replace obj lookup steps with drm_gem_objects_lookup
As vc4_cl_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
replace the open-coded implementation in vc4 to simply use the DRM function.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: André Almeida <andrealmeid@igalia.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202111943.111757-3-mcanal@igalia.com
Maíra Canal [Thu, 2 Feb 2023 11:19:43 +0000 (08:19 -0300)]
drm/vc4: replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
The array of BOs that are lookup at the start of exec doesn't need
to be instantiated as drm_gem_dma_object, as it doesn't benefit
from its attributes. So, simplify the code by replacing the array of
drm_gem_dma_object for an array of drm_gem_object in the struct
vc4_exec_info.
Suggested-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: André Almeida <andrealmeid@igalia.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202111943.111757-2-mcanal@igalia.com
Thomas Zimmermann [Tue, 28 Feb 2023 15:26:12 +0000 (16:26 +0100)]
Revert "drm/shmem-helper: Switch to reservation lock"
This reverts commit
67b7836d4458790f1261e31fe0ce3250989784f0.
The locking appears incomplete. A caller of SHMEM helper's pin
function never acquires the dma-buf reservation lock. So we get
WARNING: CPU: 3 PID: 967 at drivers/gpu/drm/drm_gem_shmem_helper.c:243 drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper]
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230228152612.19971-1-tzimmermann@suse.de
Harry Wentland [Fri, 13 Jan 2023 16:24:09 +0000 (11:24 -0500)]
drm/connector: print max_requested_bpc in state debugfs
This is useful to understand the bpc defaults and
support of a driver.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton <joshua@froggi.es>
Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-3-harry.wentland@amd.com
Harry Wentland [Fri, 13 Jan 2023 16:24:08 +0000 (11:24 -0500)]
drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
The EDID of an HDR display defines EOTFs that are supported
by the display and can be set in the HDR metadata infoframe.
Userspace is expected to read the EDID and set an appropriate
HDR_OUTPUT_METADATA.
In drm_parse_hdr_metadata_block the kernel reads the supported
EOTFs from the EDID and stores them in the
drm_connector->hdr_sink_metadata. While doing so it also
filters the EOTFs to the EOTFs the kernel knows about.
When an HDR_OUTPUT_METADATA is set it then checks to
make sure the EOTF is a supported EOTF. In cases where
the kernel doesn't know about a new EOTF this check will
fail, even if the EDID advertises support.
Since it is expected that userspace reads the EDID to understand
what the display supports it doesn't make sense for DRM to block
an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
understand.
This comes with the added benefit of future-proofing metadata
support. If the spec defines a new EOTF there is no need to
update DRM and an compositor can immediately make use of it.
Bug: https://gitlab.freedesktop.org/wayland/weston/-/issues/609
v2: Distinguish EOTFs defind in kernel and ones defined
in EDID in the commit description (Pekka)
v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved
to drm_hdmi_helper.c
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Sebastian Wick <sebastian.wick@redhat.com>
Cc: Vitaly.Prosyak@amd.com
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joshua Ashton <joshua@froggi.es>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-By: Joshua Ashton <joshua@froggi.es>
Link: https://patchwork.freedesktop.org/patch/msgid/20230113162428.33874-2-harry.wentland@amd.com
Dom Cobley [Fri, 27 Jan 2023 15:40:52 +0000 (16:40 +0100)]
drm/probe-helper: Cancel previous job before starting new one
Currently we schedule a call to output_poll_execute from
drm_kms_helper_poll_enable for 10s in future. Later we try to replace
that in drm_helper_probe_single_connector_modes with a 0s schedule with
delayed_event set.
But as there is already a job in the queue this fails, and the immediate
job we wanted with delayed_event set doesn't occur until 10s later.
And that call acts as if connector state has changed, reprobing modes.
This has a side effect of waking up a display that has been blanked.
Make sure we cancel the old job before submitting the immediate one.
Fixes:
162b6a57ac50 ("drm/probe-helper: don't lose hotplug event")
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
[Maxime: Switched to mod_delayed_work]
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127154052.452524-1-maxime@cerno.tech
Dmitry Osipenko [Mon, 21 Mar 2022 00:35:41 +0000 (03:35 +0300)]
drm/shmem-helper: Switch to reservation lock
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/all/20230108210445.3948344-8-dmitry.osipenko@collabora.com/
Dmitry Osipenko [Wed, 4 May 2022 23:06:00 +0000 (02:06 +0300)]
drm/shmem-helper: Don't use vmap_use_count for dma-bufs
DMA-buf core has its own refcounting of vmaps, use it instead of drm-shmem
counting. This change prepares drm-shmem for addition of memory shrinker
support where drm-shmem will use a single dma-buf reservation lock for
all operations performed over dma-bufs.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/all/20230108210445.3948344-7-dmitry.osipenko@collabora.com/
Dmitry Osipenko [Wed, 16 Nov 2022 20:56:33 +0000 (23:56 +0300)]
drm/shmem-helper: Switch to use drm_* debug helpers
Ease debugging of a multi-GPU system by using drm_WARN_*() and
drm_dbg_kms() helpers that print out DRM device name corresponding
to shmem GEM.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/all/20230108210445.3948344-6-dmitry.osipenko@collabora.com/
Dmitry Osipenko [Fri, 18 Nov 2022 16:13:43 +0000 (19:13 +0300)]
drm/shmem-helper: Put booleans in the end of struct drm_gem_shmem_object
Group all 1-bit boolean members of struct drm_gem_shmem_object in the end
of the structure, allowing compiler to pack data better and making code to
look more consistent.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/all/20230108210445.3948344-5-dmitry.osipenko@collabora.com/
Dmitry Osipenko [Wed, 16 Nov 2022 14:07:50 +0000 (17:07 +0300)]
drm/gem: Add evict() callback to drm_gem_object_funcs
Add new common evict() callback to drm_gem_object_funcs and corresponding
drm_gem_object_evict() helper. This is a first step on a way to providing
common GEM-shrinker API for DRM drivers.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/all/20230108210445.3948344-4-dmitry.osipenko@collabora.com/
Xu Panda [Wed, 7 Dec 2022 01:13:16 +0000 (09:13 +0800)]
drm/virtio: use strscpy() to instead of strncpy()
The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL terminated strings.
Signed-off-by: Xu Panda <xu.panda@zte.com.cn>
Signed-off-by: Yang Yang <yang.yang29@zte.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/202212070913161959936@zte.com.cn
Jani Nikula [Fri, 17 Feb 2023 10:46:27 +0000 (12:46 +0200)]
drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0
Currently we only parse the Tiled Display Topology Data Block for
DisplayID structure version 1.2, but not 2.0. The contents seem to be
the same for both, so expand the parsing to structure version 2.0.
Note that DisplayID spec version is not the same as DisplayID structure
version; DisplayID 1.3 uses structure version 1.2, and DisplayID 2.0-2.1
use structure version 2.0. Lovely.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217104627.1360015-1-jani.nikula@intel.com
Jani Nikula [Thu, 16 Feb 2023 20:45:01 +0000 (22:45 +0200)]
drm/edid: update non-desktop use also from DisplayID
Use the DisplayID 2.0 primary use case information to deduce whether
this is a head-mounted display, and should not be used for desktop.
Cc: Iaroslav Boliukin <iam@lach.pw>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # HTC VIVE Pro 2
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/de75b2edddd7d30216e4dd5699a064dc737688f5.1676580180.git.jani.nikula@intel.com
Jani Nikula [Thu, 16 Feb 2023 20:45:00 +0000 (22:45 +0200)]
drm/displayid: provide access to DisplayID version and primary use case
The DisplayID structure version and primary use case are stored in the
DisplayID Base Section. We should be checking them in a number of places
when parsing the DisplayID blocks. Currently, we completely ignore the
primary use case, and just look at the block tags without cross-checking
against structure version.
Store the version and primary use case in the DisplayID iterator, and
provide accessors to them. In general, the information is needed when
iterating the blocks, and this is a convenient place to both store and
retrieve the information during parsing.
Promote using accessors rather than users poking at the iterator
directly.
Cc: Iaroslav Boliukin <iam@lach.pw>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ad8a35c109f97ffe115e6b18e4a132b592f11089.1676580180.git.jani.nikula@intel.com
Jani Nikula [Thu, 16 Feb 2023 20:44:59 +0000 (22:44 +0200)]
drm/displayid: return struct displayid_header from validate_displayid()
Avoid figuring out the header pointer multiple times.
Cc: Iaroslav Boliukin <iam@lach.pw>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e840c744d165608a41db5a5e2bd4b0205783c697.1676580180.git.jani.nikula@intel.com
Jani Nikula [Thu, 16 Feb 2023 20:44:58 +0000 (22:44 +0200)]
drm/displayid: add displayid_get_header() and check bounds better
Add a helper to get a pointer to struct displayid_header. To be
pedantic, add buffer overflow checks to not touch the base if that
itself would overflow.
Cc: Iaroslav Boliukin <iam@lach.pw>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4a03b3a5132642d3cdb6d4c2641422955a917292.1676580180.git.jani.nikula@intel.com
Maíra Canal [Thu, 9 Feb 2023 12:44:48 +0000 (09:44 -0300)]
drm/v3d: Use drm_sched_job_add_syncobj_dependency()
As v3d_job_add_deps() performs the same steps as
drm_sched_job_add_syncobj_dependency(), replace the open-coded
implementation in v3d in order to simply use the DRM function.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209124447.467867-6-mcanal@igalia.com
Maíra Canal [Thu, 9 Feb 2023 12:44:47 +0000 (09:44 -0300)]
drm/panfrost: Use drm_sched_job_add_syncobj_dependency()
As panfrost_copy_in_sync() performs the same steps as
drm_sched_job_add_syncobj_dependency(), replace the open-coded
implementation in Panfrost in order to simply use the DRM function.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209124447.467867-5-mcanal@igalia.com
Maíra Canal [Thu, 9 Feb 2023 12:44:44 +0000 (09:44 -0300)]
drm/sched: Create wrapper to add a syncobj dependency to job
In order to add a syncobj's fence as a dependency to a job, it is
necessary to call drm_syncobj_find_fence() to find the fence and then
add the dependency with drm_sched_job_add_dependency(). So, wrap these
steps in one single function, drm_sched_job_add_syncobj_dependency().
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209124447.467867-2-mcanal@igalia.com
Matthew Auld [Wed, 8 Feb 2023 14:53:19 +0000 (14:53 +0000)]
drm/radeon: handle NULL bo->resource in move callback
The ttm bo now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for
radeon. It looks like this will just null-ptr-deref in
radeon_bo_move(), if bo->resource is NULL.
Fix this by calling move_null().
Fixes:
180253782038 ("drm/ttm: stop allocating dummy resources during BO creation")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208145319.397235-4-matthew.auld@intel.com
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Wed, 8 Feb 2023 14:53:17 +0000 (14:53 +0000)]
drm/qxl: handle NULL bo->resource in move callback
The ttm bo now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for qxl.
It looks like this will just null-ptr-deref in qxl_bo_move(), if
bo->resource is NULL.
Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM,
otherwise do the multi-hop sequence to ensure can safely call into
ttm_bo_move_memcpy(), since it might also need to clear the memory.
This should give the same behaviour as before.
Fixes:
180253782038 ("drm/ttm: stop allocating dummy resources during BO creation")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208145319.397235-2-matthew.auld@intel.com
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Wed, 8 Feb 2023 14:53:16 +0000 (14:53 +0000)]
drm/gem-vram: handle NULL bo->resource in move callback
The ttm BO now initially has NULL bo->resource, and leaves the driver
the handle that. However it looks like we forgot to handle that for
ttm_bo_move_memcpy() users, like with vram-gem, since it just silently
returns zero. This seems to then trigger warnings like:
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_gem_vram_helper.c:255 drm_gem_vram_offset (??:?)
Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM,
otherwise do the multi-hop sequence to ensure can safely call into
ttm_bo_move_memcpy(), since it might also need to clear the memory.
This should give the same behaviour as before.
While we are here let's also treat calling ttm_bo_move_memcpy() with
NULL bo->resource as programmer error, where expectation is that upper
layers should now handle it.
Fixes:
180253782038 ("drm/ttm: stop allocating dummy resources during BO creation")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208145319.397235-1-matthew.auld@intel.com
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Jiri Slaby (SUSE) [Mon, 31 Oct 2022 11:42:29 +0000 (12:42 +0100)]
drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototype
gcc-13 warns about mismatching types for enums. That revealed switched
arguments of nv50_wndw_new_():
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of 'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)'
It can be barely visible, but the declaration says about the parameters
in the middle:
enum nv50_disp_interlock_type,
u32 interlock_data,
u32 heads,
While the definition states differently:
u32 heads,
enum nv50_disp_interlock_type interlock_type,
u32 interlock_data,
Unify/fix the declaration to match the definition.
Fixes:
53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel interlocks")
Cc: Martin Liska <mliska@suse.cz>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirislaby@kernel.org
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:07 +0000 (16:41 +0100)]
drm/tidss: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for tidss hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-7-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:06 +0000 (16:41 +0100)]
drm/tidss: Remove return values from dispc_plane_{setup, enable}()
Calls to dispc_plane_setup() and dispc_plane_enable() cannot fail.
Remove the return value.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-6-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:05 +0000 (16:41 +0100)]
drm/mgag200: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for mgag200 hardware via atomic_enable.
Atomic helpers invoke this callback only when the plane becomes
active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-5-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:04 +0000 (16:41 +0100)]
drm/mgag200: Remove disable handling from atomic_update
The primary plane has the atomic_disable helper set, so atomic_update
won't be called if the plane gets disabled. Remove the respective branch
from the helper.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-4-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:03 +0000 (16:41 +0100)]
drm/ast: Implement struct drm_plane_helper_funcs.atomic_enable
Enable the primary plane for ast hardware via atomic_enable. Atomic
helpers invoke this callback only when the plane becomes active.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-3-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 15:41:02 +0000 (16:41 +0100)]
drm/atomic-helper: Add atomic_enable plane-helper callback
Add atomic_enable to struct drm_plane_helper_funcs. It enables a
plane independently from updating the plane's content. As such, it is
the inverse of the atomic_disable plane helper. Useful for hardware
where plane enable state is independent from plane content.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209154107.30680-2-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:09 +0000 (14:55 +0100)]
drm: Fix comment on mode parsing
Do not claim that there's a default mode in the video= option parser.
if no option string has been given, the parser does nothing.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-12-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:08 +0000 (14:55 +0100)]
drm: Include <video/cmdline.h> for mode parsing
Include <video/cmdline.h> in drm_connector.c to get video_get_options()
and avoid the dependency on <linux/fb.h>. The replaced function
fb_get_options() is just a tiny wrapper around video_get_opions(). No
functional changes.
Include <linux/property.h> to get fwnode_handle_put(), which had been
provided via <linux/fb.h>.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-11-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:07 +0000 (14:55 +0100)]
driver/ps3: Include <video/cmdline.h> for mode parsing
Include <video/cmdline.h> in ps3av.c to get video_get_options() and
avoid the dependency on <linux/fb.h>. The replaced function
fb_get_options() is just a tiny wrapper around video_get_opions(). No
functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-10-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:06 +0000 (14:55 +0100)]
fbdev: Handle video= parameter in video/cmdline.c
Handle the command-line parameter video= in video/cmdline.c. Implement
the fbdev helper fb_get_options() on top. Will allows to handle the
kernel parameter in DRM without fbdev dependencies.
Note that __video_get_options() has the meaning of its return value
inverted compared to fb_get_options(). The new helper returns true if
the adapter has been enabled, and false otherwise.
There is the ofonly parameter, which disables output for non-OF-based
framebuffers. It is only for offb and looks like a workaround. The actual
purpose it not clear to me. Use 'video=off' or 'nomodeset' instead.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-9-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:05 +0000 (14:55 +0100)]
fbdev: Move option-string lookup into helper
Move the lookup of the option string into an internal helper. No
functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-8-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:04 +0000 (14:55 +0100)]
fbdev: Unexport fb_mode_option
There are no external users of fb_mode_option. Unexport the variable
and declare it static.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-7-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:03 +0000 (14:55 +0100)]
fbdev: Read video= option with fb_get_option() in modedb
Get the kernel's global video= parameter with fb_get_option(). Done
to unexport the internal fbdev state fb_mode_config. No functional
changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-6-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:02 +0000 (14:55 +0100)]
drivers/ps3: Read video= option with fb_get_option()
Get the kernel's global video= parameter with fb_get_option(). Done
to unexport the internal fbdev state fb_mode_config. No functional
changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Geoff Levand <geoff@infradead.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-5-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:01 +0000 (14:55 +0100)]
fbdev: Support NULL for name in option-string lookup
Ignore the per-driver video options if no driver name has been
specified to fb_get_option(). Return the global options in this
case.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-4-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:55:00 +0000 (14:55 +0100)]
fbdev: Transfer video= option strings to caller; clarify ownership
In fb_get_options(), always duplicate the returned option string and
transfer ownership of the memory to the function's caller.
Until now, only the global option string got duplicated and transferred
to the caller; the per-driver options were owned by fb_get_options().
In the end, it was impossible for the function's caller to detect if
it had to release the string's memory buffer. Hence, all calling drivers
leak the memory buffer. The leaks have existed ever since, but drivers
only call fb_get_option() once as part of module initialization. So the
amount of leaked memory is not significant.
Fix the semantics of fb_get_option() by unconditionally transferring
ownership of the memory buffer to the caller. Later patches can resolve
the memory leaks in the fbdev drivers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-3-tzimmermann@suse.de
Thomas Zimmermann [Thu, 9 Feb 2023 13:54:59 +0000 (14:54 +0100)]
fbdev: Fix contact info in fb_cmdline.c
Fix Daniel's email address. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-2-tzimmermann@suse.de
Simon Ser [Fri, 17 Feb 2023 16:22:04 +0000 (16:22 +0000)]
drm: document DRM_IOCTL_PRIME_HANDLE_TO_FD and PRIME_FD_TO_HANDLE
v2: mention caps, note that the IOCTLs might fail, document that
user-space needs a data structure to keep track of the
handles (Daniel V.)
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217162151.59996-2-contact@emersion.fr
Simon Ser [Fri, 17 Feb 2023 16:22:01 +0000 (16:22 +0000)]
drm: document expectations for GETFB2 handles
There are two important details missing from the docs:
- If the memory object backing the FB already has a GEM handle,
it's not re-used, a new one is generated.
- Aliased planes will return the same GEM handle.
v2: document how user-space can obtain DMA-BUF FDs without leaking
handles (Pekka)
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217162151.59996-1-contact@emersion.fr
Thomas Weißschuh [Fri, 17 Feb 2023 03:13:22 +0000 (03:13 +0000)]
dma-buf: make kobj_type structure constant
Since commit
ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definition to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230217-kobj_type-dma-buf-v1-1-b84a3616522c@weissschuh.net
Simon Ser [Thu, 16 Feb 2023 13:09:45 +0000 (13:09 +0000)]
drm: document DRM_IOCTL_GEM_CLOSE
This is a bit tricky, because of the ref'counting considerations.
See also [1] for more discussion about this topic. Since this is
kernel docs, I've decided to elaborate a bit less on the user-space
details.
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216130934.156541-2-contact@emersion.fr
Maxime Ripard [Thu, 26 Jan 2023 17:05:49 +0000 (18:05 +0100)]
Revert "drm/vc4: hdmi: Enforce the minimum rate at runtime_resume"
This reverts commit
ae71ab585c819f83aec84f91eb01157a90552ef2.
Commit
ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at
runtime_resume") was introduced to work around an issue partly due to
the clk-bcm2835 driver on the RaspberryPi0-3.
Since we're not using that driver for our HDMI clocks, we can now revert
it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-4-d646ff6fb842@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 26 Jan 2023 17:05:48 +0000 (18:05 +0100)]
Revert "drm/vc4: hdmi: Fix HSM clock too low on Pi4"
This reverts commit
3bc6a37f59f21a8bfaf74d0975b2eb0b2d52a065.
Commit
3bc6a37f59f2 ("drm/vc4: hdmi: Fix HSM clock too low on Pi4") was
introduced to work around an issue partly due to the clk-bcm2835 driver
on the RaspberryPi0-3.
Since we're not using that driver for our HDMI clocks, we can now revert
that inelegant solution.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-3-d646ff6fb842@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 26 Jan 2023 17:05:47 +0000 (18:05 +0100)]
drm/vc4: hdmi: Enable power domain before setting minimum
On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835
driver, but on the Pi4 it was provided by the firmware through the
clk-raspberrypi driver.
The clk-bcm2835 driver registers the HSM clock using the
CLK_SET_RATE_GATE flag that prevents any modification to the rate while
the clock is active.
This meant that we needed to call clk_set_min_rate() before our call to
pm_runtime_resume_and_get() since our runtime_resume implementation
needs to enable the HSM clock for the HDMI controller registers to be
functional.
However, the HSM clock is part of the HDMI power domain which might not
be powered prior to the pm_runtime_resume_and_get() call, so we could
end up changing the rate of the HSM clock while its power domain was
disabled.
We recently changed the backing driver for the RaspberryPi0-3 to
clk-raspberrypi though, which doesn't have such restrictions. We can
thus move the clk_set_min_rate() after our call to runtime_resume and
avoid the access while the power domain is disabled.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-2-d646ff6fb842@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Maxime Ripard [Thu, 26 Jan 2023 17:05:46 +0000 (18:05 +0100)]
drm/vc4: hdmi: Replace hardcoded value by define
The 120MHz value hardcoded in the call to max_t to compute the HSM rate
is defined in the driver as HSM_MIN_CLOCK_FREQ, let's switch to it so
that it's more readable.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-1-d646ff6fb842@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Thomas Weißschuh [Wed, 15 Feb 2023 01:04:53 +0000 (01:04 +0000)]
drm/nouveau/led: explicitly include linux/leds.h
Instead of relying on an accidental, transitive inclusion of linux/leds.h
use it directly.
Also drop the forware definition of struct led_classdev that is now
provided by linux/leds.h.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230215-power_supply-leds-nouveau-v1-1-ea93bfa0ba7e@weissschuh.net
Zack Rusin [Sat, 11 Feb 2023 05:05:14 +0000 (00:05 -0500)]
drm/vmwgfx: Do not drop the reference to the handle too soon
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference
before the kernel was done with buffer depending on userspace doing
the right thing. Same bug, different spot.
It is possible for userspace to predict the next buffer handle and
to destroy the buffer while it's still used by the kernel. Delay
dropping the internal reference on the buffers until kernel is done
with them.
Instead of immediately dropping the gem reference in vmw_user_bo_lookup
and vmw_gem_object_create_with_handle let the callers decide when they're
ready give the control back to userspace.
Also fixes the second usage of vmw_gem_object_create_with_handle in
vmwgfx_surface.c which wasn't grabbing an explicit reference
to the gem object which could have been destroyed by the userspace
on the owning surface at any point.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes:
8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org
Zack Rusin [Wed, 8 Feb 2023 18:00:50 +0000 (13:00 -0500)]
drm/vmwgfx: Stop accessing buffer objects which failed init
ttm_bo_init_reserved on failure puts the buffer object back which
causes it to be deleted, but kfree was still being called on the same
buffer in vmw_bo_create leading to a double free.
After the double free the vmw_gem_object_create_with_handle was
setting the gem function objects before checking the return status
of vmw_bo_create leading to null pointer access.
Fix the entire path by relaying on ttm_bo_init_reserved to delete the
buffer objects on failure and making sure the return status is checked
before setting the gem function objects on the buffer object.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes:
8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208180050.2093426-1-zack@kde.org
Zack Rusin [Fri, 10 Feb 2023 02:34:37 +0000 (21:34 -0500)]
drm/vmwgfx: Make the driver work without the dummy resources
In commit
180253782038 ("drm/ttm: stop allocating dummy resources during BO creation")
ttm stopped allocating dummy resources but vmwgfx was never ported to
handle it. Make the driver treat null resources as initial creation and
port code to handle null resources in general.
Fixes kernel oops'es on boot with vmwgfx.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes:
180253782038 ("drm/ttm: stop allocating dummy resources during BO creation")
Cc: Christian König <christian.koenig@amd.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230210023437.2214816-1-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:42 +0000 (22:35 -0500)]
drm/vmwgfx: Stop using raw ttm_buffer_object's
Various bits of the driver used raw ttm_buffer_object instead of the
driver specific vmw_bo object. All those places used to duplicate
the mapped bo caching policy of vmw_bo.
Instead of duplicating all of that code and special casing various
functions to work both with vmw_bo and raw ttm_buffer_object's unify
the buffer object handling code.
As part of that work fix the naming of bo's, e.g. insted of generic
backup use 'guest_memory' because that's what it really is.
All of it makes the driver easier to maintain and the code easier to
read. Saves 100+ loc as well.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-9-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:41 +0000 (22:35 -0500)]
drm/vmwgfx: Abstract placement selection
Problem with explicit placement selection in vmwgfx is that by the time
the buffer object needs to be validated the information about which
placement was supposed to be used is lost. To workaround this the driver
had a bunch of state in various places e.g. as_mob or cpu_blit to
somehow convey the information on which placement was intended.
Fix it properly by allowing the buffer objects to hold their preferred
placement so it can be reused whenever needed. This makes the entire
validation pipeline a lot easier both to understand and maintain.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-8-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:40 +0000 (22:35 -0500)]
drm/vmwgfx: Rename dummy to is_iomem
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-7-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:39 +0000 (22:35 -0500)]
drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths
Base mapped count is useless because the ttm unmap functions handle
null maps just fine so completely remove all the code related to it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-6-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:38 +0000 (22:35 -0500)]
drm/vmwgfx: Simplify fb pinning
Only the legacy display unit requires pinning of the fb memory in vram.
Both the screen objects and screen targets can present from any buffer.
That makes the pinning abstraction pointless. Simplify all of the code
and move it to the legacy display unit, the only place that needs it.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-5-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:37 +0000 (22:35 -0500)]
drm/vmwgfx: Rename vmw_buffer_object to vmw_bo
The rest of the drivers which are using ttm have mostly standardized on
driver_prefix_bo as the name for subclasses of the TTM buffer object.
Make vmwgfx match the rest of the drivers and follow the same naming
semantics.
This is especially clear given that the name of the file in which the
object was defined is vmw_bo.c.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-4-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:36 +0000 (22:35 -0500)]
drm/vmwgfx: Remove the duplicate bo_free function
Remove the explicit bo_free parameter which was switching between
vmw_bo_bo_free and vmw_gem_destroy which had exactly the same
implementation.
It makes no sense to keep parameter which is always the same, remove it
and all code referencing it. Instead use the vmw_bo_bo_free directly.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-3-zack@kde.org
Zack Rusin [Tue, 31 Jan 2023 03:35:35 +0000 (22:35 -0500)]
drm/vmwgfx: Use the common gem mmap instead of the custom code
Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by simply setting the vm_ops to vmwgfx specific ones on the
gem object itself.
Removes a lot of code from vmwgfx without any functional difference.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-2-zack@kde.org
Asahi Lina [Sun, 5 Feb 2023 12:51:24 +0000 (21:51 +0900)]
drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()
Other functions touching shmem->sgt take the pages lock, so do that here
too. drm_gem_shmem_get_pages() & co take the same lock, so move to the
_locked() variants to avoid recursive locking.
Discovered while auditing locking to write the Rust abstractions.
Fixes:
2194a63a818d ("drm: Add library for shmem backed GEM objects")
Fixes:
4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages")
Signed-off-by: Asahi Lina <lina@asahilina.net>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230205125124.2260-1-lina@asahilina.net
Maíra Canal [Thu, 2 Feb 2023 12:55:17 +0000 (09:55 -0300)]
drm/vgem: add missing mutex_destroy
vgem_fence_open() instantiates a mutex for a particular fence
instance, but never destroys it by calling mutex_destroy() in
vgem_fence_close().
So, add the missing mutex_destroy() to guarantee proper resource
destruction.
Fixes:
407779848445 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202125517.427976-1-mcanal@igalia.com
Christian König [Thu, 26 Jan 2023 10:26:38 +0000 (11:26 +0100)]
drm: remove dumb_destroy callback
Not used by any driver any more.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230126102814.8722-2-christian.koenig@amd.com
Somalapuram Amaranath [Wed, 8 Feb 2023 09:01:02 +0000 (14:31 +0530)]
drm/amdgpu: Remove TTM resource->start visible VRAM condition v2
Use amdgpu_bo_in_cpu_visible_vram() instead.
v2 (chk): fix test inversion
Signed-off-by: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208090106.9659-2-Amaranath.Somalapuram@amd.com
John Keeping [Fri, 20 Jan 2023 11:43:12 +0000 (11:43 +0000)]
drm/bridge: panel: Set orientation on panel_bridge connector
Commit
15b9ca1641f0 ("drm: Config orientation property if panel provides
it") added a helper to set the panel orientation early but only
connected this for drm_bridge_connector, which constructs a panel bridge
with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself.
When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the
panel_bridge creates its own connector the orientation is not set unless
the panel does it in .get_modes which is too late and leads to a warning
splat from __drm_mode_object_add() because the device is already
registered.
Call the necessary function to set add the orientation property when the
connector is created so that it is available before the device is
registered.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230120114313.2087015-1-john@metanate.com
Christian König [Mon, 30 Jan 2023 12:06:36 +0000 (12:06 +0000)]
drm/ttm: prevent moving of pinned BOs
We have checks for this in the individual drivers move callback, but
it's probably better to generally forbid that on a higher level.
Also stops exporting ttm_resource_compat() since that's not necessary
any more after removing the extra checks in vmwgfx.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-6-matthew.auld@intel.com
Christian König [Mon, 30 Jan 2023 12:06:35 +0000 (12:06 +0000)]
drm/ttm: stop allocating a dummy resource for pipelined gutting
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
Christian König [Mon, 30 Jan 2023 12:06:34 +0000 (12:06 +0000)]
drm/ttm: stop allocating dummy resources during BO creation
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-4-matthew.auld@intel.com
Matthew Auld [Mon, 30 Jan 2023 10:12:27 +0000 (10:12 +0000)]
drm/ttm: clear the ttm_tt when bo->resource is NULL
In the next few patches, when initially creating a ttm BO, the
bo->resource is NULL, and the driver is then expected to handle the
initial dummy move. However, if this is created as a system resource
the first ttm_tt we create will always have the clear value set to
false. Previously the initial ttm_tt would be created in
ttm_bo_validate() with the clear parameter always set to true.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Christian König <ckoenig.leichtzumerken@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.com
Acked-by: Nirmoy Das <nirmoy.das@intel.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 30 Jan 2023 12:06:32 +0000 (12:06 +0000)]
drm/i915/ttm: audit remaining bo->resource
In the near future TTM will have NULL bo->resource when the object is
initially created, plus after calling into pipeline-gutting. Try to
handle the remaining cases. In practice NULL bo->resource should be
taken to mean swapped-out or purged object.
v2 (Andrzej):
- Rather make i915_ttm_cpu_maps_iomem() return false with NULL
resource.
References:
516198d317d8 ("drm/i915: audit bo->resource usage v3")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-2-matthew.auld@intel.com
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Matthew Auld [Mon, 30 Jan 2023 12:06:31 +0000 (12:06 +0000)]
drm/i915/ttm: fix sparse warning
Sparse complains with:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse:
expected restricted vm_fault_t [assigned] [usertype] ret
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int
Fixes:
516198d317d8 ("drm/i915: audit bo->resource usage v3")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-1-matthew.auld@intel.com
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Stanislaw Gruszka [Thu, 2 Feb 2023 09:21:14 +0000 (10:21 +0100)]
accel/ivpu: Fix old dma_buf api usage
Update according to new dma-buf locking scheme.
Remove redundant WARN_ON()'s, dma_buf functions internally
have the same warnings already.
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-5-stanislaw.gruszka@linux.intel.com
Stanislaw Gruszka [Thu, 2 Feb 2023 09:21:13 +0000 (10:21 +0100)]
accel/ivpu: Set dma max_segment_size
Avoid below spurious warning:
[ 264.844029] DMA-API: intel_vpu 0000:00:0b.0: mapping sg segment longer than device claims to support [len=143360] [max=65536]
[ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160 debug_dma_map_sg+0x6ca/0xb70
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-4-stanislaw.gruszka@linux.intel.com
Andrzej Kacprowski [Thu, 2 Feb 2023 09:21:12 +0000 (10:21 +0100)]
accel/ivpu: Send VPU_JSM_MSG_CONTEXT_DELETE when deleting context
The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated
with the SSID, that included any blobs create by the user space
application.
The command can also remove doorbell registrations, but since this
does not work in HW scheduling case, we do not depend on this
capability and unregister the doorbells explicitly.
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-3-stanislaw.gruszka@linux.intel.com
Andrzej Kacprowski [Thu, 2 Feb 2023 09:21:11 +0000 (10:21 +0100)]
accel/ivpu: Fix FW API data alignment issues
FW API structures have been updated to fix misaligned
structure members.
Also changed JSM message header format to account for
future improvements.
Added explicit check for minimum supported JSM API version.
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-2-stanislaw.gruszka@linux.intel.com
Rob Clark [Thu, 19 Jan 2023 23:17:34 +0000 (15:17 -0800)]
drm/rockchip: Drop unbalanced obj unref
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj
reference that it doesn't own.
Fixes:
41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com
John Keeping [Thu, 10 Nov 2022 17:24:14 +0000 (17:24 +0000)]
drm/rockchip: avoid duplicate mappings for IOMMU devices
If a buffer is allocated with alloc_kmap, then it is vmap'd on creation
and there is no reason to map it again in rockchip_gem_prime_vmap() when
the existing mapping can be used.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20221110172415.2853420-1-john@metanate.com
Brian Norris [Mon, 31 Oct 2022 17:16:01 +0000 (10:16 -0700)]
drm/rockchip: vop: Quiet always-warning AFBC log
The downstream code from which this was derived didn't ever run through
this 'switch' block with non-AFBC formats, but the upstream code does --
we use this function to probe whether a given format is supported.
Demote the warning to eliminate this sort of warning seen on every
boot:
[drm] unsupported AFBC format[
3231564e]
And make it warn more than once, because if we *actually* care to see
what formats we're probing/rejecting and for what reasons, we probably
care about more than just the first message.
Drop the comment, because one of the two *is* commonly reachable.
And lastly, drop the unreachable return; we'd do better to let the
compiler complain if we start hitting this unexpectedly.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20221031101557.1.Ic1569d394173c1c3016142fee4bb87a09753db94@changeid
Michael Riesch [Tue, 24 Jan 2023 05:47:05 +0000 (06:47 +0100)]
drm/rockchip: vop2: add support for the rgb output block
The Rockchip VOP2 features an internal RGB output block, which can be
attached any video port of the VOP2. Add support for this output block.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-6-michael.riesch@wolfvision.net
Michael Riesch [Tue, 24 Jan 2023 05:47:04 +0000 (06:47 +0100)]
drm/rockchip: vop2: use symmetric function pair vop2_{create,destroy}_crtcs
Let the function name vop2_create_crtcs reflect that the function creates
multiple CRTCS. Also, use a symmetric function pair to create and destroy
the CRTCs and the corresponding planes.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-5-michael.riesch@wolfvision.net
Michael Riesch [Tue, 24 Jan 2023 05:47:03 +0000 (06:47 +0100)]
drm/rockchip: rgb: add video_port parameter to init function
The VOP2 driver has more than one video port, hence the hard-coded
port id will not work anymore. Add an extra parameter for the video
port id to the rockchip_rgb_init function.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-4-michael.riesch@wolfvision.net
Michael Riesch [Tue, 24 Jan 2023 05:47:02 +0000 (06:47 +0100)]
drm/rockchip: rgb: embed drm_encoder into rockchip_encoder
Commit
540b8f271e53 ("drm/rockchip: Embed drm_encoder into
rockchip_decoder") provides the means to pass the endpoint ID to the
VOP2 driver, which sets the interface MUX accordingly. However, this
step has not yet been carried out for the RGB output block. Embed the
drm_encoder structure into the rockchip_encoder structure and set the
endpoint ID correctly.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-3-michael.riesch@wolfvision.net
Michael Riesch [Tue, 24 Jan 2023 05:47:01 +0000 (06:47 +0100)]
drm/rockchip: vop2: initialize possible_crtcs properly
The variable possible_crtcs is only initialized for primary and
overlay planes. Since the VOP2 driver only supports these plane
types at the moment, the current code is safe. However, in order
to provide a future-proof solution, fix the initialization of
the variable.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-2-michael.riesch@wolfvision.net
Johan Jonker [Thu, 22 Dec 2022 14:27:35 +0000 (15:27 +0100)]
dt-bindings: display: rockchip: convert analogix_dp-rockchip.txt to yaml
Convert analogix_dp-rockchip.txt to yaml.
Changed:
Add power-domains property
File name
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/88a5a9e3-9bc8-5966-22ec-5bdb1fa7a5b1@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:26:57 +0000 (15:26 +0100)]
dt-bindings: display: bridge: convert analogix_dp.txt to yaml
Convert analogix_dp.txt to yaml for use as common document.
Changed:
Relexed requirements
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/489e7bd3-fa26-885f-4104-8b0b29aa4f2b@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:26:28 +0000 (15:26 +0100)]
dt-bindings: display: rockchip: convert dw_mipi_dsi_rockchip.txt to yaml
Convert dw_mipi_dsi_rockchip.txt to yaml.
Changed:
file name
requirements
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/d6dc8453-4807-0a5d-15bf-6dcf80dcd0fe@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:25:44 +0000 (15:25 +0100)]
dt-bindings: display: bridge: snps,dw-mipi-dsi: fix clock properties
Fix clock properties from the common snps,dw-mipi-dsi.yaml file,
as they don't match with what is used on the SoCs.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/78b4548e-dfe1-d0c6-f96c-5d40f28f8b2e@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:24:51 +0000 (15:24 +0100)]
dt-bindings: display: dsi-controller: move clock-master property
The clock-master property is used for the controller and not in the panel,
so move it there.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1c3b18ad-350f-e862-de98-a775e11e132c@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:24:15 +0000 (15:24 +0100)]
dt-bindings: soc: rockchip: grf: add rockchip,lvds.yaml
Add new converted rockchip,lvds.yaml to grf.yaml file.
Prepare for more SoCs with lvds output.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/ff3644da-e5ae-f795-c7d9-454b8c8bdfe8@gmail.com
Johan Jonker [Thu, 22 Dec 2022 14:22:14 +0000 (15:22 +0100)]
dt-bindings: display: rockchip: convert rockchip-lvds.txt to YAML
Convert rockchip-lvds.txt to YAML.
Changed:
Add power-domains property.
Requirements between PX30 and RK3288
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/67771143-fd83-383d-41b2-68e8707134e8@gmail.com
Deepak R Varma [Fri, 27 Jan 2023 20:51:26 +0000 (02:21 +0530)]
drm/arm/malidp: use sysfs_emit in show function callback
According to Documentation/filesystems/sysfs.rst, the show() callback
function of kobject attributes should strictly use sysfs_emit() instead
of sprintf() family functions.
Issue identified using the device_attr_show.cocci Coccinelle script.
Signed-off-by: Deepak R Varma <drv@mailo.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/Y9Q5Tt8c9WBDxeyV@ubun2204.myguest.virtualbox.org
Maíra Canal [Mon, 30 Jan 2023 12:55:55 +0000 (09:55 -0300)]
drm/format-helper: Use KUNIT_EXPECT_MEMEQ macro
Commit
b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
memory and, if the test fails, print the result in a human-friendly
format. Therefore, use KUNIT_EXPECT_MEMEQ to compare memory blocks in
replacement of the KUNIT_EXPECT_EQ macro.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230130125554.363481-1-mairacanal@riseup.net
Stephen Boyd [Fri, 6 Jan 2023 03:01:08 +0000 (19:01 -0800)]
drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable
The unprepare sequence has started to fail after moving to panel bridge
code in the msm drm driver (commit
007ac0262b0d ("drm/msm/dsi: switch to
DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:
panel-boe-tv101wum-nl6
ae94000.dsi.0: failed to set panel off: -22
This is because boe_panel_enter_sleep_mode() needs an operating DSI link
to set the panel into sleep mode. Performing those writes in the
unprepare phase of bridge ops is too late, because the link has already
been torn down by the DSI controller in post_disable, i.e. the PHY has
been disabled, etc. See dsi_mgr_bridge_post_disable() for more details
on the DSI .
Split the unprepare function into a disable part and an unprepare part.
For now, just the DSI writes to enter sleep mode are put in the disable
function. This fixes the panel off routine and keeps the panel happy.
My Wormdingler has an integrated touchscreen that stops responding to
touch if the panel is only half disabled too. This patch fixes it. And
finally, this saves power when the screen is off because without this
fix the regulators for the panel are left enabled when nothing is being
displayed on the screen.
Fixes:
007ac0262b0d ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
Fixes:
a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel")
Cc: yangcong <yangcong5@huaqin.corp-partner.google.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jitao Shi <jitao.shi@mediatek.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230106030108.2542081-1-swboyd@chromium.org
Arnd Bergmann [Thu, 26 Jan 2023 16:37:55 +0000 (17:37 +0100)]
accel/ivpu: avoid duplicate assignment
With extra warnings enabled, gcc warns about two assignments
of the same .mmap callback:
In file included from drivers/accel/ivpu/ivpu_drv.c:10:
include/drm/drm_accel.h:31:27: error: initialized field overwritten [-Werror=override-init]
31 | .mmap = drm_gem_mmap
| ^~~~~~~~~~~~
drivers/accel/ivpu/ivpu_drv.c:360:9: note: in expansion of macro 'DRM_ACCEL_FOPS'
360 | DRM_ACCEL_FOPS,
| ^~~~~~~~~~~~~~
Remove the unused local assignment.
Fixes:
e868cc591e89 ("accel: Add .mmap to DRM_ACCEL_FOPS")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230126163804.3648051-2-arnd@kernel.org