Enable the Microchip's DSI controller wrapper driver that uses
the Synopsys DesignWare MIPI DSI host controller bridge for
sam9x7 SoC family.
Signed-off-by: Manikandan Muralidharan
---
changes in v6:
- Rewrite commit message
---
arch/arm/configs/at91_dt_defconfig | 1 +
1 file changed, 1 inserti
Add the 'sam9x75-mipi-dsi' compatible binding, which describes the
Microchip's specific wrapper for the Synopsys DesignWare MIPI DSI HOST
Controller for the sam9x75 series System-on-Chip (SoC) devices.
Signed-off-by: Manikandan Muralidharan
Reviewed-by: Conor Dooley
---
changes in v5:
- Add revi
This patch series adds support for the Microchip's MIPI DSI Controller
wrapper driver that uses the Synopsys DesignWare MIPI DSI host controller
bridge for SAM9X75 SoC series.
Changelogs are available in respective patches.
Manikandan Muralidharan (4):
dt-bindings: display: bridge: add sam9x75-
Add the Microchip's DSI controller wrapper driver that uses the
Synopsys DesignWare MIPI DSI host controller bridge for the SAM9X7
SoC series to the MAINTAINERS entry.
Signed-off-by: Manikandan Muralidharan
---
changes in v3:
- Drop T: section
---
MAINTAINERS | 7 +++
1 file changed, 7 inser
Add the Microchip's DSI controller wrapper driver that uses
the Synopsys DesignWare MIPI DSI host controller bridge.
Signed-off-by: Manikandan Muralidharan
---
changes in v6:
- Fixed warning reported by Kernel test robot
changes in v4:
- Fixed issues reported by kernel test robot
- replaced sysc
This series adds a new driver for the NPU that Rockchip includes in its
newer SoCs, developed by them on the NVDLA base.
In its current form, it supports the specific NPU in the RK3588 SoC.
The userspace driver is part of Mesa and an initial draft can be found at:
https://gitlab.freedesktop.org/
From: Nicolas Frattaroli
The NPU on the ROCK5B uses the same regulator for both the sram-supply
and the npu's supply. Add this regulator, and enable all the NPU bits.
Also add the regulator as a domain-supply to the pd_npu power domain.
Signed-off-by: Nicolas Frattaroli
Signed-off-by: Tomeu Viz
Enable the nodes added in a previous commit to the rk3588s device tree.
v2:
- Split nodes (Sebastian Reichel)
- Sort nodes (Sebastian Reichel)
- Add board regulators (Sebastian Reichel)
Signed-off-by: Tomeu Vizoso
---
.../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 30 +
Using the DRM GPU scheduler infrastructure, with a scheduler for each
core.
Userspace can decide for a series of tasks to be executed sequentially
in the same core, so SRAM locality can be taken advantage of.
The job submission code was initially based on Panfrost.
v2:
- Remove hardcoded number
See Chapter 36 "RKNN" from the RK3588 TRM (Part 1).
The IP is divided in three cores, programmed independently. The first
core though is special, being able to delegate work to the other cores.
The IOMMU of the first core is also special in that it has two subunits
(read/write?) that need to be p
From: Nicolas Frattaroli
The NPU of the RK3588 has an external supply. This supply also affects
the power domain of the NPU, not just the NPU device nodes themselves.
Since correctly modelled boards will want the power domain to be aware
of the regulator so that it doesn't always have to be on, a
Add the bindings for the Neural Processing Unit IP from Rockchip.
v2:
- Adapt to new node structure (one node per core, each with its own
IOMMU)
- Several misc. fixes from Sebastian Reichel
v3:
- Split register block in its constituent subblocks, and only require
the ones that the kernel woul
This initial version supports the NPU as shipped in the RK3588 SoC and
described in the first part of its TRM, in Chapter 36.
This NPU contains 3 independent cores that the driver can submit jobs
to.
This commit adds just hardware initialization and power management.
v2:
- Split cores and IOMMUs
The NPU cores have their own access to the memory bus, and this isn't
cache coherent with the CPUs.
Add IOCTLs so userspace can mark when the caches need to be flushed, and
also when a writer job needs to be waited for before the buffer can be
accessed from the CPU.
Initially based on the same IO
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
v2:
- Sync the IOMMUs for the other cores when mapping and unmapping.
v3:
- Make use of GPL-2.0-only for the copyright notice (Jeff Hugo)
v6:
- Use mutexes guard
Hi Andrew,
> Subject: Re: [PATCH v3 1/3] mm/hugetlb: Make hugetlb_reserve_pages()
> return nr of entries updated
>
> On Tue, 20 May 2025 22:19:35 -0700 Vivek Kasireddy
> wrote:
>
> > Currently, hugetlb_reserve_pages() returns a bool to indicate whether
> > the reservation map update for the ran
Hi Linus,
This is pretty much 2 weeks worth of fixes, plus one thing that might
be considered next.
amdkfd is now able to be enabled on risc-v platforms.
Otherwise, amdgpu and xe with the majority of fixes, and then a
smattering all over, just realised I forgot the nouveau fix in the
signed tag,
On Wed, 4 Jun 2025 12:48:49 +0530 Ayushi Makhija
wrote:
> This series enables the support for DSI to DP bridge ports
> (labled as DSI0 and DSI1) of the Qualcomm's SA8775P Ride platform.
>
> SA8775P SoC has DSI controller v2.5.1 and DSI PHY v4.2.
> The Ride platform is having ANX7625 DSI to DP br
On Thu, Jun 05, 2025 at 01:33:39PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 05, 2025 at 09:47:01PM +0530, Aneesh Kumar K.V wrote:
> > Jason Gunthorpe writes:
> >
> > > On Thu, Jun 05, 2025 at 05:33:52PM +0530, Aneesh Kumar K.V wrote:
> > >
> > >> > +
> > >> > + /* To ensure no host side M
On Thu, Jun 05, 2025 at 12:09:16PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 05, 2025 at 05:41:17PM +0800, Xu Yilun wrote:
>
> > No, this is not device side TDISP requirement. It is host side
> > requirement to fix DMA silent drop issue. TDX enforces CPU S2 PT share
> > with IOMMU S2 PT (does AR
On Mon, 02 Jun 2025 10:49:06 -0400, Frank Li wrote:
> Allow resets property to fix below CHECK_DTB warning:
> arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: lcd-controller@40008000
> (arm,pl111): 'resets' does not match any of the regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Frank Li
> ---
> D
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/xe/xe_lrc.c
between commit:
617d824c5323 ("drm/xe: Add WA BB to capture active context utilization")
from Linus' tree and commit:
2b0a0ce0c20b ("drm/xe: Create LRC BO without VM")
from the drm tree.
I
On Mon, 02 Jun 2025 11:28:13 -0400, Frank Li wrote:
> Convert himax,hx8357d.txt to yaml format.
>
> Additional changes:
> - add spi parent node in examples.
> - ref to spi-peripheral-props.yaml.
> - change himax,hx8357a to himax,hx8357 to align driver and existed dts.
> - add himax,hx8369a and f
Hi Dave, Simona,
Fixes for 6.16.
The following changes since commit 1c1df79ccf5615a007cb11ff30e997e58a9fa79a:
Merge tag 'amd-drm-fixes-6.16-2025-05-29' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2025-06-02 11:56:06
+1000)
are available in the Git repository at:
https://
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20250605]
[cannot apply to drm-exynos/exynos-drm-next drm/drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-misc/drm-misc-next
drm-tip/drm
Hi all,
Today's linux-next merge of the drm-misc-fixes tree got a conflict in:
drivers/accel/ivpu/ivpu_gem.c
between commit:
835b14ce4ee3 ("accel/ivpu:
s/drm_gem_shmem_v[un]map/drm_gem_shmem_v[un]map_locked/")
from Linus' tree and commit:
98d3f772ca7d ("accel/ivpu: Use dma_resv_lock()
On Thu, 29 May 2025 16:05:19 -0400, Frank Li wrote:
> Allow lcd panel related property for imx28 and keep the same restriction
> for other platform. It is legancy platform and set these property to
> deprecated.
>
> Fix below CHECK_DTB warnings:
> arch/arm/boot/dts/nxp/mxs/imx28-apx4devkit.dtb:
On Fri, May 30, 2025 at 06:05:42PM -0500, David Lechner wrote:
> Convert the sitronix,st7586 binding documentation from .txt to .yaml.
>
> Also added a link to the datasheet while we are touching this.
>
> Signed-off-by: David Lechner
> ---
> .../bindings/display/sitronix,st7586.txt |
On Wed, Jun 04, 2025 at 11:35:34AM +0200, Thomas Hellström wrote:
> From: Matthew Brost
>
> The migration functionality and track-keeping of per-pagemap VRAM
> mapped to the CPU mm is not per GPU_vm, but rather per pagemap.
> This is also reflected by the functions not needing the drm_gpusvm
> st
On Thu, Jun 05, 2025 at 04:19:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This is an initial port of the TTM pools for
> write combined and uncached pages to use the list_lru.
>
> This makes the pool's more NUMA aware and avoids
> needing separate NUMA pools (later commit enables this
On Fri, 30 May 2025 10:47:25 -0700, Jessica Zhang wrote:
> From: Abhinav Kumar
>
> Add DISP_CC_MDSS_DP_PIXEL1_* macros for SC7280
>
> Signed-off-by: Abhinav Kumar
> Signed-off-by: Jessica Zhang
> ---
> include/dt-bindings/clock/qcom,dispcc-sc7280.h | 2 ++
> 1 file changed, 2 insertions(+)
On Fri, 30 May 2025 10:47:24 -0700, Jessica Zhang wrote:
> From: Abhinav Kumar
>
> Add x1e80100 to the dp-controller bindings, fix the
> displayport-controller reg bindings, and drop
> assigned-clock-parents
>
> Signed-off-by: Abhinav Kumar
> Signed-off-by: Jessica Zhang
> ---
> .../devicet
On Wed, Jun 04, 2025 at 11:35:36AM +0200, Thomas Hellström wrote:
> Add runtime PM since we might call populate_mm on a foreign device.
> Also create the VRAM bos as ttm_bo_type_kernel. This avoids the
> initial clearing and the creation of an mmap handle.
>
I didn't read this part - skipping the
On Thu, 29 May 2025 07:36:53 +0200, Andrej Picej wrote:
> The kernel test robot reported a warning related to the use of "$ref"
> type definitions for custom endpoint properties
> - "ti,lvds-vod-swing-clock-microvolt" and
> - "ti,lvds-vod-swing-data-microvolt".
>
> Using "$ref" with "uint32-arra
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Francis, David
> Sent: Wednesday, May 21, 2025 10:07 AM
> To: dri-devel@lists.freedesktop.org
> Cc: tvrtko.ursu...@igalia.com; Kuehling, Felix ; Yat
> Sin,
> David ; Freehill, Chris ;
> Koenig, Christia
The unmap logic assumes a fixed step size of PAGE_SIZE, but the
actual IOVA step depends on iommu_pgshift, not PAGE_SHIFT. If
iommu_pgshift > PAGE_SHIFT, this results in mismatched offsets and
causes iommu_unmap() to target incorrect addresses, potentially
leaving mappings intact or corrupting IOMM
Fix possible overflow in the address expression used as the second
argument to iommu_map() and iommu_unmap(). Without an explicit cast,
this expression may overflow when 'r->offset' or 'i' are large. Cast
the result to unsigned long before shifting to ensure correct IOVA
computation and prevent uni
Hi Piotr,
Since kernel 6.14-rc1 I have the problem that visual output is no longer
shown on my PineTab2 and a ``git bisect`` pointed to this patch/commit
as the culprit. What is important to note is that ``CONFIG_DRM=m`` seems
to be required as the problem does not occur with ``CONFIG_DRM=y``.
Ne
Fix possible overflow in the address expression used as the second
argument to iommu_map() and iommu_unmap(). Without an explicit cast,
this expression may overflow when 'r->offset' or 'i' are large. Cast
the result to unsigned long before shifting to ensure correct IOVA
computation and prevent uni
The unmap logic assumes a fixed step size of PAGE_SIZE, but the
actual IOVA step depends on iommu_pgshift, not PAGE_SHIFT. If
iommu_pgshift > PAGE_SHIFT, this results in mismatched offsets and
causes iommu_unmap() to target incorrect addresses, potentially
leaving mappings intact or corrupting IOMM
Dave, Simona
This week's drm-xe-next-fixes pull. Quite a few this week.
One thing to be aware of is a conflict in "Create LRC bo without VM",
Looks like a commit got pulled into drm-xe-fixes that is not in
drm-xe-next-fixes,
and pulling this branch will likely conflict with that once Linus merges
On 6/5/25 04:18, Biju Das wrote:
Hi Hugo,
Thanks for the patch.
-Original Message-
From: dri-devel On Behalf Of Hugo
Villeneuve
Sent: 04 June 2025 15:53
Subject: [PATCH v4 1/1] drm: renesas: rz-du: Implement MIPI DSI host transfers
From: Hugo Villeneuve
Add support for sending MIP
From: luoqing
sizeof(xx) these variable values' return values cannot be 0.
For memory allocation requests of non-zero length,
there is no need to check other return values;
it is sufficient to only verify that it is not null.
Signed-off-by: luoqing
---
drivers/gpu/drm/amd/display/amdgpu_dm/amd
From: luoqing
sizeof(xx) these variable values' return values cannot be 0.
For memory allocation requests of non-zero length,
there is no need to check other return values;
it is sufficient to only verify that it is not null.
Signed-off-by: luoqing
---
drivers/accel/habanalabs/common/memory.c
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 +-
2 files
From: Rob Clark
Similar to the previous commit, add support for dumping partial
mappings.
Signed-off-by: Rob Clark
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(
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
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
Signed-off
With the conversion to drm_gpuvm, we lost the lazy VMA cleanup, which
means that fb cleanup/unpin when pageflipping to new scanout buffers
immediately unmaps the scanout buffer. This is costly (with tlbinv,
it can be 4-6ms for a 1080p scanout buffer, and more for higher
resolutions)!
To avoid thi
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c|1 +
drivers/gpu/drm/msm/msm_drv.h|
From: Rob Clark
Bump version to signal to userspace that VM_BIND is supported.
Signed-off-by: Rob Clark
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.
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 20 +++-
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/
A large number of (unsorted or separate) small (<2MB) mappings can cause
a lot of, probably unnecessary, prealloc pages. Ie. a single 4k page
size mapping will pre-allocate 3 pages (for levels 2-4) for the
pagetable. Which can chew up a large amount of unneeded memory. So add
a mechanism to put
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
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
From: Rob Clark
So we can monitor how many pages are getting preallocated vs how many
get used.
Signed-off-by: Rob Clark
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
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
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
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
Signed-off-by: Rob Clark
---
drivers
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h| 17 +
drivers/gpu/drm/msm/msm_gem_submit.c | 3 +++
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
This is a more descriptive name.
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 12 +
drivers/gpu/drm/msm/msm_gem_submit.c | 60 +++
From: Rob Clark
As with devcoredump, we need to iterate the VMAs to figure out what to
dump.
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_rd.c | 48 +---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/gp
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 96 ++-
1 file changed, 72 insertions(+), 24 deletions(-)
diff --git a/driv
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, 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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 17 +
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_
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
Signed-off-by: Rob Clark
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 ++-
drivers/gpu/dr
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/
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
Signed-off-by: Rob Clark
-
From: Rob Clark
We'll re-use this in the vm_bind path.
Signed-off-by: Rob Clark
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/d
From: Rob Clark
This fits better drm_gpuvm/drm_gpuva.
Signed-off-by: Rob Clark
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/m
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
Signed-off-by: Rob
The fb only deals with kms->vm, so make that explicit. This will start
letting us refcount the # of times the fb is pinned, so we can only
unpin the vma after last user of the fb is done. Having a single
reference count really only works if there is only a single vm.
Signed-off-by: Rob Clark
--
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
We were already keeping a refcount of # of prepares (pins), to clear the
iova array. Use that to avoid unpinning the iova until the last cleanup
(unpin). This way, when msm_gem_unpin_iova() actually tears down the
mapping, we won't have problems if the fb is being scanned out on
another display (
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
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 30 +++---
driver
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_NULL/UNMAP commands
Hello Maxime,
thanks for reviewing this series.
On Tue, 27 May 2025 18:10:31 +0200
Maxime Ripard wrote:
[...]
> > @@ -422,11 +424,93 @@ static struct kunit_suite
> > drm_bridge_helper_reset_crtc_test_suite = {
> > .test_cases = drm_bridge_helper_reset_crtc_tests,
> > };
> >
> > +struct
From: Rob Clark
Just some tidying up.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.h | 44 +++
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/
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
This is a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Rob Clark
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
Hello Aradhya,
Thanks for the patch series.
On 6/5/2025 10:45 PM, Aradhya Bhatia wrote:
> Hello all,
>
> This series re-orders the sequences in which the drm CRTC and the drm
> Bridge get enabled and disabled with respect to each other.
>
> The bridge pre_enable calls have been shifted before t
From: Thomas Zimmermann Sent: Thursday, June 5, 2025 8:36
AM
>
> Hi
>
> Am 04.06.25 um 23:43 schrieb Michael Kelley:
> [...]
> > Nonetheless, there's an underlying issue. A main cause of the difference
> > is the number of messages to Hyper-V to update dirty regions. With
> > hyperv_fb using de
On Sat, 24 May 2025 13:48:36 +0200, Jens Glathe wrote:
> Document the x1p-42-100/x1-26-100 variants of the Thinkbook 16 G7 QOY.
>
> [1]:
> https://psref.lenovo.com/syspool/Sys/PDF/ThinkBook/ThinkBook_16_G7_QOY/ThinkBook_16_G7_QOY_Spec.pdf
>
> Signed-off-by: Jens Glathe
> ---
> Documentation/
From: Aradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before
the input DPI's source has begun streaming[0]. Not having that, allows
for a small window before cdns-dsi enable and after cdns-dsi disable
where the previous entity (in this case tidss's videoport) to co
The encoder-bridge ops occur by looping over the new connector states of
the display pipelines. The enable sequence runs as follows -
- pre_enable(bridge),
- enable(encoder),
- enable(bridge),
while the disable sequnce runs as follows -
- disable(bridge),
From: Aradhya Bhatia
Move the bridge pre_enable call before crtc enable, and the bridge
post_disable call after the crtc disable.
The sequence of enable after this patch will look like:
bridge[n]_pre_enable
...
bridge[1]_pre_enable
crtc_enable
encoder_en
From: Aradhya Bhatia
The way any singular display pipeline, in need of a modeset, gets
enabled is as follows -
crtc enable
(all) bridge pre-enable
encoder enable
(all) bridge enable
- and the disable sequence is exactly the reverse of this.
The crtc operations o
Hello all,
This series re-orders the sequences in which the drm CRTC and the drm
Bridge get enabled and disabled with respect to each other.
The bridge pre_enable calls have been shifted before the crtc_enable and
the bridge post_disable calls have been shifted after the crtc_disable.
This has b
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_NULL/UNMAP commands
On 05.06.25 18:30, Dan Williams wrote:
David Hildenbrand wrote:
On 05.06.25 14:09, Jason Gunthorpe wrote:
On Wed, Jun 04, 2025 at 07:35:24PM -0700, Dan Williams wrote:
If all dax pages are special, then vm_normal_page() should never find
them and gup should fail.
...oh, but vm_normal_page_p[
Hi Dave, Simona,
Small list of fixes for v6.16-rc1!
Best regards!
~Maarten
drm-misc-next-fixes-2025-06-05:
drm-misc-fixes for v6.16-rc1:
- Fixes for nt37801 panel
- Fix null deref in HDMI audio helper.
- Fixes for analogix_dp.
The following changes since commit 7c1a9408ce5f34ded5a85db81cf80e0975
On Thu, 5 Jun 2025 at 17:32, Tomeu Vizoso wrote:
> On Thu, Jun 5, 2025 at 3:37 PM Robin Murphy wrote:
> > It should only need a single IOMMU domain per DRM client, so no faffing
> > about replicating mappings. iommu_paging_domain_alloc() does need *an*
> > appropriate target device so it can iden
On Thu, Jun 05, 2025 at 09:47:01PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe writes:
>
> > On Thu, Jun 05, 2025 at 05:33:52PM +0530, Aneesh Kumar K.V wrote:
> >
> >> > +
> >> > +/* To ensure no host side MMIO access is possible */
> >> > +ret = pci_request_regions_exclusive
On Thu, Jun 5, 2025 at 3:37 PM Robin Murphy wrote:
>
> On 05/06/2025 8:41 am, Tomeu Vizoso wrote:
> [...]
> >> In fact this is precisely the usage model I would suggest for this sort
> >> of thing, and IIRC I had a similar conversation with the Ethos driver
> >> folks a few years back. Running you
1 - 100 of 188 matches
Mail list logo
