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 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
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:
On 2024-03-01 4:42 pm, abdellatif.elkhl...@arm.com wrote:
From: Abdellatif El Khlifi
introduce the bindings for Arm remoteproc support.
Signed-off-by: Abdellatif El Khlifi
---
.../bindings/remoteproc/arm,rproc.yaml| 69 +++
MAINTAINERS
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
7c0802a6 6000 7c0802a6 fba1ffe8
fbc1fff0 fbe1fff8 7cbf2b78 38a0 7cdd3378 f8010010 f821ffc1
4bff95d1 6000 7c7e1b79
[ 981.124374] ---[ end trace ]---
Thanks and Regards
On 1/31/24 16:18, Robin Murphy wrote:
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings,
[mainline] [linux-next] [6.8-rc1] [DLPAR] OOps kernel crash after
performing dlpar remove test
--- Traces ---
[58563.146236] BUG: Unable to handle kernel data access at
0x6b6b6b6b6b6b6b83
[58563.146242] Faulting instruction
On 2023-12-15 7:13 am, Kever Yang wrote:
Hi Jagan,
On 2023/12/15 14:36, Jagan Teki wrote:
Hi Heiko/Kerver/Anatoloj,
On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki
wrote:
Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would
support external vendor PHY with DW HDMI chip.
Support
, at least) in the SMMU
getting wedged and the GPU stuck without memory access.
Reviewed-by: Robin Murphy
Cc: sta...@vger.kernel.org
Signed-off-by: Rob Clark
---
I didn't add a fixes tag because really this issue has been there
all along, but either didn't matter with other firmware or we didn't
On 07/12/2023 9:24 pm, Rob Clark wrote:
From: Rob Clark
We also want the default domain for the GMU to be an identy domain,
so it does not get a context bank assigned. Without this, both
of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
allocating and configuring a context
On 07/12/2023 12:54 pm, Dmitry Baryshkov wrote:
In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).
Acked-by: Robin Murphy
Unless Joerg disagrees, I think it should be fine
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 +-
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 +-
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 +-
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
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
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
On 28/11/2023 11:50 pm, Jason Gunthorpe wrote:
On Tue, Nov 28, 2023 at 06:00:13PM -0500, Pasha Tatashin wrote:
On Tue, Nov 28, 2023 at 5:53 PM Robin Murphy wrote:
On 2023-11-28 8:49 pm, Pasha Tatashin wrote:
Convert iommu/fsl_pamu.c to use the new page allocation functions
provided in iommu
On 2023-11-28 10:50 pm, Pasha Tatashin wrote:
On Tue, Nov 28, 2023 at 5:34 PM Robin Murphy wrote:
On 2023-11-28 8:49 pm, Pasha Tatashin wrote:
Convert iommu/dma-iommu.c to use the new page allocation functions
provided in iommu-pages.h.
These have nothing to do with IOMMU pagetables
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/mediatek
On 2023-11-16 4:17 am, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote:
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested
On 2023-11-16 4:17 am, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 08:23:54PM +, Robin Murphy wrote:
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously
On 2023-11-15 3:36 pm, Jason Gunthorpe wrote:
On Wed, Nov 15, 2023 at 03:22:09PM +, Robin Murphy wrote:
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously far, far too much for a stable
fix, but then it's also not the refactoring we want for the future
either,
On 2023-11-15 2:05 pm, Jason Gunthorpe wrote:
[Several people have tested this now, so it is something that should sit in
linux-next for a while]
What's the aim here? This is obviously far, far too much for a stable
fix, but then it's also not the refactoring we want for the future
either,
On 11/11/2023 6:45 pm, Chuck Zmudzinski wrote:
Enabling the new option, ARM_DMA_USE_IOMMU_XEN, fixes this error when
attaching the Exynos mixer in Linux dom0 on Xen on the Chromebook Snow
(and probably on other devices that use the Exynos mixer):
[drm] Exynos DRM: using 1440.fimd device for
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
On 2023-11-03 5:02 pm, Duje Mihanović wrote:
On Friday, November 3, 2023 4:34:54 PM CET Robin Murphy wrote:
On 2023-11-02 3:20 pm, Duje Mihanović wrote:
+config ARCH_MMP
+ bool "Marvell MMP SoC Family"
+ select ARM_GIC
+ select ARM_ARCH_TIMER
+ select ARM_
On 2023-11-02 3:20 pm, Duje Mihanović wrote:
Add ARCH_MMP configuration option for Marvell PXA1908 SoC.
Signed-off-by: Duje Mihanović
---
arch/arm64/Kconfig.platforms | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
On 2023-11-02 3:26 pm, Mark Brown wrote:
On Thu, Nov 02, 2023 at 04:20:29PM +0100, Duje Mihanović wrote:
The SSPA driver currently seems to generate ARM32 assembly, which causes
build errors when building a kernel for an ARM64 ARCH_MMP platform.
Fixes: fa375d42f0e5 ("ASoC: mmp: add sspa
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
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
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/apple-dart.c
On 2023-09-26 20:34, Robin Murphy wrote:
On 2023-09-26 20:05, Janne Grunau wrote:
Hej,
On Fri, Sep 22, 2023 at 02:07:57PM -0300, Jason Gunthorpe wrote:
Move to the new static global for blocked domains. Move the blocked
specific code to apple_dart_attach_dev_blocked().
Signed-off-by: Jason
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
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
On 2023-09-25 14:29, Jason Gunthorpe wrote:
On Mon, Sep 25, 2023 at 02:07:50PM +0100, Robin Murphy wrote:
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings
eit
On 2023-09-23 00:33, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 07:07:40PM +0100, Robin Murphy wrote:
virtio isn't setting ops->pgsize_bitmap for the sake of direct mappings
either; it sets it once it's discovered any instance, since apparently it's
assuming that all instances must supp
On 22/09/2023 5:27 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 02:13:18PM +0100, Robin Murphy wrote:
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temporary
On 22/09/2023 1:41 pm, Jason Gunthorpe wrote:
On Fri, Sep 22, 2023 at 08:57:19AM +0100, Jean-Philippe Brucker wrote:
They're not strictly equivalent: this check works around a temporary issue
with the IOMMU core, which calls map/unmap before the domain is
finalized.
Where? The above points to
On 2023-09-21 17:44, Jason Gunthorpe wrote:
On Thu, Sep 21, 2023 at 08:12:03PM +0800, Baolu Lu wrote:
On 2023/9/21 15:51, Yi Liu wrote:
diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index 4a7c5c8fdbb4..3c8660fe9bb1 100644
--- a/include/uapi/linux/iommufd.h
+++
On 20/09/2023 3:32 pm, Mark Rutland wrote:
Hi Naresh,
On Wed, Sep 20, 2023 at 11:29:12AM +0200, Naresh Kamboju wrote:
[ my two cents ]
While running LTP pty07 test cases on arm64 juno-r2 with Linux next-20230919
the following kernel crash was noticed.
I have been noticing this issue
On 2023-09-19 09:15, Jean-Philippe Brucker wrote:
On Mon, Sep 18, 2023 at 05:37:47PM +0100, Robin Murphy wrote:
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 17dcd826f5c2..3649586f0e5c 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
On 2023-09-18 12:51, Niklas Schnelle wrote:
Pull out the sync operation from viommu_map_pages() by implementing
ops->iotlb_sync_map. This allows the common IOMMU code to map multiple
elements of an sg with a single sync (see iommu_map_sg()). Furthermore,
it is also a requirement for
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
On 2023-09-06 19:10, Laurentiu Tudor wrote:
On 9/6/2023 8:21 PM, Robin Murphy wrote:
On 2023-09-06 17:01, Laurentiu Tudor wrote:
MC being a plain DMA master as any other device in the SoC and
being live at OS boot time, as soon as the SMMU is probed it
will immediately start triggering
On 2023-09-06 17:01, Laurentiu Tudor wrote:
MC being a plain DMA master as any other device in the SoC and
being live at OS boot time, as soon as the SMMU is probed it
will immediately start triggering faults because there is no
mapping in the SMMU for the MC. Pre-create such a mapping in
the
On 2023-09-04 16:34, Jean-Philippe Brucker wrote:
On Fri, Aug 25, 2023 at 05:21:26PM +0200, Niklas Schnelle wrote:
Add ops->flush_iotlb_all operation to enable virtio-iommu for the
dma-iommu deferred flush scheme. This results inn a significant increase
in
in performance in exchange for a
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
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
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
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
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
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
IW,
Acked-by: Robin Murphy
I guess you're hoping for Joerg to pick this up? However I wouldn't
foresee any major conflicts if you do need to take it through the OF tree.
Cheers,
Robin.
Signed-off-by: Rob Herring
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 2 +-
drivers/iommu/ar
On 27/06/2023 11:24 am, Greg Kroah-Hartman wrote:
On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
+/**
+ * is_swiotlb_active() - check if the software IO TLB is initialized
+ * @dev: Device to check, or %NULL for the default IO TLB.
+ */
bool is_swiotlb_active(struct
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-06-01 20:46, Jason Gunthorpe wrote:
On Thu, Jun 01, 2023 at 08:37:45PM +0100, Robin Murphy wrote:
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY
On 2023-05-16 01:00, Jason Gunthorpe wrote:
These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively
allows them to support that mode.
The prior work to require default_domains makes this safe because every
one of these drivers is either compilation incompatible with
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Robin was able to check the documentation and what fsl_pamu has
historically called detach_dev() is really putting the IOMMU into an
IDENTITY mode.
Unfortunately it was the other way around - it's the call to
fsl_setup_liodns() from fsl_pamu_probe()
On 2023-05-16 01:00, Jason Gunthorpe wrote:
This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING
domain, so it saves a few lines in a lot of drivers needlessly checking
the type.
More critically, this allows us to sweep out all the
IOMMU_DOMAIN_UNMANAGED and IOMMU_DOMAIN_DMA
On 2023-05-16 01:00, Jason Gunthorpe wrote:
Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the
same stuff, the way they relate to the IOMMU core is quiet different.
dma-iommu.c expects the core code to setup an UNMANAGED domain (of type
IOMMU_DOMAIN_DMA) and then
On 2023-05-16 01:00, Jason Gunthorpe wrote:
The PLATFORM domain will be set as the default domain and attached as
normal during probe. The driver will ignore the initial attach from a NULL
domain to the PLATFORM domain.
After this, the PLATFORM domain's attach_dev will be called whenever we
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
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
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-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 31/03/2023 3:00 pm, Arnd Bergmann wrote:
On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote:
On 2023-03-27 13:13, Arnd Bergmann wrote:
[ HELP NEEDED: can anyone confirm that it is a correct assumption
on arm that a cache-coherent device writing to a page always results
in it being
On 31/03/2023 3:00 pm, Arnd Bergmann wrote:
On Mon, Mar 27, 2023, at 14:48, Robin Murphy wrote:
On 2023-03-27 13:13, Arnd Bergmann wrote:
[ HELP NEEDED: can anyone confirm that it is a correct assumption
on arm that a cache-coherent device writing to a page always results
in it being
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use
On 2023-02-22 13:37, Jiaxun Yang wrote:
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in
On 2023-02-22 13:04, Jiaxun Yang wrote:
2023年2月22日 12:55，Robin Murphy 写道：
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the main purpose of this patch is to fix MIPS’s broken per-device coherency.
On 2023-02-21 17:58, Christoph Hellwig wrote:
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
dma_default_coherent can be useful for determine default coherency
even on arches without noncoherent support.
How?
Indeed, "default" is conceptually meaningless when there is no
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 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 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 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-20 15:28, Jean-Philippe Brucker wrote:
For some reason this came through as blank mail with a text attachment,
so apologies for the lack of quoting, but for reference this is a
long-standing known issue:
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
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
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
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
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
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
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
1 - 100 of 7722 matches
Mail list logo
