From: Rob Clark
Re-aligning naming to better match drm_gpuvm terminology will make
things less confusing at the end of the drm_gpuvm conversion.
This is just rename churn, no functional change.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
---
drivers/gpu/d
From: Rob Clark
Conversion to DRM GPU VA Manager[1], and adding support for Vulkan Sparse
Memory[2] in the form of:
1. A new VM_BIND submitqueue type for executing VM MSM_SUBMIT_BO_OP_MAP/
MAP_NULL/UNMAP commands
2. A new VM_BIND ioctl to allow submitting batches of one or more
MAP/MAP_NU
From: Rob Clark
Eases migration for drivers where VAs don't hold hard references to
their associated BO, avoiding reference loops.
In particular, msm uses soft references to optimistically keep around
mappings until the BO is distroyed. Which obviously won't work if the
VA (the mapping) is hold
From: Rob Clark
Similar to the existing credit limit mechanism, but applying to jobs
enqueued to the scheduler but not yet run.
The use case is to put an upper bound on preallocated, and potentially
unneeded, pgtable pages. When this limit is exceeded, pushing new jobs
will block until the coun
From: Rob Clark
Just some tidying up.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.h | 44 +++
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/dr
From: Rob Clark
Now that we've realigned deletion and allocation, switch over to using
drm_gpuvm/drm_gpuva. This allows us to support multiple VMAs per BO per
VM, to allow mapping different parts of a single BO at different virtual
addresses, which is a key requirement for sparse/VM_BIND.
This
From: Rob Clark
This fits better drm_gpuvm/drm_gpuva.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 16 +++-
drivers/gpu/drm/msm/msm_gem_vma.c | 2 ++
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm
From: Rob Clark
This is a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 +--
drivers/g
From: Rob Clark
If the callback is going to have to attempt to grab more locks, it is
useful to have an ww_acquire_ctx to avoid locking order problems.
Why not use the drm_exec helper instead? Mainly because (a) where
ww_acquire_init() is called is awkward, and (b) we don't really
need to retry
From: Rob Clark
Previously we'd also tear down the VMA, making the address space
available again. But with drm_gpuvm conversion, this would require
holding the locks of all VMs the GEM object is mapped in. Which is
problematic for the shrinker.
Instead just let the VMA hang around until the GE
From: Rob Clark
Introduce a mechanism to count the worst case # of pages required in a
VM_BIND op.
Note that previously we would have had to somehow account for
allocations in unmap, when splitting a block. This behavior was removed
in commit 33729a5fc0ca ("iommu/io-pgtable-arm: Remove split on
From: Rob Clark
Similar to the previous commit, add support for dumping partial
mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 10 -
drivers/gpu/drm/msm/msm_rd.c | 38 ---
2 files changed, 17 insertions(+), 31 deletions(-)
diff
From: Rob Clark
So we can monitor how many pages are getting preallocated vs how many
get used.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_trace.h | 14 ++
drivers/gpu/drm/msm/msm_iommu.c | 4
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/m
From: Rob Clark
With async VM_BIND, the actual pgtable updates are deferred.
Synchronously, a list of map/unmap ops will be generated, but the
actual pgtable changes are deferred. To support that, split out
op handlers and change the existing non-VM_BIND paths to use them.
Note in particular, t
On 13.05.25 19:40, Liam R. Howlett wrote:
* David Hildenbrand [250512 08:34]:
Let's provide variants of track_pfn_remap() and untrack_pfn() that won't
mess with VMAs, and replace the usage in mm/memremap.c.
Add some documentation.
Reviewed-by: Lorenzo Stoakes
Acked-by: Ingo Molnar # x86 bit
From: Rob Clark
When userspace opts in to VM_BIND, the submit no longer holds references
keeping the VMA alive. This makes it difficult to distinguish between
UMD/KMD/app bugs. So add a debug option for logging the most recent VM
updates and capturing these in GPU devcoredumps.
The submitqueue
From: Rob Clark
In this case, userspace could request dumping partial GEM obj mappings.
Also drop use of should_dump() helper, which really only makes sense in
the old submit->bos[] table world.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 17 ++---
1 file changed,
From: Rob Clark
Convert to using the gpuvm's r_obj for serializing access to the VM.
This way we can use the drm_exec helper for dealing with deadlock
detection and backoff.
This will let us deal with upcoming locking order conflicts with the
VM_BIND implmentation (ie. in some scenarious we need
From: Rob Clark
This is a more descriptive name.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_g
From: Rob Clark
This submitqueue type isn't tied to a hw ringbuffer, but instead
executes on the CPU for performing async VM_BIND ops.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 12 +
drivers/gpu/drm/msm/msm_gem_submit.c | 60 +++---
drivers/gpu/d
From: Rob Clark
With user managed VMs and multiple queues, it is in theory possible to
trigger map/unmap errors. These will (in a later patch) mark the VM as
unusable. But we want to tell the io-pgtable helpers not to spam the
log. In addition, in the unmap path, we don't want to bail early fr
From: Rob Clark
Make the VM log a bit more useful by providing a reason for the unmap
(ie. closing VM vs evict/purge, etc)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 18 ++
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 15 +
From: Rob Clark
If we haven't written the submit into the ringbuffer yet, then drop it.
The submit still retires through the normal path, to preserve fence
signalling order, but we can skip the IB's to userspace cmdstream.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c| 1 +
Hi Tomi,
On Wed, Apr 16, 2025 at 02:06:29PM +0300, Tomi Valkeinen wrote:
> Currently when the driver's probe is called, we do a full DSS reset. If
> the bootloader has set up a splash-screen, the reset will disable the
> video output, and after that it may still take time until the display is
> us
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
> This commit adds a document section in drm-uapi.rst about
> tracepoints,
> and mark the events gpu_scheduler_trace.h as stable uAPI.
>
> The goal is to explicitly state that tools can rely on the fields,
> formats and semantics
Hi Nicolas,
Thanks for looking at this. Some thoughts below:
On Fri, Apr 25, 2025 at 8:50 PM Nicolas Frattaroli
wrote:
>
> On Tuesday, 25 February 2025 08:55:47 Central European Summer Time Tomeu
> Vizoso wrote:
> > Add the bindings for the Neural Processing Unit IP from Rockchip.
> >
> > v2:
>
From: Rob Clark
In situations where mapping/unmapping sequence can be controlled by
userspace, attempting to map over a region that has not yet been
unmapped is an error. But not something that should spam dmesg.
Now that there is a quirk, we can also drop the selftest_running
flag, and use the
From: Rob Clark
Only needs to be supported for iopgtables mmu, the other cases are
either only used for kernel managed mappings (where offset is always
zero) or devices which do not support sparse bindings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpummu.c | 5 -
drive
From: Rob Clark
Add a SET_PARAM for userspace to request to manage to the VM itself,
instead of getting a kernel managed VM.
In order to transition to a userspace managed VM, this param must be set
before any mappings are created.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_g
From: Rob Clark
Buffers that are not shared between contexts can share a single resv
object. This way drm_gpuvm will not track them as external objects, and
submit-time validating overhead will be O(1) for all N non-shared BOs,
instead of O(n).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm
From: Rob Clark
Add PRR (Partial Resident Region) is a bypass address which make GPU
writes go to /dev/null and reads return zero. This is used to implement
vulkan sparse residency.
To support PRR/NULL mappings, we allocate a page to reserve a physical
address which we know will not be used as
From: Rob Clark
In this case, we need to iterate the VMAs looking for ones with
MSM_VMA_DUMP flag.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 96 ++-
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c
From: Rob Clark
We'll be re-using these for the VM_BIND ioctl.
Also, rename a few things in the uapi header to reflect that syncobj use
is not specific to the submit ioctl.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/msm_gem_submit.c | 192 ++
From: Rob Clark
This resolves a potential deadlock vs msm_gem_vm_close(). Otherwise for
_NO_SHARE buffers msm_gem_describe() could be trying to acquire the
shared vm resv, while already holding priv->obj_lock. But _vm_close()
might drop the last reference to a GEM obj while already holding the
On Wednesday, 14 May 2025 17:18:22 Central European Summer Time Tomeu Vizoso
wrote:
> Hi Nicolas,
>
> Thanks for looking at this. Some thoughts below:
>
> On Fri, Apr 25, 2025 at 8:50 PM Nicolas Frattaroli
> wrote:
> >
> > On Tuesday, 25 February 2025 08:55:47 Central European Summer Time Tomeu
On 13.05.25 19:48, Liam R. Howlett wrote:
* David Hildenbrand [250512 08:34]:
The "memramp() shrinking" scenario no longer applies, so let's remove
that now-unnecessary handling.
Reviewed-by: Lorenzo Stoakes
Acked-by: Ingo Molnar # x86 bits
Signed-off-by: David Hildenbrand
small comment,
From: Rob Clark
See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
msm_gem_free_object()") for justification.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gpuvm.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/d
From: Rob Clark
Now that we've dropped vram carveout support, we can collapse vma
allocation and initialization. This better matches how things work
with drm_gpuvm.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 30 +++---
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
If userspace has opted-in to VM_BIND, then GPU hangs and VM_BIND errors
will mark the VM as unusable.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 17 +
drivers/gpu/drm/msm/msm_gem_submit.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c|
From: Rob Clark
We'll re-use this in the vm_bind path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 12 ++--
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem
From: Rob Clark
Add a VM_BIND ioctl for binding/unbinding buffers into a VM. This is
only supported if userspace has opted in to MSM_PARAM_EN_VM_BIND.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c|1 +
drivers/gpu/drm/msm/msm_drv.h|4 +-
drivers/gpu/drm/ms
From: Rob Clark
Any place we wait for a BO to become idle, we should use BOOKKEEP usage,
to ensure that it waits for _any_ activity.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +-
2 files changed, 4 insertions(+),
From: Rob Clark
It is standing in the way of drm_gpuvm / VM_BIND support. Not to
mention frequently broken and rarely tested. And I think only needed
for a 10yr old not quite upstream SoC (msm8974).
Maybe we can add support back in later, but I'm doubtful.
Signed-off-by: Rob Clark
---
drive
From: Rob Clark
Bump version to signal to userspace that VM_BIND is supported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bdf775897de8..7100
From: Rob Clark
Most of the driver code doesn't need to reach in to msm specific fields,
so just use the drm_gpuvm/drm_gpuva types directly. This should
hopefully improve commonality with other drivers and make the code
easier to understand.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/ad
From: Rob Clark
In the next commit, a way for userspace to opt-in to userspace managed
VM is added. For this to work, we need to defer creation of the VM
until it is needed.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c
Hi Dave, Simona,
Fixes for 6.15.
The following changes since commit 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3:
Linux 6.15-rc6 (2025-05-11 14:54:11 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.15-2025-05-14
for you to fe
Introduce DMA_BUF_IOCTL_RW_FILE ioctl for direct file I/O on dma-buf objects.
CURRENT WORKFLOW:
1. Allocate dma-buf:
dmabuf_fd = dmabuf_alloc(len, heap_fd)
2. Map memory:
vaddr = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, dmabuf_fd, 0)
3. File operations:
file_fd = open(file_path,
On Wed, 14 May 2025, "feijuan.li" wrote:
> When DP connected to a device with HDR capability,
> the hdr structure was filled.Then connected to another
> sink device without hdr capability, but the hdr info
> still exist.
>
> Signed-off-by: feijuan.li
Reviewed-by: Jani Nikula
> ---
> drivers/
On 12/05/2025 13:49, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first
time
to see if there are any jobs, free a single job, and then lock again
to
decide whether to re-queue itself if there are
Hi Amir,
On Mon, Apr 28, 2025 at 11:06:26PM -0700, Amirreza Zarrabi wrote:
> Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in
> the secure world, accessed via objects. A QTEE client can invoke these
> objects to request services. Similarly, QTEE can request services from
> the
On Tue, May 13, 2025 at 01:03:15PM +0300, Zhi Wang wrote:
> On Mon, 12 May 2025 11:06:17 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
> >
> > > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff,
> > > > > it is just abo
On Mon, May 12, 2025 at 11:06:17AM -0300, Jason Gunthorpe wrote:
> On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote:
>
> > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is
> > > > just about managing the translation control of the device.
> > >
> > > I h
This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6.
Some eDP panels support HBR3 but not TPS4 and rely on a fixed mode that
requires HBR3. After the original commit, these panels go blank due to
the rejection of HBR3.
To restore functionality for such panels, this commit reverts the cha
On 12/05/2025 09:00, Philipp Stanner wrote:
On Thu, 2025-05-08 at 13:51 +0100, Tvrtko Ursulin wrote:
Hi Philipp,
On 08/05/2025 12:03, Philipp Stanner wrote:
On Thu, 2025-04-24 at 11:55 +0200, Philipp Stanner wrote:
The unit tests so far took care manually of avoiding memory leaks
that
migh
On 12/05/2025 13:56, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
To implement fair scheduling we will need as accurate as possible
view
into per entity GPU time utilisation. Because sched fence execution
time
are only adjusted for accuracy in the free worker
On 05/07/2025, Liu Ying wrote:
> Hi Maxime, drm/misc maintainers,
>
> On 04/14/2025, Liu Ying wrote:
>> Hi,
>>
>> This patch series aims to add Freescale i.MX8qxp Display Controller support.
>>
>> The controller is comprised of three main components that include a blit
>> engine for 2D graphics ac
On 12/05/2025 13:57, Matthew Brost wrote:
On Mon, May 12, 2025 at 02:49:55PM +0200, Philipp Stanner wrote:
On Fri, 2025-04-25 at 11:20 +0100, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first
time
to see if there are any jobs, free a single job, and t
On 5/13/25 6:06 AM, Byungchul Park wrote:
llist_head and llist_node can be used by very primitives. For example,
I suppose you mean "every primitives". Right? However, the term
"primitive" may sound strange. Maybe just saying that it is used by some
other header files.
Cheers,
Longman
dep
On Thu, 15 May 2025 at 02:52, Jessica Zhang
wrote:
>
> Since the max mixer width is not a strict hardware limit, use the actual
Is it? What is the actual max width that the mixer can support?
> hardware limit (the writeback maxlinewidth) to filter modes.
>
> Signed-off-by: Jessica Zhang
> ---
>
On Wed, May 14, 2025 at 04:52:31PM -0700, Jessica Zhang wrote:
> Validate requested mode and topology based on the PINGPONG or DSC encoder
> max width. In addition, drop MAX_HDISPLAY_SPLIT and base LM reservation
> off of PINGPONG or DSC encoder max width
Separate commit for num_lm, please.
>
>
On Wed, May 14, 2025 at 04:52:33PM -0700, Jessica Zhang wrote:
> Remove the now-unused max_mixer_width field from the HW catalog
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h | 1 -
> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_1_14_msm8937.h | 1
On Wed, May 14, 2025 at 04:52:29PM -0700, Jessica Zhang wrote:
> Drop the unused maxwidth field from the dpu_lm_sub_blks struct
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 -
> 2 files chan
On Thu, May 15, 2025 at 02:17:27AM +0530, ALOK TIWARI wrote:
>
>
> > + * DEPT(DEPendency Tracker) - Runtime dependency tracker
> > + *
> > + * Started by Byungchul Park :
> > + *
> > + * Copyright (c) 2020 LG Electronics, Inc., Byungchul Park
> > + *
> > + * DEPT provides a general way to detect
> I have to admit I'm pretty clueless about the gpu driver internals and
> can't really judge how feasible this is. But from a cgroup POV, if you
> want proper memory isolation between groups, it seems to me that's the
> direction you'd have to take this in.
Thanks for this insight, I think you ha
On Wed, May 14, 2025 at 08:14:26PM -0400, Waiman Long wrote:
> On 5/13/25 6:06 AM, Byungchul Park wrote:
> > llist_head and llist_node can be used by very primitives. For example,
>
> I suppose you mean "every primitives". Right? However, the term "primitive"
> may sound strange. Maybe just saying
Drop the unused maxwidth field from the dpu_lm_sub_blks struct
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalo
Hi, Dave & Daniel:
This includes:
1. Prepare for support MT8195/88 HDMIv2 and DDCv2
2. DPI: Cleanups and add support for more formats
3. Cleanups and sanitization
4. Replace custom compare_dev with component_compare_of
Regards,
Chun-Kuang.
The following changes since commit 0af2f6be1b4281385b618
On 14/05/2025 14:57, Rob Clark wrote:
On Wed, May 14, 2025 at 3:01 AM Tvrtko Ursulin
wrote:
On 13/05/2025 15:16, Rob Clark wrote:
On Fri, May 9, 2025 at 8:34 AM Tvrtko Ursulin wrote:
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to user
On Sun, 11 May 2025 22:31:18 +1200, Ryan Walklin wrote:
> From: Jernej Skrabec
>
> The vi_scaler appears to be used in preference to the ui_scaler module
> for hardware video scaling in the DE33.
>
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Wed, 14 May 2025 at 11:37, Sumit Garg wrote:
>
> Hi Amir,
>
> I am still unable to get the QCOMTEE driver to work on db845c. As I can
> see machine: "qcom,sdm845" is not supported for tzmem based on SHM
> brigde here: drivers/firmware/qcom/qcom_tzmem.c +81. I am still seeing
> following logs fr
On 5/14/25 5:10 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Add a file that will serve as a single source of truth for UBWC
> configuration data for various multimedia blocks.
>
> Signed-off-by: Konrad Dybcio
> ---
> +static const struct qcom_ubwc_cfg_data sar2130p_data = {
So I failed
On Tue, 06 May 2025 12:27:17 +0300, Svyatoslav Ryhel wrote:
> R69328 is liquid crystal driver for high-definition amorphous silicon
> (a-Si) panels and is ideal for tablets and smartphones.
>
> Signed-off-by: Svyatoslav Ryhel
> ---
> .../display/panel/renesas,r69328.yaml | 73 +
Hey,
On 2025-05-14 13:55, Christian König wrote:
> On 5/14/25 13:41, Maarten Lankhorst wrote:
>> Hi Dave,
>>
>> We've had a small discussion on irc, so I wanted to summarize it here:
>>
>> All memory allocated should be accounted, even memory that is being
>> evicted from VRAM.
>
> That sounds li
From: Rob Clark
This is a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 +--
drivers/g
From: Rob Clark
Eases migration for drivers where VAs don't hold hard references to
their associated BO, avoiding reference loops.
In particular, msm uses soft references to optimistically keep around
mappings until the BO is distroyed. Which obviously won't work if the
VA (the mapping) is hold
>
> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
>
> This is why GPUVM never takes locks by itself, but asserts that the correct
> lock
> is held.
>
> I think we really want to get proof by the driver by providing lock guard
> references.
Hi Dmitry,
It turned out that attaching backing during restoring process was skipped due to
obj->attach == true condition, which is the reason for the err messages you
reported.
I had tested my patch on slightly older virtio-gpu driver that didn't have this
flag
(was added by one of your commits
Hi,
Siqueira and I have been working on a solution to reduce the usage of
drm_edid_raw in the AMD display driver, since the current guideline in
the DRM subsystem is to stop handling raw edid data in driver-specific
implementation and use opaque `drm_edid` object with common-code
helpers.
In shor
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 18 +++
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
.../drm/amd/d
There is an opaque obj in Linux/DRM to encapsulate edid data as
`drm_edid`. This obj isn't present in other platforms but we need to
pass it through DC when adding sink. To pass this data without
compromise the independence of DC code, make some DC functions accept
edid data as private options.
Si
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
Original drm_edid_get_monitor_name encapsulates raw edid in drm_edid and
then call get_monitor_name. AMD still stores the display name for
debugging, but it is migrating to drm_edid, on the other hand,
drm_dp_mst_topology and sil-sii8620 still use the raw edid version.
Split drm_edid_get_monitor_n
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/d
Groundwork that allocates a temporary drm_edid from raw edid to take
advantage of DRM common-code helpers instead of driver-specific code.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15
Make sure the drm_edid container stored in aconnector is freed when
destroying the aconnector.
Fixes: 48edb2a4 ("drm/amd/display: switch amdgpu_dm_connector to use struct
drm_edid")
Reviewed-by: Mario Limonciello
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On 5/14/25 9:24 PM, Dmitry Baryshkov wrote:
> On Wed, May 14, 2025 at 05:10:34PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio
>>
>> Make the values a bit more meaningful.
>
> Not sure if it's more meaningful or not. In the end, we all can read hex
> masks.
0x1d7efc35
magic constants are n
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
v3:
- remove uneccessary include (jani)
- use dc_edid_sink_edid_free in link_detection
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
v3:
- remove superfulous cast (jani)
Signed-off-by: Rodrigo Siqueira
Co-developer--by: Melissa W
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
v3:
- rebase on top of asdn
Signed-off-by: Rodrigo Siqueira
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it available at the DRM level
by wrapping exi
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.h | 1 +
On Wed, May 14, 2025 at 10:09:35PM +0200, Konrad Dybcio wrote:
> On 5/14/25 9:24 PM, Dmitry Baryshkov wrote:
> > On Wed, May 14, 2025 at 05:10:34PM +0200, Konrad Dybcio wrote:
> >> From: Konrad Dybcio
> >>
> >> Make the values a bit more meaningful.
> >
> > Not sure if it's more meaningful or not
On 14/05/2025 17:19, Melissa Wen wrote:
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/
On 14/05/2025 23:05, Konrad Dybcio wrote:
On 5/14/25 9:23 PM, Dmitry Baryshkov wrote:
On Wed, May 14, 2025 at 05:10:33PM +0200, Konrad Dybcio wrote:
From: Konrad Dybcio
The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
swizzling) is what we want on this platform (and others
On Wed, May 14, 2025 at 05:10:32PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> On A663 (SA8775P) the value matches exactly.
>
> On A610, the value matches on SM6115, but is different on SM6125. That
> turns out not to be a problem, as the bits that differ aren't even
> interpreted.
We
Make use of the drm_bridge::driver_private data instead of
container_of() wrapper.
No functional changes.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/fsl-ldb.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c b/driver
Hi,
just a small series to cleanup the fsl-ldb lvds bridge driver a bit.
Regards,
Marco
Marco Felsch (3):
drm/bridge: fsl-ldb: make use of driver_private
drm/bridge: fsl-ldb: make use of dev_err_probe
drm/bridge: fsl-ldb: simplify device_node error handling
drivers/gpu/drm/bridge/fsl-ldb
1 - 100 of 244 matches
Mail list logo