Thomas Zimmermann [Fri, 25 Jun 2021 08:22:20 +0000 (10:22 +0200)]
drm/vmwgfx: Don't set struct drm_device.irq_enabled
The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in vmxgfx. All usage of
the field within vmwgfx can safely be removed.
Thomas Zimmermann [Fri, 25 Jun 2021 08:22:10 +0000 (10:22 +0200)]
drm/omapdrm: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct omap_drm_device.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Thomas Zimmermann [Fri, 25 Jun 2021 08:22:01 +0000 (10:22 +0200)]
drm/i915: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct drm_i915_private.irq_enabled. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Thomas Zimmermann [Fri, 25 Jun 2021 08:21:59 +0000 (10:21 +0200)]
drm: Don't test for IRQ support in VBLANK ioctls
For KMS drivers, replace the IRQ check in VBLANK ioctls with a check for
vblank support. IRQs might be enabled wthout vblanking being supported.
This change also removes the DRM framework's only dependency on IRQ state
for non-legacy drivers. For legacy drivers with userspace modesetting,
the original test remains in drm_wait_vblank_ioctl().
v4:
* avoid preprocessor ifdef in drm_wait_vblank_ioctl()
(Jani, Thierry)
v3:
* optimize test in drm_wait_vblank_ioctl() for KMS case (Liviu)
* update docs for drm_irq_uninstall()
v2:
* keep the old test for legacy drivers in
drm_wait_vblank_ioctl() (Daniel)
Thomas Zimmermann [Fri, 25 Jun 2021 08:21:58 +0000 (10:21 +0200)]
drm/radeon: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct radeon_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Remove the check around drm_irq_uninstall(). The same test is
done by the function internally. The tested state in irq_enabled
is considered obsolete and should not be used by KMS drivers.
Thomas Zimmermann [Fri, 25 Jun 2021 08:21:56 +0000 (10:21 +0200)]
drm/amdgpu: Track IRQ state in local device state
Replace usage of struct drm_device.irq_enabled with the driver's
own state field struct amdgpu_device.irq.installed. The field in
the DRM device structure is considered legacy and should not be
used by KMS drivers.
Boris Brezillon [Thu, 24 Jun 2021 14:08:50 +0000 (16:08 +0200)]
drm/sched: Declare entity idle only after HW submission
The panfrost driver tries to kill in-flight jobs on FD close after
destroying the FD scheduler entities. For this to work properly, we
need to make sure the jobs popped from the scheduler entities have
been queued at the HW level before declaring the entity idle, otherwise
we might iterate over a list that doesn't contain those jobs.
Daniel Vetter [Wed, 23 Jun 2021 16:24:56 +0000 (18:24 +0200)]
drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default
It's tedious to review this all the time, and my audit showed that
arcpgu actually forgot to set this.
Make this the default and stop worrying.
Again I sprinkled WARN_ON_ONCE on top to make sure we don't have
strange combinations of hooks: cleanup_fb without prepare_fb doesn't
make sense, and since simpler drivers are all new they better be GEM
based drivers.
v2: Warn and bail when it's _not_ a GEM driver (Noralf)
v3: It's neither ... nor, not not (Sam)
Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210623162456.3373469-1-daniel.vetter@ffwll.ch
Like we have for the shadow helpers too, and roll it out to drivers.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210622165511.3169559-11-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 22 Jun 2021 16:55:05 +0000 (18:55 +0200)]
drm/armada: Remove prepare/cleanup_fb hooks
All they do is refcount the fb, which the atomic helpers already do.
This is was necessary with the legacy helpers and I guess just carry
over in the conversion. drm_plane_state always has a full reference
for its ->fb pointer during its entire lifetime,
see __drm_atomic_helper_plane_destroy_state()
Daniel Vetter [Wed, 23 Jun 2021 16:22:00 +0000 (18:22 +0200)]
drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default
There's a bunch of atomic drivers who don't do this quite correctly,
luckily most of them aren't in wide use or people would have noticed
the tearing.
By making this the default we avoid the constant audit pain and can
additionally remove a ton of lines from vfuncs for a bit more clarity
in smaller drivers.
While at it complain if there's a cleanup_fb hook but no prepare_fb
hook, because that makes no sense. I haven't found any driver which
violates this, but better safe than sorry.
Subsequent patches will reap the benefits.
v2: It's neither ... nor, not not (Sam)
Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210623162200.3372056-1-daniel.vetter@ffwll.ch
and that last boolean controls whether the exclusive or shared fence
slot is used.
- radeon follows this contract by setting
p->relocs[i].tv.num_shared = !r->write_domain;
in radeon_cs_parser_relocs(), which ensures that the call to
ttm_eu_fence_buffer_objects() in radeon_cs_parser_fini() will do the
right thing.
- vmwgfx seems to follow this contract with the shotgun approach of
always setting ttm_val_buf->num_shared = 0, which means
ttm_eu_fence_buffer_objects() will only use the exclusive slot.
- etnaviv follows this contract, as can be trivially seen by looking
at submit_attach_object_fences()
- i915 is a bit a convoluted maze with multiple paths leading to
i915_vma_move_to_active(). Which sets the exclusive flag if
EXEC_OBJECT_WRITE is set. This can either come as a buffer flag for
softpin mode, or through the write_domain when using relocations. It
follows this contract.
- lima follows this contract, see lima_gem_submit() which sets the
exclusive fence when the LIMA_SUBMIT_BO_WRITE flag is set for that
bo
- msm follows this contract, see msm_gpu_submit() which sets the
exclusive flag when the MSM_SUBMIT_BO_WRITE is set for that buffer
- panfrost follows this contract with the shotgun approach of just
always setting the exclusive fence, see
panfrost_attach_object_fences(). Benefits of a single engine I guess
- v3d follows this contract with the same shotgun approach in
v3d_attach_fences_and_unlock_reservation(), but it has at least an
XXX comment that maybe this should be improved
- v4c uses the same shotgun approach of always setting an exclusive
fence, see vc4_update_bo_seqnos()
- vgem also follows this contract, see vgem_fence_attach_ioctl() and
the VGEM_FENCE_WRITE. This is used in some igts to validate prime
sharing with i915.ko without the need of a 2nd gpu
- vritio follows this contract again with the shotgun approach of
always setting an exclusive fence, see virtio_gpu_array_add_fence()
This covers the setting of the exclusive fences when writing.
Synchronizing against the exclusive fence is a lot more tricky, and I
only spot checked a few:
- i915 does it, with the optional EXEC_OBJECT_ASYNC to skip all
implicit dependencies (which is used by vulkan)
- etnaviv does this. Implicit dependencies are collected in
submit_fence_sync(), again with an opt-out flag
ETNA_SUBMIT_NO_IMPLICIT. These are then picked up in
etnaviv_sched_dependency which is the
drm_sched_backend_ops->dependency callback.
- v4c seems to not do much here, maybe gets away with it by not having
a scheduler and only a single engine. Since all newer broadcom chips than
the OG vc4 use v3d for rendering, which follows this contract, the
impact of this issue is fairly small.
- v3d does this using the drm_gem_fence_array_add_implicit() helper,
which then it's drm_sched_backend_ops->dependency callback
v3d_job_dependency() picks up.
- panfrost is nice here and tracks the implicit fences in
panfrost_job->implicit_fences, which again the
drm_sched_backend_ops->dependency callback panfrost_job_dependency()
picks up. It is mildly questionable though since it only picks up
exclusive fences in panfrost_acquire_object_fences(), but not buggy
in practice because it also always sets the exclusive fence. It
should pick up both sets of fences, just in case there's ever going
to be a 2nd gpu in a SoC with a mali gpu. Or maybe a mali SoC with a
pcie port and a real gpu, which might actually happen eventually. A
bug, but easy to fix. Should probably use the
drm_gem_fence_array_add_implicit() helper.
- lima is nice an easy, uses drm_gem_fence_array_add_implicit() and
the same schema as v3d.
- msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
but because it doesn't use the drm/scheduler it handles fences from
the wrong context with a synchronous dma_fence_wait. See
submit_fence_sync() leading to msm_gem_sync_object(). Investing into
a scheduler might be a good idea.
- all the remaining drivers are ttm based, where I hope they do
appropriately obey implicit fences already. I didn't do the full
audit there because a) not follow the contract would confuse ttm
quite well and b) reading non-standard scheduler and submit code
which isn't based on drm/scheduler is a pain.
Onwards to the display side.
- Any driver using the drm_gem_plane_helper_prepare_fb() helper will
correctly. Overwhelmingly most drivers get this right, except a few
totally dont. I'll follow up with a patch to make this the default
and avoid a bunch of bugs.
- I didn't audit the ttm drivers, but given that dma_resv started
there I hope they get this right.
In conclusion this IS the contract, both as documented and
overwhelmingly implemented, specically as implemented by all render
drivers except amdgpu.
drm/amdgpu: fix using shared fence for exported BOs v2
but this fix falls short on a number of areas:
- It's racy, by the time the buffer is shared it might be too late. To
make sure there's definitely never a problem we need to set the
fences correctly for any buffer that's potentially exportable.
- It's breaking uapi, dma-buf fds support poll() and differentitiate
between, which was introduced in
Rejecting new development because your own driver is broken and
violates established cross driver contracts and uapi is really not
how upstream works.
Now this patch will have a severe performance impact on anything that
runs on multiple engines. So we can't just merge it outright, but need
a bit a plan:
- amdgpu needs a proper uapi for handling implicit fencing. The funny
thing is that to do it correctly, implicit fencing must be treated
as a very strange IPC mechanism for transporting fences, where both
setting the fence and dependency intercepts must be handled
explicitly. Current best practices is a per-bo flag to indicate
writes, and a per-bo flag to to skip implicit fencing in the CS
ioctl as a new chunk.
- Since amdgpu has been shipping with broken behaviour we need an
opt-out flag from the butchered implicit fencing model to enable the
proper explicit implicit fencing model.
- for kernel memory fences due to bo moves at least the i915 idea is
to use ttm_bo->moving. amdgpu probably needs the same.
- since the current p2p dma-buf interface assumes the kernel memory
fence is in the exclusive dma_resv fence slot we need to add a new
fence slot for kernel fences, which must never be ignored. Since
currently only amdgpu supports this there's no real problem here
yet, until amdgpu gains a NO_IMPLICIT CS flag.
- New userspace needs to ship in enough desktop distros so that users
wont notice the perf impact. I think we can ignore LTS distros who
upgrade their kernels but not their mesa3d snapshot.
- Then when this is all in place we can merge this patch here.
What is not a solution to this problem here is trying to make the
dma_resv rules in the kernel more clever. The fundamental issue here
is that the amdgpu CS uapi is the least expressive one across all
drivers (only equalled by panfrost, which has an actual excuse) by not
allowing any userspace control over how implicit sync is conducted.
Until this is fixed it's completely pointless to make the kernel more
clever to improve amdgpu, because all we're doing is papering over
this uapi design issue. amdgpu needs to attain the status quo
established by other drivers first, once that's achieved we can tackle
the remaining issues in a consistent way across drivers.
v2: Bas pointed me at AMDGPU_GEM_CREATE_EXPLICIT_SYNC, which I
entirely missed.
This is great because it means the amdgpu specific piece for proper
implicit fence handling exists already, and that since a while. The
only thing that's now missing is
- fishing the implicit fences out of a shared object at the right time
- setting the exclusive implicit fence slot at the right time.
Jason has a patch series to fill that gap with a bunch of generic
ioctl on the dma-buf fd:
Use the audit covered in this commit message as the excuse to update
the dma-buf docs around dma_buf.resv usage across drivers.
Since dynamic importers have different rules also hammer these in
again while we're at it.
v4:
- Add the missing "through the device" in the dynamic section that I
overlooked.
- Fix a kerneldoc markup mistake, the link didn't connect
v5:
- A few s/should/must/ to make clear what must be done (if the driver
does implicit sync) and what's more a maybe (Daniel Stone)
- drop all the example api discussion, that needs to be expanded,
clarified and put into a new chapter in drm-uapi.rst (Daniel Stone)
Cc: Daniel Stone <daniel@fooishbar.org> Acked-by: Daniel Stone <daniel@fooishbar.org> Reviewed-by: Dave Airlie <airlied@redhat.com> (v4) Reviewed-by: Christian König <christian.koenig@amd.com> (v3) Cc: mesa-dev@lists.freedesktop.org Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Dave Airlie <airlied@gmail.com> Cc: Rob Clark <robdclark@chromium.org> Cc: Kristian H. Kristensen <hoegsberg@google.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Daniel Stone <daniels@collabora.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Deepak R Varma <mh12gx2825@gmail.com> Cc: Chen Li <chenli@uniontech.com> Cc: Kevin Wang <kevin1.wang@amd.com> Cc: Dennis Li <Dennis.Li@amd.com> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210624125246.166721-1-daniel.vetter@ffwll.ch
Daniel Vetter [Wed, 23 Jun 2021 16:17:12 +0000 (18:17 +0200)]
dma-buf: Switch to inline kerneldoc
Also review & update everything while we're at it.
This is prep work to smash a ton of stuff into the kerneldoc for
@resv.
v2: Move the doc for sysfs_entry.attachment_uid to the right place too
(Sam)
Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Christian König <christian.koenig@amd.com> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Nirmoy Das <nirmoy.das@amd.com> Cc: Deepak R Varma <mh12gx2825@gmail.com> Cc: Chen Li <chenli@uniontech.com> Cc: Kevin Wang <kevin1.wang@amd.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210623161712.3370885-1-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 22 Jun 2021 16:55:10 +0000 (18:55 +0200)]
drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
Spotted while trying to convert panfrost to these.
Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210622165511.3169559-15-daniel.vetter@ffwll.ch
Laurent Pinchart [Thu, 24 Jun 2021 00:02:59 +0000 (03:02 +0300)]
dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional
The SN65DSI86 EN pin can be hardwired to a high level, or connected to a
global reset signal, not controllable by the kernel. Make it optional in
those cases.
Boris Brezillon [Mon, 21 Jun 2021 13:38:56 +0000 (15:38 +0200)]
drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv
Jobs can be in-flight when the file descriptor is closed (either because
the process did not terminate properly, or because it didn't wait for
all GPU jobs to be finished), and apparently panfrost_job_close() does
not cancel already running jobs. Let's refcount the MMU context object
so it's lifetime is no longer bound to the FD lifetime and running jobs
can finish properly without generating spurious page faults.
Daniel Vetter [Tue, 22 Jun 2021 16:55:02 +0000 (18:55 +0200)]
drm/panfrost: Fix implicit sync
Currently this has no practial relevance I think because there's not
many who can pull off a setup with panfrost and another gpu in the
same system. But the rules are that if you're setting an exclusive
fence, indicating a gpu write access in the implicit fencing system,
then you need to wait for all fences, not just the previous exclusive
fence.
panfrost against itself has no problem, because it always sets the
exclusive fence (but that's probably something that will need to be
fixed for vulkan and/or multi-engine gpus, or you'll suffer badly).
Also no problem with that against display.
With the prep work done to switch over to the dependency helpers this
is now a oneliner.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://patchwork.freedesktop.org/patch/msgid/20210622165511.3169559-7-daniel.vetter@ffwll.ch
Daniel Vetter [Tue, 22 Jun 2021 16:55:01 +0000 (18:55 +0200)]
drm/panfrost: Use xarray and helpers for depedency tracking
More consistency and prep work for the next patch.
Aside: I wonder whether we shouldn't just move this entire xarray
business into the scheduler so that not everyone has to reinvent the
same wheels. Cc'ing some scheduler people for this too.
v2: Correctly handle sched_lock since Lucas pointed out it's needed.
Lang Yu [Tue, 22 Jun 2021 16:23:35 +0000 (12:23 -0400)]
drm/amdgpu: user temporary GTT as bounce buffer
Currently, we have a limitted GTT memory size and need a bounce buffer
when doing buffer migration between VRAM and SYSTEM domain.
The problem is under GTT memory pressure we can't do buffer migration
between VRAM and SYSTEM domain. But in some cases we really need that.
Eespecially when validating a VRAM backing store BO which resides in
SYSTEM domain.
v2: still account temporary GTT allocations
v3 (chk): revert to the simpler change for now
Dom Cobley [Tue, 25 May 2021 13:23:50 +0000 (15:23 +0200)]
drm/vc4: hdmi: Set VC4_HDMI_MAI_CONFIG_FORMAT_REVERSE
Without this bit set, HDMI_MAI_FORMAT doesn't pick up
the format and samplerate from DVP_CFG_MAI0_FMT and you
can't get HDMI_HDMI_13_AUDIO_STATUS_1 to indicate HBR mode
Dom Cobley [Tue, 25 May 2021 13:23:48 +0000 (15:23 +0200)]
drm/vc4: hdmi: Set HD_CTL_WHOLSMP and HD_CTL_CHALIGN_SET
Symptom is random switching of speakers when using multichannel.
Repeatedly running speakertest -c8 occasionally starts with
channels jumbled. This is fixed with HD_CTL_WHOLSMP.
The other bit looks beneficial and apears harmless in testing so
I'd suggest adding it too.
Documentation says: HD_CTL_WHILSMP_SET
Wait for whole sample. When this bit is set MAI transmit will start
only when there is at least one whole sample available in the fifo.
Documentation says: HD_CTL_CHALIGN_SET
Channel Align When Overflow. This bit is used to realign the audio
channels in case of an overflow.
If this bit is set, after the detection of an overflow, equal
amount of dummy words to the missing words will be written to fifo,
filling up the broken sample and maintaining alignment.
Maxime Ripard [Wed, 16 Jun 2021 14:15:29 +0000 (16:15 +0200)]
drm: Mention the power state requirement on side-channel operations
The drm_connector detect, drm_dp_aux transfer and mipi_dsi_host
operations typically require to access their underlying device to
perform what is expected of them.
However, there's no guarantee on the fact that the device has been
enabled through atomic_enable or similar that will usually power the
device. The access to an unpowered device is then an undefined behaviour
ranging from the access being ignored to a hard CPU hang.
Let's document that expectation to avoid as much as possible those
consequences.
Maxime Ripard [Wed, 16 Jun 2021 14:15:28 +0000 (16:15 +0200)]
drm/dp_helper: Mention the concurrency requirement hw_mutex
Drivers that allow concurrent access over multiple DP channels need to
provide additional locking, even though the hw_mutex field might
indicate otherwise. Clarify it in the documentation.
Vivek Kasireddy [Thu, 10 Jun 2021 23:24:56 +0000 (16:24 -0700)]
drm/virtio: Add the fence in resource_flush if present
If the framebuffer associated with the plane contains a fence, then
it is added to resource_flush and will be waited upon for a max of
50 msecs or until it is signalled by the Host.
Dongwon Kim [Fri, 11 Jun 2021 21:21:07 +0000 (14:21 -0700)]
udmabuf: configurable list_limit and size_limit_mb
Default list_limit and size_limit_mb are not big enough to cover all
possible use cases. For example, list_limit could be well over its default,
1024 if only one or several pages are chained in all individual list entries
when creating dmabuf backed by >4MB buffer. list_limit and size_limit_mb are
now defined as module parameters so that those can be optionally configured
by root with proper values to remove these constraints.
Christian and me realized we have a pretty massive disconnect about
different interpretations of what dma_resv is used for by different
drivers. The discussion is much, much bigger than this change here,
but this is an important one:
Non-dynamic exporters must guarantee that the memory they return is
ready for use. They cannot expect importers to wait for the exclusive
fence. Only dynamic importers are required to obey the dma_resv fences
strictly (and more patches are needed to define exactly what this
means).
Christian has patches to update nouvea, radeon and amdgpu. The only
other driver using both ttm and supporting dma-buf export is qxl,
which only uses synchronous ttm_bo_move.
v2: To hammer this in document that dynamic importers _must_ wait for
the exclusive fence after having called dma_buf_map_attachment.
Laurent Pinchart [Mon, 21 Jun 2021 12:55:18 +0000 (15:55 +0300)]
drm: bridge: ti-sn65dsi83: Retrieve the display mode from the state
Instead of storing a copy of the display mode in the sn65dsi83
structure, retrieve it from the atomic state in
sn65dsi83_atomic_enable(). This allows the removal of the .mode_set()
operation, and completes the transition to the atomic API.
Laurent Pinchart [Mon, 21 Jun 2021 12:55:17 +0000 (15:55 +0300)]
drm: bridge: ti-sn65dsi83: Retrieve output format from bridge state
The driver currently iterates over all connectors to get the bus format,
used to configure the LVDS output format. This causes several issues:
- If other connectors than the LVDS output are present, the format used
by the driver may end up belonging to an entirely different output.
- The code can crash if some connectors are not connected, as bus_format
may then be NULL.
- There's no guarantee that the bus format on the connector at the
output of the pipeline matches the output of the sn65dsi83, as there
may be other bridges in the pipeline.
Solve this by retrieving the format from the bridge state instead, which
provides the format corresponding to the output of the bridge.
The struct sn65dsi83 lvds_format_24bpp and lvds_format_jeida fields are
moved to local variables in sn65dsi83_atomic_enable() as they're now
used in that function only.
Laurent Pinchart [Mon, 21 Jun 2021 12:55:16 +0000 (15:55 +0300)]
drm: bridge: ti-sn65dsi83: Switch to atomic operations
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API, started with the introduction of
.atomic_get_input_bus_fmts(). This will be needed to access the mode
from the atomic state.
Laurent Pinchart [Mon, 21 Jun 2021 12:55:15 +0000 (15:55 +0300)]
drm: bridge: ti-sn65dsi83: Pass mode explicitly to helper functions
Pass the display mode explicitly to the sn65dsi83_get_lvds_range() and
sn65dsi83_get_dsi_range() functions to prepare for its removal from the
sn65dsi83 structure. This is not meant to bring any functional change.
Laurent Pinchart [Mon, 21 Jun 2021 12:55:14 +0000 (15:55 +0300)]
drm: bridge: ti-sn65dsi83: Move LVDS format selection to .mode_set()
The LVDS format is selected based on the bus format reported by the
connector. This is currently done in .mode_fixup(), but that's not the
right place, as the format should be selected when setting the mode.
Move it to .mode_set().
Marek Vasut [Sun, 20 Jun 2021 22:42:08 +0000 (00:42 +0200)]
drm/bridge: ti-sn65dsi83: Replace connector format patching with atomic_get_input_bus_fmts
Patching the connector format is causing various problematic
side effects. Implement .atomic_get_input_bus_fmts callback
instead, which sets up the input (DSI-end) format, and that
format can then be used in pipeline format negotiation between
the DSI-end of this bridge and the other component closer to
the scanout engine.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Adam Ford <aford173@gmail.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Valentin Raevsky <valentin@compulab.co.il> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210620224208.184719-1-marex@denx.de
Colin Ian King [Fri, 18 Jun 2021 18:35:24 +0000 (19:35 +0100)]
drm/gma500/oaktrail_lvds: replace continue with break
Currently a loop scans through the connector list checking
for connectors that do not match a specific criteria. The
use of the continue statement is a little unintuitive and
can confuse static analysis checking. Invert the criteria
matching logic and use a break to terminate the loop once
the first suitable connector has been found.
Thanks to Patrik Jakobsson for explaining the original
intent of the code and suggesting this change.
Dan Carpenter [Fri, 18 Jun 2021 08:37:21 +0000 (11:37 +0300)]
drm/amdgpu: fix amdgpu_preempt_mgr_new()
There is a reversed if statement in amdgpu_preempt_mgr_new() so it
always returns -ENOMEM.
Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/YMxbQXg/Wqm0ACxt@mwanda Signed-off-by: Christian König <christian.koenig@amd.com>
Pi-Hsun Shih [Tue, 15 Jun 2021 03:29:24 +0000 (11:29 +0800)]
drm/bridge: anx7625: Make hpd workqueue freezable
There were still a race condition between hpd work and suspend, since
the workqueue work can still be run after anx7625 had powered off in
suspend.
Since we never want hpd work to run while suspending, and there's no
harm to delay them to be run after resume, mark the workqueue as
WQ_FREEZABLE so all works won't run while suspending.
Jason Ekstrand [Thu, 17 Jun 2021 19:42:58 +0000 (14:42 -0500)]
dma-buf: Document DMA_BUF_IOCTL_SYNC (v3)
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
documentation for DMA_BUF_IOCTL_SYNC.
v2 (Daniel Vetter):
- Fix a couple typos
- Add commentary about synchronization with other devices
- Use item list format for describing flags
v3 (Pekka Paalanen):
- Clarify stalling requirements.
- Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be
called before more GPU work happens.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210617194258.579011-1-jason@jlekstrand.net
Martin Krastev [Tue, 15 Jun 2021 18:23:36 +0000 (14:23 -0400)]
drm/vmwgfx: Fix build issues in mksGuestStats discovered by the kernel test robot
Fixes for ARCH
i386
* printk format specifier warnings
* inconsistent operand constraints in an ‘asm’ errors
arm64
* not targeted by the commit being fixed
Zack Rusin [Tue, 15 Jun 2021 18:23:35 +0000 (14:23 -0400)]
drm/vmwgfx: Fix a bad merge in otable batch takedown
Change 2ef4fb92363c ("drm/vmwgfx: Make sure bo's are unpinned before putting them back")
caused a conflict in one of the drm trees and the merge commit 68a32ba14177 ("Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm")
accidently re-added code that the original change was removing.
Fixed by removing the incorrect buffer unpin - it has already been unpinned
two lines above.
Zack Rusin [Tue, 15 Jun 2021 18:23:33 +0000 (14:23 -0400)]
drm/vmwgfx: Update device headers
Historically our device headers have been forked versions of the
internal device headers, this has made maintaining them a bit
of a burden. To fix the situation, going forward, the device headers
will be verbatim copies of the internal headers.
To do that the driver code has to be adapted to use pristine
device headers. This will make future update to the device
headers trivial and automatic.
Maxime Ripard [Mon, 24 May 2021 13:20:18 +0000 (15:20 +0200)]
drm/vc4: hdmi: Rely on interrupts to handle hotplug
DRM currently polls for the HDMI connector status every 10s, which can
be an issue when we connect/disconnect a display quickly or the device
on the other end only issues a hotplug pulse (for example on EDID
change).
Switch the driver to rely on the internal controller logic for the
BCM2711/RPi4.
Yu Jiahua [Wed, 16 Jun 2021 03:44:48 +0000 (19:44 -0800)]
drivers: gpu: add missing MODULE_DEVICE_TABLE in anx7625.c
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Hridya Valsaraju [Thu, 3 Jun 2021 21:47:51 +0000 (14:47 -0700)]
dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Overview
========
The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It
allows statistics to be enabled for each DMA-BUF in sysfs by enabling
the config CONFIG_DMABUF_SYSFS_STATS.
The following stats will be exposed by the interface:
The inode_number is unique for each DMA-BUF and was added earlier [1]
in order to allow userspace to track DMA-BUF usage across different
processes.
Use Cases
=========
The interface provides a way to gather DMA-BUF per-buffer statistics
from production devices. These statistics will be used to derive DMA-BUF
per-exporter stats and per-device usage stats for Android Bug reports.
The corresponding userspace changes can be found at [2].
Telemetry tools will also capture this information(along with other
memory metrics) periodically as well as on important events like a
foreground app kill (which might have been triggered by Low Memory
Killer). It will also contribute to provide a snapshot of the system
memory usage on other events such as OOM kills and Application Not
Responding events.
Background
==========
Currently, there are two existing interfaces that provide information
about DMA-BUFs.
1) /sys/kernel/debug/dma_buf/bufinfo
debugfs is however unsuitable to be mounted in production systems and
cannot be considered as an alternative to the sysfs interface being
proposed.
2) proc/<pid>/fdinfo/<fd>
The proc/<pid>/fdinfo/<fd> files expose information about DMA-BUF fds.
However, the existing procfs interfaces can only provide information
about the buffers for which processes hold fds or have the buffers
mmapped into their address space. Since the procfs interfaces alone
cannot provide a full picture of all DMA-BUFs in the system, there is
the need for an alternate interface to provide this information on
production systems.
The patch contains the following major improvements over v1:
1) Each attachment is represented by its own directory to allow creating
a symlink to the importing device and to also provide room for future
expansion.
2) The number of distinct mappings of each attachment is exposed in a
separate file.
3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers
inorder to make the interface expandable in future.
All of the improvements above are based on suggestions/feedback from
Daniel Vetter and Christian König.
A shell script that can be run on a classic Linux environment to read
out the DMA-BUF statistics can be found at [3](suggested by John
Stultz).
Christian König [Wed, 5 May 2021 09:40:54 +0000 (11:40 +0200)]
dma-buf: some dma_fence_chain improvements
The callback and the irq work are never used at the same
time. Putting them into an union saves us 24 bytes and
makes the structure only 120 bytes in size.
Thomas Zimmermann [Mon, 14 Jun 2021 04:56:22 +0000 (06:56 +0200)]
Merge tag 'tags/topic/i915-ttm-2021-06-11' into drm-misc-next
drm-misc and drm-intel pull request for topic/i915-ttm:
- Convert i915 lmem handling to ttm.
- Add a patch to temporarily add a driver_private member to vma_node.
- Use this to allow mixed object mmap handling for i915.
Zack Rusin [Wed, 9 Jun 2021 17:23:07 +0000 (13:23 -0400)]
drm/vmwgfx: Fix implicit declaration error
The declarations of ttm_range_man_init and ttm_range_man_fini
have been moved to ttm_range_manager.h so we have to add it
to the include list.
Signed-off-by: Zack Rusin <zackr@vmware.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Fixes: 3eb7d96e9415 ("drm/ttm: flip over the range manager to self allocated nodes") Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-10-zackr@vmware.com
projects / users / willy / xarray.git / log