On 2025-08-26 2:43 pm, Mark Rutland wrote:
On Wed, Aug 13, 2025 at 06:01:10PM +0100, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an explicit opt-in for these special cases
On 2025-08-26 2:28 pm, Mark Rutland wrote:
On Tue, Aug 26, 2025 at 03:08:06PM +0200, Peter Zijlstra wrote:
On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
Sampling is inherently a feature for CPU PMUs, given that the thing
to be sampled is a CPU context. These days, we have many
On 2025-08-26 2:11 pm, Leo Yan wrote:
On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
Sampling is inherently a feature for CPU PMUs, given that the thing
to be sampled is a CPU context. These days, we have many more
uncore/system PMUs than CPU PMUs, so it no longer makes much
On 2025-08-26 2:03 pm, Peter Zijlstra wrote:
On Wed, Aug 13, 2025 at 06:01:04PM +0100, Robin Murphy wrote:
It may have been different long ago, but today it seems wrong for these
drivers to skip counting disabled sibling events in group validation,
given that perf_event_enable() could make them
On 2025-08-26 12:15 pm, Mark Rutland wrote:
On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
The group validation logic shared by the HiSilicon HNS3/PCIe drivers is
a bit off, in that given a software group leader, it will consider that
event *in place of* the actual new event
Hi Thomas,
On 2025-08-20 9:09 am, Thomas Richter wrote:
On 8/19/25 15:15, Robin Murphy wrote:
On 13/08/2025 6:01 pm, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an
ab-lkp/linux/commits/Robin-Murphy/perf-arm-cmn-Fix-event-validation/20250814-010626
base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
91325f31afc1026de28665cf1a7b6e157fa4d39d
patch link:
https://lore.kernel.org/all/ace3532a8a438a96338bf349a27636d8294c7111.1755096883.git.robin.m
On 13/08/2025 6:01 pm, Robin Murphy wrote:
[...]
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 297ff5adb667..98ffab403bb4 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -731,24 +731,11 @@ static int uncore_pmu_event_init
On 13/08/2025 6:01 pm, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an explicit opt-in for these special cases, so that we can
make life easier for every other driver (and
to look like one of the hardware siblings.
The uncore framework avoids that particular issue, but all 3 also share
the common issue of not preventing racy access to the sibling list, and
some redundant checks which can be cleaned up.
Signed-off-by: Robin Murphy
---
drivers/perf/hisilicon
ING.
- has_branch_stack()
Now doubly-illogical for PMUs which never supported sampling
anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mach-imx/mmdc.c | 14 -
arch/arm/mm/cache-l2x0-pmu.c | 10 ---
arch/powerpc/perf/hv-24x7.c
having perf_try_init_event() do the basic type
checking to cover the majority of cases.
Signed-off-by: Robin Murphy
---
A further possibility is to automatically add the cap to PERF_TYPE_RAW
PMUs in perf_pmu_register() to have a single point-of-use condition; I'm
undecided...
---
arch
Now that we have a well-defined cap for sampling support, clean up the
remains of the mildly unintuitive and inconsistently-applied
PERF_PMU_CAP_NO_INTERRUPT. Not to mention the obvious redundancy of
some of these drivers still checking for sampling in event_init too.
Signed-off-by: Robin Murphy
(or erroneously fail to). Instead, let's
introduce a positive opt-in capability that's more obvious and easier to
maintain.
Signed-off-by: Robin Murphy
---
arch/alpha/kernel/perf_event.c | 3 ++-
arch/arc/kernel/perf_event.c | 2 ++
arch/csky/kernel/perf_event.c
ility
of their own events within the given group, for now at least removing
this redundant code makes it even clearer that they are not.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-ccn.c | 16
drivers/perf/fsl_imx9_ddr_perf.c | 16
drivers/per
down to
trivial counting.
Signed-off-by: Robin Murphy
---
drivers/perf/arm_cspmu/arm_cspmu.c | 7 ++-
drivers/perf/arm_dsu_pmu.c | 6 ++
drivers/perf/arm_pmu.c | 11 ++-
drivers/perf/thunderx2_pmu.c | 30 +++---
4 files changed, 13 in
).
Signed-off-by: Robin Murphy
---
drivers/perf/arm-cci.c | 47 +++---
1 file changed, 12 insertions(+), 35 deletions(-)
diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 1cc3214d6b6d..086d4363fcc8 100644
--- a/drivers/perf/arm-cci.c
+++ b
software-only group.
In particular it took a while to see that marvell_cn10k_tad_pmu was
seemingly trying to rely on the empirical behaviour of perf tool
creating group leader events with disabled=1 and subsequent siblings
with disabled=0. Down with this sort of thing!
Signed-off-by: Robin Murphy
truly dead then it stands to reason that the whole
group is dead, so it's not worth going to any special effort to try to
squeeze in a new event that's never going to run anyway. Thus, we can
simply remove all these checks.
Signed-off-by: Robin Murphy
---
arch/alpha/kernel/perf_eve
with core code.
Signed-off-by: Robin Murphy
---
arch/arm/mach-imx/mmdc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index 94e4f4a2f73f..f9d432b385a2 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm
which doesn't belong to our PMU. Similarly drop the early return
paths since they can almost never actually return early.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-ni.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/arm-ni.c
vents which do not belong to our PMU.
The L2 driver gets a cleanup of some slightly suspicious logic, and both
can have the same overall simplification to not duplicate things that perf
core will already do, and avoid racy access to the sibling list of group
leader events.
Signed-off-by: Robin M
Signed-off-by: Robin Murphy
---
drivers/perf/arm_smmuv3_pmu.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43b..7cac380a3528 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++
The group validation here is almost right, but fails to count the new
event itself. While we fix that, also adopt the standard pattern to
avoid racy access the sibling list and drop checks that are redundant
with core code.
Signed-off-by: Robin Murphy
---
arch/arm/mm/cache-l2x0-pmu.c | 9
ss to the sibling list when the event is its own group leader.
Signed-off-by: Robin Murphy
---
drivers/iommu/intel/perfmon.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel/perfmon.c b/drivers/iommu/intel/perfmon.c
index 75f493b
() will already check for us.
Signed-off-by: Robin Murphy
---
drivers/perf/fsl_imx8_ddr_perf.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index b989ffa95d69..56fe281974d2 100644
---
The group validation code here is superficially the right shape, but
is failing to count the group leader, while also erroneously counting
software siblings. Just correctly count the events which belong to our
PMU, and let perf core worry about the rest.
Signed-off-by: Robin Murphy
---
drivers
there... Thankfully the way to be more robust is to be
less clever - stop trying to special-case software events and simply
skip any event that isn't for our PMU.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-cmn.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/driver
e rest into per-driver patches, but I'm sure
nobody wants a ~70-patch series out of the gate :)
Thanks,
Robin.
Robin Murphy (19):
perf/arm-cmn: Fix event validation
perf/hisilicon: Fix group validation
perf/imx8_ddr: Fix group validation
perf/starfive: Fix group validation
iommu
On 2025-07-29 9:13 pm, Jason Gunthorpe wrote:
On Tue, Jul 29, 2025 at 08:44:21PM +0100, Robin Murphy wrote:
In this case with just one single
contiguous mapping, it is clearly objectively worse to have to bounce in and
out of the IOMMU layer 3 separate times and store a dma_map_state,
The
On 2025-07-23 2:00 pm, Leon Romanovsky wrote:
[...]
+static struct sg_table *
+vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
+enum dma_data_direction dir)
+{
+ struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
+ struct p2pdma_provider *provide
On 11/07/2025 5:00 pm, Tomeu Vizoso wrote:
On Tue, Jun 24, 2025 at 3:50 PM Robin Murphy wrote:
On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
[...]
diff --git a/drivers/accel/rocket/rocket_device.h
b/drivers/accel/rocket/rocket_device.h
index
10acfe8534f00a7985d40a93f4b2f7f69d43caee
On 28/06/2025 4:39 pm, Kaustabh Chakraborty wrote:
On 2025-06-25 11:34, Robin Murphy wrote:
On 2025-06-25 9:42 am, Marek Szyprowski wrote:
On 25.06.2025 09:39, Kaustabh Chakraborty wrote:
On 2025-06-24 17:12, Robin Murphy wrote:
On 2025-06-18 3:02 pm, Kaustabh Chakraborty wrote:
Since
On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
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, an
On 2025-06-25 9:42 am, Marek Szyprowski wrote:
On 25.06.2025 09:39, Kaustabh Chakraborty wrote:
On 2025-06-24 17:12, Robin Murphy wrote:
On 2025-06-18 3:02 pm, Kaustabh Chakraborty wrote:
Since bcb81ac6ae3c (iommu: Get DT/ACPI parsing into the proper probe
path),
The Samsung Exynos 7870 DECON
On 2025-06-18 3:02 pm, Kaustabh Chakraborty wrote:
Since bcb81ac6ae3c (iommu: Get DT/ACPI parsing into the proper probe path),
The Samsung Exynos 7870 DECON device (with patches [1], [2], and [3]) seems
to not work anymore. Upon closer inspection, I observe that there is an
IOMMU crash.
[2.9
On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
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
On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
[...]
diff --git a/drivers/accel/rocket/rocket_device.h
b/drivers/accel/rocket/rocket_device.h
index
10acfe8534f00a7985d40a93f4b2f7f69d43caee..50e46f0516bd1615b5f826c5002a6c0ecbf9aed4
100644
--- a/drivers/accel/rocket/rocket_device.h
+++ b/drivers/acc
copyright notice (Jeff Hugo)
v6:
- Use mutexes guard (Markus Elfring)
v7:
- Assign its own IOMMU domain to each client, for isolation (Daniel
Stone and Robin Murphy)
Reviewed-by: Jeffrey Hugo
Signed-off-by: Tomeu Vizoso
---
drivers/accel/rocket/Makefile| 3 +-
drivers/accel/rocket
On 2025-06-12 7:56 pm, Nicolas Frattaroli wrote:
Hardware of various vendors, but very notably Rockchip, often uses
32-bit registers where the upper 16-bit half of the register is a
write-enable mask for the lower half.
This type of hardware setup allows for more granular concurrent register
wri
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 your own IOMMU domain is no biggie, see
several other DRM drivers (includi
[ Since Daniel made me look... ]
On 2025-06-04 8:57 am, Tomeu Vizoso wrote:
[...]
diff --git a/drivers/accel/rocket/Kconfig b/drivers/accel/rocket/Kconfig
new file mode 100644
index
..9a59c6c61bf4d6460d8008b16331f001c97de67d
--- /dev/null
+++ b/drivers/ac
On 2025-06-04 5:18 pm, Daniel Stone wrote:
Hi Tomeu,
I have some bad news ...
On Wed, 4 Jun 2025 at 08:57, Tomeu Vizoso wrote:
+int rocket_ioctl_create_bo(struct drm_device *dev, void *data, struct drm_file
*file)
+{
+ [...]
+
+ /* This will map the pages to the IOMMU linked to co
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 quirk instead for selftests.
Signed-off-by: Rob Clark
Acked-by: Robin Murphy
On 02/05/2025 10:59 am, Jens Wiklander wrote:
Add tee_shm_alloc_cma_phys_mem() to allocate a physical memory using
from the default CMA pool. The memory is represented by a tee_shm object
using the new flag TEE_SHM_CMA_BUF to identify it as physical memory
from CMA.
If and when it's possible to
On 02/05/2025 10:59 am, Jens Wiklander wrote:
Implement DMA heap for protected DMA-buf allocation in the TEE
subsystem.
Restricted memory refers to memory buffers behind a hardware enforced
firewall. It is not accessible to the kernel during normal circumstances
but rather only accessible to cer
On 02/05/2025 10:59 am, Jens Wiklander wrote:
If a parent device is supplied to tee_device_alloc(), copy the dma_mask
field into the new device. This avoids future warnings when mapping a
DMA-buf for the device.
That also sounds dodgy. If the parent device is the hardware device
physically per
Robin.
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: io...@lists.linux.dev
Signed-off-by: Jens Wiklander
---
kernel/dma/contiguous.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 8df0dfaaca18..eb361794a9c5 100644
--- a/kerne
On 28/04/2025 9:54 pm, Rob Clark wrote:
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/i
On 2025-03-10 12:06 pm, Maxime Ripard wrote:
In order to support any device using the GEM support, let's charge any
GEM DMA allocation into the dmem cgroup.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_gem.c| 5 +
drivers/gpu/drm/drm_gem_dma_helper.c | 6 ++
incl
On 2025-03-10 4:28 pm, Maxime Ripard wrote:
On Mon, Mar 10, 2025 at 02:56:37PM +, Robin Murphy wrote:
On 2025-03-10 12:06 pm, Maxime Ripard wrote:
Consumers of the direct DMA API will have to know which region their
device allocate from in order for them to charge the memory allocation
in
On 2025-03-10 12:06 pm, Maxime Ripard wrote:
Consumers of the direct DMA API will have to know which region their
device allocate from in order for them to charge the memory allocation
in the right one.
This doesn't seem to make much sense - dma-direct is not an allocator
itself, it just provi
On 2024-11-04 5:41 pm, Jason Gunthorpe wrote:
A minority of page table implementations (arm_lpae, armv7) are unique in
how they handle partial unmap of large IOPTEs.
Other implementations will unmap the large IOPTE and return it's
length. For example if a 2M IOPTE is present and the first 4K is
On 21/10/2024 1:17 pm, Jason Gunthorpe wrote:
On Mon, Oct 21, 2024 at 12:32:21PM +0100, Steven Price wrote:
that, we can always do it in two steps (unmap the 2M region and remap
the borders). At some point it'd be good to have some kind of atomic
page table updates, so we don't have this short
On 2024-09-20 9:20 am, Andy Yan wrote:
From: Andy Yan
The vop mmu support translate physical address upper 4 GB to iova
below 4 GB. So set dma mask to 64 bit to indicate we support address
4GB.
This can avoid warnging message like this on some boards with DDR
4 GB:
rockchip-drm display-su
On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
+/**
+ * enum drm_panthor_sync_op_flags - Synchronization operation
flags.
+ */
+enum drm_panthor_sync_op_flags {
+ /** @DRM_PANT
t thinking ahead, might it be worth a logical "are SG segment limits
relevant?" wrapper around the dev->dma_parms reference? Not a big deal
for now if we think this site is the only user, so either way,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
drive
On 23/05/2024 6:52 pm, Rob Clark wrote:
From: Rob Clark
Add an io-pgtable method to walk the pgtable returning the raw PTEs that
would be traversed for a given iova access.
Have to say I'm a little torn here - with my iommu-dma hat on I'm not
super enthusiastic about adding any more overhead
On 2024-06-13 10:38 pm, Sebastian Reichel wrote:
Hi,
On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
wrote:
On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
IOMMUs
On 29/05/2024 6:32 am, Lu Baolu wrote:
The IOMMU subsystem has undergone some changes, including the removal
of iommu_ops from the bus structure. Consequently, the existing domain
allocation interface, which relies on a bus type argument, is no longer
relevant:
struct iommu_domain *iommu_do
On 11/04/2024 4:04 pm, Thorsten Blum wrote:
Use `find . -type f -exec sed -i 's/\/the/g' {} +` to find all
occurrences of "the the" and replace them with a single "the".
[...]
diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index d60b09a5acfc..a75da9a01f91 100644
---
On 18/03/2024 2:51 pm, Steven Price wrote:
virt_to_pfn() isn't available on x86 (except to xen) so breaks
COMPILE_TEST builds. Avoid its use completely by instead storing the
struct page pointer allocated in panthor_device_init() and using
page_to_pfn() instead.
Signed-off-by: Steven Price
---
On 18/03/2024 1:49 pm, Steven Price wrote:
On 18/03/2024 13:08, Boris Brezillon wrote:
On Mon, 18 Mar 2024 11:31:05 +
Steven Price wrote:
On 18/03/2024 08:58, Boris Brezillon wrote:
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's ac
On 18/03/2024 8:58 am, Boris Brezillon wrote:
Putting a hard dependency on CONFIG_PM is not possible because of a
circular dependency issue, and it's actually not desirable either. In
order to support this use case, we forcibly resume at init time, and
suspend at unplug time.
Reported-by: kernel
On 2024-03-11 1:22 pm, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:11:28 +
Robin Murphy wrote:
On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
On Mon, 11 Mar 2024, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:05:01 +0200
On 2024-03-11 11:52 am, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:49:56 +0200
Jani Nikula wrote:
On Mon, 11 Mar 2024, Boris Brezillon wrote:
On Mon, 11 Mar 2024 13:05:01 +0200
Jani Nikula wrote:
This breaks the config for me:
SYNCinclude/config/auto.conf.cmd
GEN Makef
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe
---
drivers/acpi/Kconfig| 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/ar
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
decisively seems more useful than deferring forever.
Signed-off-by: Robin Murphy
---
I realised that last time I sent this I probably should have CCed a
wider audience of reviewers, so here's one with an updated commit
message as well to make the resend more worthwhile.
drivers/gpu/drm/med
On 13/11/2023 6:37 am, Yong Wu (吴勇) wrote:
[...]
+properties:
+ compatible:
+const: secure_cma_region
Still wrong compatible. Look at other bindings - there is nowhere
underscore. Look at other reserved memory bindings especially.
Also, CMA is a Linux thingy, so either not suitable for bi
On 29/09/2023 4:45 pm, Will Deacon wrote:
On Mon, Sep 25, 2023 at 06:54:42PM +0100, Robin Murphy wrote:
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
On 2023-04-10 19:52, Dmitry Baryshkov wrote:
If the Adreno SMMU is dma-coherent, allocation will fail unless we
disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the
coherent SMMUs (like we have on sm8350 platform).
Hmm, but is it right that it should fail in the first place?
On 12/09/2023 4:53 pm, Rob Herring wrote:
On Tue, Sep 12, 2023 at 11:13:50AM +0100, Robin Murphy wrote:
On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote:
On 12/09/2023 08:16, Yong Wu (吴勇) wrote:
Hi Rob,
Thanks for your review.
On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote
On 12/09/2023 9:28 am, Krzysztof Kozlowski wrote:
On 12/09/2023 08:16, Yong Wu (吴勇) wrote:
Hi Rob,
Thanks for your review.
On Mon, 2023-09-11 at 10:44 -0500, Rob Herring wrote:
External email : Please do not click links or open attachments until
you have verified the sender or the co
On 2023-09-04 17:16, Boris Brezillon wrote:
On Mon, 4 Sep 2023 16:22:19 +0100
Steven Price wrote:
On 04/09/2023 10:26, Boris Brezillon wrote:
On Mon, 4 Sep 2023 08:42:08 +0100
Steven Price wrote:
On 01/09/2023 17:10, Boris Brezillon wrote:
On Wed, 9 Aug 2023 18:53:15 +0200
Boris Brezi
On 2023-08-09 17:53, Boris Brezillon wrote:
[...]
+/**
+ * struct drm_panthor_vm_create - Arguments passed to
DRM_PANTHOR_IOCTL_VM_CREATE
+ */
+struct drm_panthor_vm_create {
+ /** @flags: VM flags, MBZ. */
+ __u32 flags;
+
+ /** @id: Returned VM ID. */
+ __u32 id;
+
+
On 2023-08-14 12:18, Steven Price wrote:
On 11/08/2023 20:26, Robin Murphy wrote:
On 2023-08-11 17:56, Daniel Stone wrote:
Hi,
On 11/08/2023 17:35, Robin Murphy wrote:
On 2023-08-09 17:53, Boris Brezillon wrote:
+obj-$(CONFIG_DRM_PANTHOR) += panthor.o
FWIW I still think it would be nice
On 2023-08-14 11:54, Steven Price wrote:
[...]
+/**
+ * panthor_gpu_l2_power_on() - Power-on the L2-cache
+ * @ptdev: Device.
+ *
+ * Return: 0 on success, a negative error code otherwise.
+ */
+int panthor_gpu_l2_power_on(struct panthor_device *ptdev)
+{
+ u64 core_mask = U64_MAX;
+
+
On 2023-08-18 22:32, Jason Gunthorpe wrote:
It turns out several drivers are calling of_dma_configure() outside the
expected bus_type.dma_configure op. This ends up being mis-locked and
triggers a lockdep assertion, or instance:
iommu_probe_device_locked+0xd4/0xe4
of_iommu_configure+0x10c/
On 2023-07-13 20:13, Andrew Davis wrote:
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
---
Changes from v2:
- Make sram_dma_heap_alloca
On 2023-08-11 17:56, Daniel Stone wrote:
Hi,
On 11/08/2023 17:35, Robin Murphy wrote:
On 2023-08-09 17:53, Boris Brezillon wrote:
+obj-$(CONFIG_DRM_PANTHOR) += panthor.o
FWIW I still think it would be nice to have a minor
directory/Kconfig/Makefile reshuffle and a trivial bit of extra
On 2023-08-09 17:53, Boris Brezillon wrote:
Now that all blocks are available, we can add/update Kconfig/Makefile
files to allow compilation.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 -> MIT + GPL2)
- Split the driver addition commit
- Add new dependencies on GPUVA a
On 2023-06-20 10:47, Sui Jingfeng wrote:
From: Sui Jingfeng
Loongson CPUs maintain cache coherency by hardware, which means that the
data in the CPU cache is identical to the data in main system memory. As
for the peripheral device, most of Loongson chips chose to define the
peripherals as DMA
On 2023-05-17 15:52, Alexandre Bailon wrote:
Some APU devices are behind an IOMMU.
For some of these devices, we can't use DMA API because
they use static addresses so we have to manually use
IOMMU API to correctly map the buffers.
Except you still need to use the DMA for the sake of cache cohe
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
v2: Rebase to 6.4-rc1
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file
On 2023-05-05 15:50, Jason Gunthorpe wrote:
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote:
Although iommu-dma is a per-architecture chonce, that is currently
implemented in a rather haphazard way. Selecting from the arch Kconfig
was the original logical approach, but is
On 2023-04-28 10:27, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*()
with Linux' regular I/O functions. Remove all ifdef cases for the
various architectures.
Most of the supported architectures use __raw_() I/O functions or treat
framebuffer memory
On 2023-01-18 18:00, Jason Gunthorpe wrote:
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
On 2023-01-18 11:09, Steven Price wrote:
On 17/01/2023 16:44, Arnd Bergmann wrote:
From: Arnd Bergmann
On ARMv5 and earlier, a randconfig build can still run into
WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE
Depends on [n]: IOMMU_SUPPORT [=y] && (ARM [=y] || ARM64
On 2023-01-06 16:42, Jason Gunthorpe wrote:
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
FWIW, since we *do* have two variants already
On 03/01/2023 4:15 pm, Maxime Ripard wrote:
Hi Robin,
On Tue, Jan 03, 2023 at 01:01:07PM +, Robin Murphy wrote:
Hi Sean,
On 22/12/2022 11:37 pm, Sean Anderson wrote:
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of
Hi Sean,
On 22/12/2022 11:37 pm, Sean Anderson wrote:
Convert users of component_match_add_release with component_release_of
and component_compare_of to component_match_add_of.
Signed-off-by: Sean Anderson
Acked-by: Mark Brown
---
Changes in v2:
- Split off from helper addition
drivers/io
On 2022-12-16 17:08, Sean Anderson wrote:
On 11/3/22 14:22, Sean Anderson wrote:
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
drm_of_component_match_a
Robin Murphy:
On 2022-12-14 22:02, Alex Deucher wrote:
On Wed, Dec 14, 2022 at 4:54 PM Robin Murphy
wrote:
On 2022-12-12 02:08, Luben Tuikov wrote:
Fix screen corruption on older 32-bit systems using AGP chips.
On older systems with little memory, for instance 1.5 GiB, using an
AGP chip,
the
On 2022-12-14 22:02, Alex Deucher wrote:
On Wed, Dec 14, 2022 at 4:54 PM Robin Murphy wrote:
On 2022-12-12 02:08, Luben Tuikov wrote:
Fix screen corruption on older 32-bit systems using AGP chips.
On older systems with little memory, for instance 1.5 GiB, using an AGP chip,
the device'
nks,
Robin.
Partially reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
v2: Amend the commit description.
Cc: Mikhail Krylov
Cc: Alex Deucher
Cc: Robin Murphy
Cc: Direct Rendering Infrastructure - Development
Cc: AMD Graphics
Fixes: 33b3ad3788aba8 ("drm/radeon: handle PCI
On 2022-12-07 15:29, Liviu Dudau wrote:
On Wed, Dec 07, 2022 at 01:59:04PM +, Robin Murphy wrote:
On 2022-12-07 09:21, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer, it should be better to check
the return value in order to avoid the NULL pointer dereference in
On 2022-12-07 09:21, Jiasheng Jiang wrote:
As kzalloc may fail and return NULL pointer, it should be better to check
the return value in order to avoid the NULL pointer dereference in
__drm_atomic_helper_connector_reset.
This commit message is nonsense; if
__drm_atomic_helper_connector_reset()
On 2022-11-30 19:59, Mikhail Krylov wrote:
On Wed, Nov 30, 2022 at 11:07:32AM -0500, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 10:42 AM Robin Murphy wrote:
On 2022-11-30 14:28, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy wrote:
On 2022-11-29 17:11, Mikhail Krylov
On 2022-11-30 14:28, Alex Deucher wrote:
On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy wrote:
On 2022-11-29 17:11, Mikhail Krylov wrote:
On Tue, Nov 29, 2022 at 11:05:28AM -0500, Alex Deucher wrote:
On Tue, Nov 29, 2022 at 10:59 AM Mikhail Krylov wrote:
On Tue, Nov 29, 2022 at 09:44:19AM
1 - 100 of 589 matches
Mail list logo
