Hi,
At 2025-04-25 02:59:10, "Luca Ceresoli" wrote:
>This is the new API for allocating DRM bridges.
>
>Signed-off-by: Luca Ceresoli
Reviewed-by: Andy Yan
>
>---
>
>Cc: "Uwe Kleine-König"
>Cc: Andy Yan
>Cc: Dmitry Baryshkov
>Cc: Jani Nikula
>Cc: Sui Jingfeng
>---
> drivers/gpu/drm/bridge
The generic FourCC format always prints the data using the big endian
order. It is generic because it allows to read the data using a custom
ordering.
The current code uses "n" for reading data in the reverse host ordering.
It makes the 4 variants [hnbl] consistent with the generic printing
of IPv
Hi ,
At 2025-04-25 02:59:08, "Luca Ceresoli" wrote:
>devm_drm_bridge_alloc() is the new API to be used for allocating (and
>partially initializing) a private driver struct embedding a struct
>drm_bridge.
>
>For many drivers having a simple code flow in the probe function, this
>commit does a mass
On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote:
> On Mon, 28 Apr 2025 at 09:45, Johan Hovold wrote:
> > On Thu, Apr 17, 2025 at 04:10:31AM +0200, Aleksandrs Vinarskis wrote:
> > > Recently added Initial LTTPR support in msm/dp has configured LTTPR(s)
> > > to non-transparent
On 4/24/25 09:07, Tvrtko Ursulin wrote:
>
> On 23/04/2025 14:12, Christian König wrote:
>> On 4/18/25 18:42, Tvrtko Ursulin wrote:
>>> Hi all,
>>>
>>> Recently I mentioned to Danilo about some fence lifetime issues so here is a
>>> rough series, more than anything intended to start the discussion.
From: Andy Yan
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Note: I don't have the hardware to test this driver, so for now
I can only do the compilation test.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rk3
On Mon, 28 Apr 2025 09:32:21 +0200
Krzysztof Kozlowski wrote:
> On Thu, Apr 24, 2025 at 05:07:39PM GMT, Kory Maincent wrote:
> > Faced a binding error check while adding the data-lanes property in the
> > ilitek,ili9881c binding. See the next patch for the binding changes.
> > Here is the error:
On 4/23/25 23:37, Dave Airlie wrote:
> Hey,
>
> I've been tasked to look into this, and I'm going start from hopeless
> naivety and see how far I can get. This is an initial attempt to hook
> TTM system memory allocations into memcg and account for them.
Yeah, this looks mostly like what we had a
On 4/14/2025 4:31 PM, Konrad Dybcio wrote:
> On 2/27/25 9:07 PM, Akhil P Oommen wrote:
>> From: Jie Zhang
>>
>> Add gpu and gmu nodes for qcs8300 chipset.
>>
>> Signed-off-by: Jie Zhang
>> Signed-off-by: Akhil P Oommen
>> ---
>
> [...]
>
>> +gmu: gmu@3d6a000 {
>> +
-Original Message-
From: Hirschfeld, Dafna
Sent: Sunday, April 27, 2025 4:57 AM
To: Cavitt, Jonathan
Cc: intel-xe@listxe_uc_fw_types.hs.freedesktop.org; Gupta, saurabhg
; Zuo, Alex ;
joonas.lahti...@linux.intel.com; Brost, Matthew ;
Zhang, Jianxun ; Lin, Shuicheng
; dri-devel@lists.f
On 25-04-28 14:47:04, Johan Hovold wrote:
> On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote:
> > On Mon, 28 Apr 2025 at 09:45, Johan Hovold wrote:
> > > On Thu, Apr 17, 2025 at 04:10:31AM +0200, Aleksandrs Vinarskis wrote:
> > > > Recently added Initial LTTPR support in msm/dp
On 2025-04-26 21:25, liu.son...@zte.com.cn wrote:
From: Xuemei Liu
KFD has been confirmed that can run on RISCV systems. It's necessary to
support CONFIG_HSA_AMD on RISCV.
Is there a public user mode branch with any changes needed to make ROCm
user mode work with RISCV?
One more question i
On 4/28/2025 12:47 AM, Jacek Lawrynowicz wrote:
Hi,
On 4/25/2025 7:22 PM, Jeff Hugo wrote:
On 4/25/2025 3:36 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
The mutex unlock for vdev->submitted_jobs_lock was incorrectly placed
after unlocking file_priv->lock. Change order of unlocks to av
Hi Danilo,
On Tue Apr 22, 2025 at 7:29 PM JST, Danilo Krummrich wrote:
> On Sun, Apr 20, 2025 at 09:19:38PM +0900, Alexandre Courbot wrote:
>> Add the register!() macro, which defines a given register's layout and
>> provide bit-field accessors with a way to convert them to a given type.
>> This m
On 4/24/25 15:02, Philipp Stanner wrote:
> In nouveau_fence_done(), a fence is checked for being signaled by
> manually evaluating the base fence's bits. This can be done in a
> canonical manner through dma_fence_is_signaled().
>
> Replace the bit-check with dma_fence_is_signaled().
>
> Signed-of
On 4/24/25 15:02, Philipp Stanner wrote:
> nouveau_fence_done() contains an if branch that checks whether a
> nouveau_fence has either of the two existing nouveau_fence backend ops,
> which will always evaluate to true.
>
> Remove the surplus check.
>
> Signed-off-by: Philipp Stanner
Reviewed-
Hi John,
On Fri, Apr 25, 2025 at 12:39:40PM -0700, John Stultz wrote:
> On Thu, Apr 24, 2025 at 11:58 PM Maxime Ripard wrote:
> > On Thu, Apr 24, 2025 at 05:13:47PM -0700, John Stultz wrote:
> > > On Thu, Apr 24, 2025 at 1:34 AM Maxime Ripard wrote:
> > > > I appreciate this is kind of bikeshed-
On 4/24/25 15:40, Alex Deucher wrote:
> On Wed, Apr 23, 2025 at 10:29 AM Christian König
> wrote:
>>
>> On 4/22/25 18:26, Deucher, Alexander wrote:
>>> [Public]
>>>
-Original Message-
From: Alex Deucher
Sent: Tuesday, April 22, 2025 9:46 AM
To: Koenig, Christian
What it does on PAT (only implementation so far ...) is looking up the
memory type to select the caching mode that can be use.
"sanitize" was IMHO a good fit, because we must make sure that we don't use
the wrong caching mode.
update/setup/... don't make that quite clear. Any other suggestion
Hallo Andy,
On Mon, 28 Apr 2025 20:44:03 +0800 (CST)
"Andy Yan" wrote:
> Hi ,
>
> At 2025-04-25 02:59:08, "Luca Ceresoli" wrote:
> >devm_drm_bridge_alloc() is the new API to be used for allocating (and
> >partially initializing) a private driver struct embedding a struct
> >drm_bridge.
> >
> >
From: Arnd Bergmann
The newly added driver calls drm_client_setup(), but that is not
always built in:
x86_64-linux-ld: vmlinux.o: in function `st7571_probe':
st7571-i2c.c:(.text+0x7b7119): undefined reference to `drm_client_setup'
Select the appropriate Kconfig symbol.
Fixes: 4b35f0f41ee2 ("dr
Hi,
On 04/25/2025, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> This driver embeds an array of channels in the main struct, and each
> channel embeds a drm_bridge. This prevents dynamic, refcount-based
> deallocation of the bridges.
>
> To make the new, dynamic brid
On 04/25/2025, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> These two drivers are tangled together by the ldb_add_bridge_helper(), so
> they are converted at once.
>
> They also have a similar design, each embedding an array of channels in
> their main struct, and ea
Hi,
On 04/25/2025, Luca Ceresoli wrote:
> devm_drm_bridge_alloc() is the new API to be used for allocating (and
> partially initializing) a private driver struct embedding a struct
> drm_bridge.
>
> For many drivers having a simple code flow in the probe function, this
> commit does a mass conver
On 3/1/2025 1:24 AM, Dmitry Baryshkov wrote:
The SDM630 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask, replacing PINGPONG_SDM845_MASK with
BIT(DPU_PINGPONG_DITHER).
Fixes: 7204df5e7
On 25-04-28 20:23:45, Aleksandrs Vinarskis wrote:
> On Mon, 28 Apr 2025 at 16:17, Abel Vesa wrote:
> >
> > The change itself makes sense though and I think makes sense to be marked
> > as a fix.
>
> Just to confirm, you mean to mark as fix only the 1st patch, correct?
> Since it's obvious now th
For drivers that can transfer data to the TEE without using shared
memory from client, it is necessary to receive the user address
directly, bypassing any processing by the TEE subsystem. Introduce
TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT/OUTPUT/INOUT to represent
userspace buffers.
Signed-off-by: Ami
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 nonsecure world using objects exported to the secure world.
Add low-level primitive
The tee_context can be used to manage TEE user resources, including
those allocated by the driver for the TEE on behalf of the user.
The release() callback is invoked only when all resources, such as
tee_shm, are released and there are no references to the tee_context.
When a user closes the devic
The TEE subsystem allows session-based access to trusted services,
requiring a session to be established to receive a service. This
is not suitable for an environment that represents services as objects.
An object supports various operations that a client can invoke,
potentially generating a result
This patch series introduces a Trusted Execution Environment (TEE)
driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs)
and services to run securely. It uses an object-based interface, where
each service is an object with sets of operations. Clients can invoke
these operations on
A TEE driver doesn't always need to provide a pool if it doesn't
support memory sharing ioctls and can allocate memory for TEE
messages in another way. Although this is mentioned in the
documentation for tee_device_alloc(), it is not handled correctly.
Reviewed-by: Sumit Garg
Signed-off-by: Amirr
shm_bridge create/delete functions always use the scm device.
There is no need to pass it as an argument.
Signed-off-by: Amirreza Zarrabi
---
drivers/firmware/qcom/qcom_scm.c | 4 ++--
drivers/firmware/qcom/qcom_tzmem.c | 8
include/linux/firmware/qcom/qcom_scm.h | 4 ++--
3 f
Introduce qcomtee_object, which represents an object in both QTEE and
the kernel. QTEE clients can invoke an instance of qcomtee_object to
access QTEE services. If this invocation produces a new object in QTEE,
an instance of qcomtee_object will be returned.
Similarly, QTEE can request services fr
Enable userspace to allocate shared memory with QTEE. Since
QTEE handles shared memory as object, a wrapper is implemented
to represent tee_shm as an object. The shared memory identifier,
obtained through TEE_IOC_SHM_ALLOC, is transferred to the driver using
TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT/O
Add documentation for the Qualcomm TEE driver.
Signed-off-by: Amirreza Zarrabi
---
Documentation/tee/index.rst | 1 +
Documentation/tee/qtee.rst | 150
MAINTAINERS | 1 +
3 files changed, 152 insertions(+)
diff --git a/Documentat
Anyone with access to contiguous physical memory should be able to
share memory with QTEE using shm_bridge.
Signed-off-by: Amirreza Zarrabi
---
drivers/firmware/qcom/qcom_tzmem.c | 57 +---
include/linux/firmware/qcom/qcom_tzmem.h | 15 +
2 files changed
After booting, the kernel provides a static object known as the
primordial object. This object is utilized by QTEE for native
kernel services such as yield or privileged operations.
Signed-off-by: Amirreza Zarrabi
---
drivers/tee/qcomtee/Makefile | 1 +
drivers/tee/qcomtee/core.c
On 28/04/2025 20:13, barnabas.cze...@mainlining.org wrote:
>>
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - reset-gpios
>>
>> No supplies? This looks really incomplete.
> It works without supplies because BL is enabling them and there is no
> qpnp-lcdb driver yet.
If something en
Hello Geert,
On Thu, Apr 24, 2025 at 10:38:33AM +0200, Geert Uytterhoeven wrote:
[...]
> > + /*
> > +* As the display supports grayscale, all pixels
> > must be written as two bits
> > +* even if the format is monochrome.
> >
Hi,
On 28/04/2025 12:40, Vitor Soares wrote:
From: Vitor Soares
The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks
for both runtime PM and system sleep. This causes the DSI clocks to be
disabled twice: once during runtime suspend and again during system
suspend, resulting
[AMD Official Use Only - AMD Internal Distribution Only]
Ping ?
-Original Message-
From: Sunil Khatri
Sent: Thursday, April 17, 2025 3:55 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Tvrtko Ursulin ;
Pelloux-Prayer,
Catching up after spring break, hence the late reply ...
On Fri, Apr 11, 2025 at 02:34:37PM -0400, Nicolas Dufresne wrote:
> Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> > There is no way to transmit the DMA address of a buffer to userspace.
> > Some UIO users need this to h
Hi Marcus,
On Tue, 29 Apr 2025 at 08:15, Marcus Folkesson
wrote:
> On Thu, Apr 24, 2025 at 10:38:33AM +0200, Geert Uytterhoeven wrote:
>
> [...]
>
> > > + /*
> > > +* As the display supports grayscale, all pixels
> > > must be written as two bits
> >
On 8/1/25 01:27, Xu Yilun wrote:
This series is based on an earlier kvm-coco-queue version (v6.12-rc2)
Has this been pushed somewhere public? The patchset does not apply on top of
v6.12-rc2, for example (I fixed locally).
Also, is there somewhere a QEMU tree using this? I am trying to use this
On Mon, Apr 28, 2025 at 07:12:11PM +0200, David Hildenbrand wrote:
>
> > >
> > > +int pfnmap_track(unsigned long pfn, unsigned long size, pgprot_t *prot)
> > > +{
> > > + const resource_size_t paddr = (resource_size_t)pfn << PAGE_SHIFT;
> > > +
> > > + return reserve_pfn_range(paddr, size, prot, 0)
On 3/6/2025 10:24 PM, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov
In case of complex pipelines (e.g. the forthcoming quad-pipe) the DPU
might use more that one MERGE_3D block for a single output. Follow the
pattern and extend the CTL_MERGE_3D_ACTIVE active register instead of
simply writ
Hi,
On Mon, Apr 21, 2025 at 4:36 AM Zhengqiao Xia
wrote:
>
> AUO B140QAN08.H EDID:
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 06 af b9 fe 00 00 00 00
> 00 23 01 04 a5 1e 13 78 03 c1 45 a8 55 48 9d 24
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 18 86 40 a0 b0 08 52
Hi,
On Mon, Apr 21, 2025 at 4:37 AM Zhengqiao Xia
wrote:
>
> CSW MNE007QS3-8 EDID:
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 0e 77 57 14 00 00 00 00
> 34 22 01 04 a5 1e 13 78 07 ee 95 a3 54 4c 99 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 cd 7c 80 a0 70 b0 50
Hi,
On Mon, Apr 21, 2025 at 4:37 AM Zhengqiao Xia
wrote:
>
> BOE NE140WUM-N6S EDID:
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 09 e5 73 0d 00 00 00 00
> 32 22 01 04 a5 1e 13 78 07 13 45 a6 54 4d a0 27
> 0c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 03 3e 80 a0 70 b0 48
+cc Suren, who has worked HEAVILY on VMA field manipulation and such :)
Suren - David is proposing adding a new field. AFAICT this does not add a
new cache line so I think we're all good.
But FYI!
On Fri, Apr 25, 2025 at 10:17:09AM +0200, David Hildenbrand wrote:
> Let's use our new interface. I
On Mon, Apr 28, 2025 at 12:34:27PM -0700, Linus Torvalds wrote:
> Honestly, the least wrong thing is to just NOT HAVE THE CHECK FOR ZERO AT ALL.
>
> IOW, just generate the divide instruction.
>
> I can almost guarantee that that will actually then generate the best
> code too, because you'll prob
On Mon, Apr 28, 2025 at 12:37 PM Lorenzo Stoakes
wrote:
>
> On Mon, Apr 28, 2025 at 07:23:18PM +0200, David Hildenbrand wrote:
> > On 28.04.25 18:24, Peter Xu wrote:
> > > On Mon, Apr 28, 2025 at 06:16:21PM +0200, David Hildenbrand wrote:
> > > > > Probably due to what config you have. E.g., when
On Mon, Apr 28, 2025 at 12:47 PM Lorenzo Stoakes
wrote:
>
> +cc Suren, who has worked HEAVILY on VMA field manipulation and such :)
>
> Suren - David is proposing adding a new field. AFAICT this does not add a
> new cache line so I think we're all good.
>
> But FYI!
Thanks! Yes, there should be s
Hi,
On Sun, Apr 20, 2025 at 9:26 PM Nick Bowler wrote:
>
> Hi,
>
> I recently noticed that on current kernels I lose video output from
> my Blackbird's AST2500 BMC after a reboot, which makes it difficult to
> boot the system again (the video output will come on only after Linux
> is booted again
On 28.04.25 18:21, Peter Xu wrote:
On Mon, Apr 28, 2025 at 04:58:46PM +0200, David Hildenbrand wrote:
What it does on PAT (only implementation so far ...) is looking up the
memory type to select the caching mode that can be use.
"sanitize" was IMHO a good fit, because we must make sure that w
Hi,
On Thu, Apr 24, 2025 at 12:00 PM Luca Ceresoli
wrote:
>
> This is the new API for allocating DRM bridges.
>
> Reviewed-by: Herve Codina
> Signed-off-by: Luca Ceresoli
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by:
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
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
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
In situations where mapping/unmapping squence 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.
Signed-off-by: Rob Clark
---
drivers/iommu/io-pgtable-arm.c | 18
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
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
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
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
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
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
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
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
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
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
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
As with devcoredump, we need to iterate the VMAs to figure out what to
dump.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drive
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
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
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
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
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
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
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
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
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
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
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
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
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(+),
On Mon, 28 Apr 2025 at 12:54, Josh Poimboeuf wrote:
>
> BTW, I've noticed Clang also generates UB for negative shift values. I
> assume we'd want it to stop checking for those as well.
Yeah, that seems to match the exact same issue.
And again - the correct fix would be for the compiler to not d
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/msm/
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 a63442039e22..4117
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
On Mon, Apr 28, 2025 at 12:34 PM Linus Torvalds
wrote:
>
> On Mon, 28 Apr 2025 at 11:08, Bill Wendling wrote:
> >
> > This situation is one of the
> > easier ones: "do something other than fall into the next function";
>
> Note that the "fall into the next function" is just something that
> objto
On Fri, Apr 25, 2025 at 10:36:55PM +0200, David Hildenbrand wrote:
> On 25.04.25 22:23, Peter Xu wrote:
> > On Fri, Apr 25, 2025 at 10:17:09AM +0200, David Hildenbrand wrote:
> > > Let's use our new interface. In remap_pfn_range(), we'll now decide
> > > whether we have to track (full VMA covered)
On Fri, Apr 25, 2025 at 10:17:07AM +0200, David Hildenbrand wrote:
> Let's provide variants of track_pfn_remap() and untrack_pfn() that won't
> mess with VMAs, to replace the existing interface step-by-step.
>
> Add some documentation.
>
> Signed-off-by: David Hildenbrand
There's some pedantry be
On Fri, Apr 25, 2025 at 04:00:42PM -0400, Peter Xu wrote:
> On Fri, Apr 25, 2025 at 10:17:08AM +0200, David Hildenbrand wrote:
> > Let's use the new, cleaner interface.
> >
> > Signed-off-by: David Hildenbrand
> > ---
> > mm/memremap.c | 8
> > 1 file changed, 4 insertions(+), 4 deletion
Reviewed-by: Alyssa Rosenzweig
Le Mon , Apr 28, 2025 at 01:37:14PM +0200, Janne Grunau via B4 Relay a écrit :
> From: Janne Grunau
>
> drm_crtc_vblank_get() may fail when it's called before
> drm_crtc_vblank_on() on a resetted CRTC. This occurs in
> drm_crtc_helper_funcs' atomic_flush() calls a
Acked-by: Alyssa Rosenzweig
Since the other patches went thru drm-misc-next, I guess this should
too?
Le Mon , Apr 28, 2025 at 02:31:32PM +0200, Petr Mladek a écrit :
> The generic FourCC format always prints the data using the big endian
> order. It is generic because it allows to read the dat
Hi,
On Thu, Apr 24, 2025 at 3:47 AM Jayesh Choudhary wrote:
>
> Hello Doug,
>
> On 17/04/25 02:40, Jayesh Choudhary wrote:
> > Hello Doug,
> >
> > On 13/04/25 07:22, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Fri, Apr 11, 2025 at 2:23 AM Jayesh Choudhary
> >> wrote:
> >>>
> >>> Enable NO_EOT and
On Sat, Apr 26, 2025 at 5:31 PM Linus Torvalds
wrote:
> So please. Clang people need to get a clue. Yes, we care *deeply*
> about performance in the kernel, but a C compiler that thinks that
> using UD to generate "better" code is a disgrace and pure garbage.
> Because security matters a whole lot
101 - 200 of 219 matches
Mail list logo
