[PATCH] dma-mapping: tidy up dma_parms default handling

a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous else statements. Signed-off-by: Robin Murphy robin.mur...@arm.com --- Hi Vinod, dmaengine folks, This isn't strictly a dmaengine patch, but get_maintainer.pl pointed at you, and there do happen

Re: dmapool regression in next

On 06/12/2018 15:11, Tony Battersby wrote: On 12/6/18 4:25 AM, Krzysztof Kozlowski wrote: On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote: Hi, Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)" on

Re: [PATCH 2/9] ACPI/IORT: Use helper functions to access dev->iommu_fwspec

On 04/12/2018 16:29, Joerg Roedel wrote: From: Joerg Roedel Use the new helpers dev_iommu_fwspec_get()/set() to access the dev->iommu_fwspec pointer. This makes it easier to move that pointer later into another struct. Cc: Lorenzo Pieralisi Signed-off-by: Joerg Roedel ---

Re: dw_mmc: IDMAC Invalidate cache after read

Hi Jan, [repeating some of the discussion from your other thread for the benefit of the MMC audience] On 21/11/2018 07:42, JABLONSKY Jan wrote: CPU may not see most up-to-date and correct copy of DMA buffer, when internal DMA controller is in use. Problem appears on The Altera SoC FPGA (uses

Re: [PATCH 3/3] spi: at91-usart: add DMA support

On 21/11/2018 11:27, Radu Pirea wrote: This patch adds support for DMA. Transfers are done with dma only if they are longer than 16 bytes in order to achieve a better performance. DMA setup introduces a little overhead and for transfers shorter than 16 bytes there is no performance improvement.

Re: [PATCH v4] arm64: dts: rockchip: Add DT for nanopc-t4

Hi Tomeu, On 2018-11-27 9:07 am, Tomeu Vizoso wrote: This adds a device tree for the NanoPC-T4 SBC, which is based on the Rockchip RK3399 SoC and marketed by FriendlyELEC. I'm happy to see this, as mine's been sat waiting until I could find time to wrangle a mainline DT for it :) Known

Re: remove the ->mapping_error method from dma_map_ops V2

On 22/11/2018 17:09, Linus Torvalds wrote: On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux wrote: I'm afraid that won't work very well - 32 bit platforms with 64-bit addresses (LPAE) would have dma_addr_t as a 64-bit value, which wouldn't fit into an unsigned long. Good point. So

Re: [PATCH] pci: imx6: support kernels built in Thumb-2 mode

Hi Stefan, On 28/11/2018 13:25, Stefan Agner wrote: Add a fault handler which handles reads in Thumb-2 mode. Install the appropriate handler depending on which mode the kernel has been built. This avoids an "Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0a8" during boot on

Re: [PATCH] pci: imx6: support kernels built in Thumb-2 mode

On 28/11/2018 17:53, Stefan Agner wrote: On 28.11.2018 17:16, Robin Murphy wrote: Hi Stefan, On 28/11/2018 13:25, Stefan Agner wrote: Add a fault handler which handles reads in Thumb-2 mode. Install the appropriate handler depending on which mode the kernel has been built. This avoids

Re: [PATCH] pci: imx6: support kernels built in Thumb-2 mode

On 28/11/2018 18:56, Trent Piepho wrote: On Wed, 2018-11-28 at 16:16 +, Robin Murphy wrote: +static int imx6q_pcie_abort_handler_thumb2(unsigned long addr, + unsigned int fsr, struct pt_regs *regs) +{ + unsigned long pc = instruction_pointer(regs); + unsigned

Re: [PATCH v4 4/4] perf/smmuv3_pmu: Enable HiSilicon Erratum 162001800 quirk

Hi Shameer, Sorry for the delay... On 18/10/2018 16:27, Shameerali Kolothum Thodi wrote: -Original Message- From: Linuxarm [mailto:linuxarm-boun...@huawei.com] On Behalf Of Shameerali Kolothum Thodi Sent: 18 October 2018 14:34 To: Robin Murphy ; lorenzo.pieral...@arm.com; jean

Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size

On 19/11/2018 14:18, Ramon Fried wrote: On Tue, Oct 9, 2018 at 8:02 AM Benjamin Herrenschmidt wrote: On Wed, 2018-10-03 at 16:10 -0700, Alexander Duyck wrote: -* Because 32-bit DMA masks are so common we expect every architecture -* to be able to satisfy them - either by not

Re: [PATCH v2 3/4] perf: add arm64 smmuv3 pmu driver

On 18/09/18 12:47, Will Deacon wrote: On Mon, Sep 17, 2018 at 06:10:05PM +0100, John Garry wrote: + +#define SMMU_EVENT_ATTR(_name, _id) \ +(&((struct perf_pmu_events_attr[]) { \ +{ .attr = __ATTR(_name, 0444, smmu_pmu_event_show, NULL), \ +

[PATCH v6 6/7] iommu/arm-smmu: Support non-strict mode

-pgtable for that combination just so anyone who does actually try it will simply get over-invalidation instead of failure to initialise domains. Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 43 +--- 1 file changed, 36 insertions(+), 7 deletions

[PATCH v6 3/7] iommu/io-pgtable-arm: Add support for non-strict mode

-by: Zhen Lei [rm: tweak comment, commit message, and split_blk_unmap logic] Signed-off-by: Robin Murphy --- drivers/iommu/io-pgtable-arm.c | 9 ++--- drivers/iommu/io-pgtable.h | 5 + 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers

[PATCH v6 5/7] iommu/arm-smmu-v3: Add support for non-strict mode

From: Zhen Lei Dynamically choose strict or non-strict mode for page table config based on the iommu domain type. Signed-off-by: Zhen Lei [rm: convert to domain attribute] Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu-v3.c | 33 +++-- 1 file changed, 27

Re: [PATCH 3/3] dt-bindings: remoteproc: Add Arm remoteproc

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

Re: [PATCH/RFC 4/4] iommu/arm-smmu: Support deferred probing

Hi Laura, As a heads up, I'm still vainly hoping to move the ARM SMMU driver entirely over to the generic framework - there's an iommu/dev branch on top of the iommu/dma branch I pushed earlier[1] which you might want to take a peek at to check if we're likely to end up pulling in different

Re: [RFCv2 1/2] device: add dma_params-max_segment_count

Hi Sumit, On 21/01/15 04:16, Sumit Semwal wrote: From: Rob Clark robdcl...@gmail.com For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

Hi Murali, On 23/01/15 22:32, Murali Karicheri wrote: Fix the dma-range size when the DT attribute is missing. i.e set size to dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect overflow when mask is set to max of u64, add a check, log error and return. Some platform use

Re: [PATCH v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size

Hi Murali, On 23/01/15 22:32, Murali Karicheri wrote: Limit the dma_mask to minimum of dma_mask and dma_base + size - 1. Also arm_iommu_create_mapping() has size parameter of size_t and arm_setup_iommu_dma_ops() can take a value higher than that. So limit the size to SIZE_MAX. Signed-off-by:

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

On 28/01/15 11:05, Catalin Marinas wrote: On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote: On 01/27/2015 06:27 AM, Robin Murphy wrote: On 23/01/15 22:32, Murali Karicheri wrote: Fix the dma-range size when the DT attribute is missing. i.e set size to dev-coherent_dma_mask + 1

Re: [PATCH v5 3/8] of: fix size when dma-range is not used

Hi Murali, [sorry, missed replying to yesterday's version] On 27/01/15 21:00, Murali Karicheri wrote: Fix the dma-range size when the DT attribute is missing. i.e set size to dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add code to check invalid values of size configured

Re: [PATCH 2/5] iommu: Allocate a default domain for iommu groups

On 28/01/15 14:30, Will Deacon wrote: On Tue, Jan 27, 2015 at 12:08:56AM +, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The default domain will be used (if supported by the iommu driver) when the devices in the iommu group are not attached to any other domain. Signed-off-by:

Re: [PATCH RESEND] dma-mapping: tidy up dma_parms default handling

On 09/01/15 19:45, Arnd Bergmann wrote: On Friday 09 January 2015 16:56:03 Robin Murphy wrote: This one's a bit tricky to find a home for - I think technically it's probably an IOMMU patch, but then the long-underlying problem doesn't seem to have blown up anything until arm64, and my

[PATCH RESEND] dma-mapping: tidy up dma_parms default handling

a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous else statements. Signed-off-by: Robin Murphy robin.mur...@arm.com --- Hi, various maintainers from Git logs ;) This one's a bit tricky to find a home for - I think technically it's probably

Re: [PATCH 2/5] iommu/mediatek: Add mt8173 IOMMU driver

On 18/03/15 11:22, Yong Wu wrote: Hi Tomasz, Thanks very much for your review. please help check below. The others I will fix in the next version. Hi Robin, There are some place I would like you can have a look and give me some suggestion. On Wed, 2015-03-11 at 19:53 +0900, Tomasz Figa

Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

Hi Suravee, On 05/05/15 16:12, Suravee Suthikulpanit wrote: From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices. This patch introduces ACPI_MUST_HAVE_CCA in arm64

Re: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency

On 11/05/15 18:10, Catalin Marinas wrote: On Fri, May 08, 2015 at 04:08:53PM +0200, Arnd Bergmann wrote: On Friday 01 May 2015 12:06:44 Catalin Marinas wrote: If we just disallow DMA to devices that are marked with _CCA=0 in ACPI, we can avoid this case, or discuss it by the time someone has

Re: [PATCH v2 3/6] iommu: add ARM short descriptor page table allocator.

Oops, seems I'm rather behind on things - I started this review on the RFC, but I'll finish it here... On 15/05/15 10:43, Yong Wu wrote: This patch is for ARM Short Descriptor Format.It has 2-levels pagetable and the allocator supports 4K/64K/1M/16M. From the look of the code, this doesn't

Re: [RFC/PATCH 2/9] arm: dma-mapping: Support IOMMU mappings spanning the full 32 bits range

Hi Laurent, On 15/05/15 00:00, Laurent Pinchart wrote: The arm_iommu_create_mapping() function takes the IOMMU mapping size as a size_t, limiting the size to 4GB - 1 on 32 bit platforms while most bus masters would support the full 32 bits range. Fix this by passing the size as a 64 bits

Re: [RFC/PATCH 6/9] drivers: platform: Configure dma operations at probe time

Hi Laurent, On 15/05/15 00:00, Laurent Pinchart wrote: Configuring DMA ops at probe time will allow deferring device probe when the IOMMU isn't available yet. This is great, as I think it also subtly solves the ordering problem the current domain allocation has with platform devices. WRT to

Re: [PATCH 06/22] iommu: Allocate a default domain for iommu groups

Hi Joerg, On 28/05/15 17:41, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The default domain will be used (if supported by the iommu driver) when the devices in the iommu group are not attached to any other domain. Signed-off-by: Joerg Roedel jroe...@suse.de ---

Re: [PATCH 06/22] iommu: Allocate a default domain for iommu groups

Hi Joerg, On 28/05/15 17:41, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de The default domain will be used (if supported by the iommu driver) when the devices in the iommu group are not attached to any other domain. Signed-off-by: Joerg Roedel jroe...@suse.de ---

Re: [PATCH 08/22] iommu: Make sure a device is always attached to a domain

On 28/05/15 17:41, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de Make use of the default domain and re-attach a device to it when it is detached from another domain. Also enforce that a device has to be in the default domain before it can be attached to a different domain.

Re: [PATCH 10/22] iommu: Introduce direct mapped region handling

On 28/05/15 17:41, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de Add two new functions to the IOMMU-API to allow the IOMMU drivers to export the requirements for direct mapped regions per device. This is useful for exporting the information in Intel VT-d's RMRR entries or AMD-Vi's

Re: [PATCH char-misc-next 10/19] lib: convert iova.c into a library

On 28/07/15 11:03, Joerg Roedel wrote: On Mon, Jul 27, 2015 at 04:57:32PM -0700, Ashutosh Dixit wrote: From: Harish Chegondi harish.chego...@intel.com This patch converts iova.c into a library, moving it from drivers/iommu/ to lib/, and exports its virtual address allocation and management

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

On 16/07/15 10:04, Yong Wu wrote: This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu yong...@mediatek.com [...] +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie) +{ + struct mtk_iommu_domain *domain = cookie; +

Re: [PATCH v3 3/6] iommu: add ARM short descriptor page table allocator.

On 27/07/15 05:21, Yong Wu wrote: [...] +static arm_short_iopte +__arm_short_pte_prot(struct arm_short_io_pgtable *data, int prot, bool large) +{ + arm_short_iopte pteprot; + + pteprot = ARM_SHORT_PTE_S | ARM_SHORT_PTE_nG; + pteprot |= large ? ARM_SHORT_PTE_TYPE_LARGE : +

Re: [PATCH v3 5/6] iommu/mediatek: Add mt8173 IOMMU driver

On 27/07/15 16:31, Russell King - ARM Linux wrote: On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote: On 16/07/15 10:04, Yong Wu wrote: This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu yong...@mediatek.com [...] +static void

Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

at least this patch definitely makes things less wrong in that respect. Reviewed-by: Robin Murphy robin.mur...@arm.com --- This also begs the question as to what happens if the memory region _is_ contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops

Re: [PATCH 3/3] Docs: dt: add PCI IOMMU map bindings

Hi Mark, This looks sane, and lets me describe the thing I have on my desk, so I'm happy. I have a couple of general thoughts below, but I don't intend that they should stand in the way of this proposal as-is. On 23/07/15 17:52, Mark Rutland wrote: The existing IOMMU bindings are able to

Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

Hi Laura, On 17/07/15 17:50, Laura Abbott wrote: On 07/17/2015 08:21 AM, Robin Murphy wrote: Hi Tixy, On 17/07/15 12:01, Jon Medhurst (Tixy) wrote: Use dma_get_sgtable rather than dma_common_get_sgtable so a device's dma_ops aren't bypassed. This is essential in situations where a device

Re: [PATCH v5 5/6] iommu/mediatek: Add mt8173 IOMMU driver

On 09/10/15 03:23, Yong Wu wrote: [...] +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include Nit: ordering? +#include +#include "io-pgtable.h" [...] +struct mtk_iommu_data { + void __iomem

Re: [PATCH v5 4/6] memory: mediatek: Add SMI driver

On 09/10/15 03:23, Yong Wu wrote: [...] +static int mtk_smi_probe(struct platform_device *pdev) +{ + struct device *dev = >dev; + struct mtk_smi_data *smidata; + int ret; + + if (!dev->pm_domain) + return -EPROBE_DEFER; + + smidata = devm_kzalloc(dev,

Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

On 29/10/15 18:28, Will Deacon wrote: On Tue, Oct 27, 2015 at 10:00:11AM -0600, Alex Williamson wrote: On Tue, 2015-10-27 at 15:40 +, Will Deacon wrote: On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote: Would it be possible to add iommu_domain_geometry support to

Re: [RFC/PATCH] media: omap3isp: Set maximum DMA segment size

Hi Laurent, On 09/11/15 14:18, Laurent Pinchart wrote: Hello everybody, Ping ? Apologies, I did start writing a response a while ago, but it ended up getting subsumed into the bigger DMA API discussion thread. On Tuesday 13 October 2015 16:18:36 Laurent Pinchart wrote: The maximum DMA

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

Hi Suravee, On 28/10/15 22:50, Suravee Suthikulpanit wrote: This patch move of_pci_dma_configure() to a more generic pci_dma_configure(), which can be extended by non-OF code (e.g. ACPI). This has no functional change. Unfortunately, it appears that it does... Signed-off-by: Suravee

Re: [PATCH] ARM:dma-mapping: Handle DMA_BIDIRECTIONAL in _dma_page_cpu_to_dev()

On 09/11/15 10:15, Sharma, Sanjeev wrote: On Mon, Nov 09, 2015 at 11:29:17AM +0530, sanjeev sharma wrote: On Wed, Nov 04, 2015 at 10:39:13AM +, Will Deacon wrote: > On Wed, Nov 04, 2015 at 03:26:48PM +0530, Sanjeev Sharma wrote: > > _dma_page_cpu_to_dev() treat

Re: [PATCH V2 2/3] Add iommu driver for hi6220 SoC platform

On 20/10/15 09:45, Chen Feng wrote: iommu/hisilicon: Add hi6220-SoC smmu driver A brief description of the smmu and what capabilities it provides wouldn't go amiss here. Signed-off-by: Chen Feng Signed-off-by: Yu Dongbin ---

Re: [PATCH 4/4] dma-debug: Allow poisoning nonzero allocations

On 29/09/15 22:27, Andrew Morton wrote: [...] If I'm understanding things correctly, some allocators zero the memory by default and others do not. And we have an unknown number of drivers which are assuming that the memory is zeroed. Correct? That's precisely the motivation here, yes. If

Re: [PATCH v4 3/6] iommu: add ARM short descriptor page table allocator.

On 09/10/15 16:57, Will Deacon wrote: On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote: I would like to show you a problem I met, The recursion here may lead to stack overflow while we test FHD video decode. From the log, I get the internal variable in the error case: the

Re: [PATCH v4 5/6] iommu/mediatek: Add mt8173 IOMMU driver

On 03/08/15 11:21, Yong Wu wrote: This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu --- [...] +/* + * There is only one iommu domain called the m4u domain that + * all Multimedia modules share. + */ +static struct

Re: [RFC PATCH 0/3] iommu: Add range flush operation

Hi Tomasz, On 29/09/15 06:25, Tomasz Figa wrote: Currently the IOMMU subsystem provides 3 basic operations: iommu_map(), iommu_map_sg() and iommu_unmap(). iommu_map() can be used to map memory page by page, however it involves flushing the caches (CPU and IOMMU) for every mapped page

Re: [RFC PATCH 0/3] iommu: Add range flush operation

On 29/09/15 15:32, Russell King - ARM Linux wrote: On Tue, Sep 29, 2015 at 03:20:38PM +0100, Robin Murphy wrote: A single callback doesn't really generalise well enough: If we wanted to implement this in the ARM SMMU drivers to optimise the unmap() case [ask Will how long he spends waiting

Re: [RFC PATCH 0/3] iommu: Add range flush operation

On 29/09/15 17:40, Russell King - ARM Linux wrote: On Tue, Sep 29, 2015 at 05:27:12PM +0100, Robin Murphy wrote: Eh, swings and roundabouts. An argument denoting whether the flush is being called on the map or unmap path would be fine, Sorry, that statement is wrong. It's not about whether

Re: [PATCH 1/4] of: Add of_parse_phandle_with_opt_args() helper function

Hi Marc, On 22/09/15 18:52, Marc Zyngier wrote: of_parse_phandle_with_args() is slightly inflexible as it doesn't allow the (unusual) case where the #*-cells property is not defined. In order to support this, introduce of_parse_phandle_with_opt_args() which assumes that #*-cells is zero when it

Re: How to ensure that different peripherals getting different IOVA address in kernel?

On 23/09/15 02:55, chenfeng wrote: Hi all, In IOMMU architecture , how to make two different peripherals share the same page table ? In other words , is there a mechanism or structure to make two peripherals get completely different address. eg: peri-A、peri-B and peri-C share the same iova

Re: [PATCH v2 3/3] irqchip/gicv3-its: Handle OF device tree "msi-map" properties.

On 23/09/15 19:18, Marc Zyngier wrote: On Wed, 23 Sep 2015 18:52:59 +0100 Will Deacon wrote: On Wed, Sep 23, 2015 at 06:08:39PM +0100, David Daney wrote: On 09/23/2015 10:01 AM, Marc Zyngier wrote: On Tue, 22 Sep 2015 17:00:06 -0700 David Daney

Re: [PATCH 4/4] dma-debug: Allow poisoning nonzero allocations

Hi Russell, On 25/09/15 13:44, Russell King - ARM Linux wrote: On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote: Since some dma_alloc_coherent implementations return a zeroed buffer regardless of whether __GFP_ZERO is passed, there exist drivers which are implicitly dependent

Re: [RESEND PATCH] media: vb2: Fix vb2_dc_prepare do not correct sync data to device

Hi Hans, On 21/09/15 14:13, Hans Verkuil wrote: Hi Tiffany! On 21-09-15 14:26, Tiffany Lin wrote: vb2_dc_prepare use the number of SG entries dma_map_sg_attrs return. But in dma_sync_sg_for_device, it use lengths of each SG entries before dma_map_sg_attrs. dma_map_sg_attrs will concatenate

[PATCH 3/4] dma-debug: Check nents in dma_sync_sg*

Like dma_unmap_sg, dma_sync_sg* should be called with the original number of entries passed to dma_map_sg, so do the same check in the sync path as we do in the unmap path. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- lib/dma-debug.c | 8 1 file changed, 8 insertions(+)

[PATCH 1/4] dmapool: Fix overflow condition in pool_find_page

If a DMA pool lies at the very top of the dma_addr_t range (as may happen with an IOMMU involved), the calculated end address of the pool wraps around to zero, and page lookup always fails. Tweak the relevant calculation to be overflow-proof. Signed-off-by: Robin Murphy <robin.mur...@arm.

[PATCH 0/4] Assorted DMA mapping tweaks

a related patch in -next from Sakari clarifying the docs. #4 seemed worth posting now that the recent rework means it no longer has to be a sprawling touch-all-the-architectures patch for something so small. Thanks, Robin. [0]:http://thread.gmane.org/gmane.linux.kernel/2043117 Robin Murphy (4

[PATCH 2/4] dma-mapping: Tidy up dma_parms default handling

, clean up a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous "else" statements. Acked-by: Marek Szyprowski <m.szyprow...@samsung.com> Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org> Signed-off-by: Robin Murphy <robin

[PATCH 4/4] dma-debug: Allow poisoning nonzero allocations

on different platforms, where nonzero uninitialised junk may for instance occasionally look like a valid command which causes the hardware to start misbehaving. To help with debugging such issues, add the option to make uninitialised buffers much more obvious. Signed-off-by: Robin Murphy <robin.

Re: [PATCH v5 2/4] drm: Add support for ARM's HDLCD controller.

<airl...@linux.ie> > Cc: Robin Murphy <robin.mur...@arm.com> I've given this a spin on my Juno, and the first thing of note is this: hdlcd 7ff6.hdlcd: master bind failed: -517 hdlcd 7ff5.hdlcd: master bind failed: -517 scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.9.0 ve

Re: [PATCH 6/9] dmaengine:pl330: set segment_boundary_mask = 0cffffffff

On 04/12/15 03:24, Wang Hongcheng wrote: Because amd iommu and software iommu need this mask.For example, if we use software iommu without this mask, we will get 'Out of SW-IOMMU space' error, when calling swiotlb_map_page function. The commit title doesn't match the code, but either way this

Re: [PATCH] ARM: dma-mapping: Just allocate one chunk at a time

Hi Doug, On 17/12/15 22:31, Doug Anderson wrote: Hi, On Thu, Dec 17, 2015 at 12:30 PM, Douglas Anderson wrote: The __iommu_alloc_buffer() is expected to be called to allocate pretty sizeable buffers. Upon simple tests of video I saw it trying to allocate 4,194,304

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

On 15/12/15 03:28, Yong Wu wrote: On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote: On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote: +static int mtk_iommu_attach_device(struct iommu_domain *domain, + struct device *dev) +{ + struct

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

On 16/12/15 05:59, Yong Wu wrote: On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote: On 15/12/15 03:28, Yong Wu wrote: On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote: On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote: +static int mtk_iommu_attach_device(struct iommu_domain

Re: [PATCH v5 2/4] drm: Add support for ARM's HDLCD controller.

On 08/12/15 16:52, Liviu Dudau wrote: On Tue, Dec 08, 2015 at 04:25:27PM +, Robin Murphy wrote: Hi Liviu, On 07/12/15 12:11, Liviu Dudau wrote: The HDLCD controller is a display controller that supports resolutions up to 4096x4096 pixels. It is present on various development boards

Re: [PATCH v7 4/5] iommu/mediatek: Add mt8173 IOMMU driver

On 18/12/15 08:09, Yong Wu wrote: This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu --- drivers/iommu/Kconfig | 14 + drivers/iommu/Makefile| 1 + drivers/iommu/mtk_iommu.c | 734

[PATCH 1/2] io-64-nonatomic: Add relaxed accessor variants

@lst.de> CC: Darren Hart <dvh...@linux.intel.com> CC: Hitoshi Mitake <mitake.hito...@lab.ntt.co.jp> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- include/linux/io-64-nonatomic-hi-lo.h | 25 + include/linux/io-64-nonatomic-lo-hi.h | 25 ++

[PATCH 2/2] iommu/arm-smmu: Tidy up 64-bit/atomic I/O accesses

with SMMUv2 under a 64-bit kernel. Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/iommu/arm-smmu.c | 48 +++- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 5

Re: [PATCH] ARM: dma-mapping: Just allocate one chunk at a time

On 18/12/15 18:55, Doug Anderson wrote: Robin, On Fri, Dec 18, 2015 at 4:41 AM, Robin Murphy <robin.mur...@arm.com> wrote: Hi Doug, On 17/12/15 22:31, Doug Anderson wrote: Hi, On Thu, Dec 17, 2015 at 12:30 PM, Douglas Anderson <diand...@chromium.org> wrote: The __iommu_

Re: [PATCH V5 8/9] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()

+Arnd On 17/11/15 15:00, Robin Murphy wrote: Hi Suravee, On 28/10/15 22:50, Suravee Suthikulpanit wrote: This patch move of_pci_dma_configure() to a more generic pci_dma_configure(), which can be extended by non-OF code (e.g. ACPI). This has no functional change. Unfortunately, it appears

Re: [PATCH v2] of: iommu: make of_iommu_init() postcore_initcall_sync

On 08/06/16 16:44, Rob Herring wrote: On Wed, Jun 1, 2016 at 1:06 AM, Kefeng Wang wrote: The of_iommu_init() is called multiple times by arch code, make it postcore_initcall_sync, then we can drop relevant calls fully. Note, the IOMMUs should have a chance to

Re: [PATCH] arm64: Implement arch_setup_pdev_archdata hook

On 07/06/16 09:29, Baolin Wang wrote: Now on ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if it did not call 'arch_setup_dma_ops' at device creation time by issuing platform_device_alloc() function, that will cause failure when setting the dma mask for device. Yes, that's

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

regular DMA ops, if the allocation is provided by an IOMMU then such assumptions can fall apart spectacularly. To resolve this, reroute the fb_mmap call to the appropriate DMA API implementation, as per the other cma_helper calls. Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch> Signed-off-by:

Re: [PATCH] drm/fb_cma_helper: Implement fb_mmap callback

On 07/06/16 15:43, Daniel Vetter wrote: On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote: In the absence of an fb_mmap callback, the fbdev code falls back to a naive implementation which relies upon the DMA address being the same as the physical address, and the buffer being

Re: [PATCH v4 05/44] arm64: dma-mapping: Use unsigned long for dma_attrs

dma_addr_t handle, struct dma_attrs *attrs) + dma_addr_t handle, + unsigned long attrs) Nit: unnecessary line break? Otherwise, though, I'm all for the idea; Acked-by: Robin Murphy <robin.mur...@arm.com> { size_

Re: [PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

On 13/06/16 10:56, Shunqian Zheng wrote: Hi On 2016年06月10日 17:10, Tomasz Figa wrote: Hi, On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng wrote: Use DMA API instead of architecture internal functions like __cpuc_flush_dcache_area() etc. To support the virtual device

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

that support it. Signed-off-by: Wei Chen <wei.c...@arm.com> Makes sense to me: Reviewed-by: Robin Murphy <robin.mur...@arm.com> p.s. The confidential disclaimer is a good way to get patches ignored here on the lists - please check with Steve about getting set up on the appropriate

Re: [PATCH] drivers: char: mem: Check {read,write}_kmem() addresses

On 31/05/16 14:46, Catalin Marinas wrote: On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote: Arriving at read_kmem() with an offset representing a bogus kernel address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user faulting on the kernel-space read. x86_

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

On 25/05/16 22:43, Wei Yang wrote: On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: On 25/05/16 00:06, Wei Yang wrote: Hi, Joerg Not sure whether you think this calculation is correct. If I missed something for this " + 1" in your formula, I am glad to hear your expla

[PATCH v2] drivers: char: mem: Check {read,write}_kmem() addresses

e that consistent across {read,write}_kem() too. Reported-by: Kefeng Wang <wangkefeng.w...@huawei.com> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- v2: Make the error code consistent and more appropriate, tweak commit message. drivers/char/mem.c | 6 ++ 1 file changed,

[PATCH] drivers: char: mem: Check {read,write}_kmem() addresses

efeng.w...@huawei.com> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- I'm not sure if this warrants going to stable or not, as it's really just making an existing failure case more graceful and less confusing. drivers/char/mem.c | 6 ++ 1 file changed, 6 insertions(+) diff

Re: [BUG] Page allocation failures with newest kernels

On 31/05/16 04:02, Marcin Wojtas wrote: Hi, After rebasing platform support of two different ARMv8 SoC's from v4.1 baseline to v4.4 it occurred that stressed systems tend to have page allocation problems, related to creating new slabs: http://pastebin.com/FhRW5DsF Steps to reproduce: - use

Re: [PATCH] drivers: char: mem: Check {read,write}_kmem() addresses

On 31/05/16 14:08, Russell King - ARM Linux wrote: On Tue, May 31, 2016 at 01:52:45PM +0100, Robin Murphy wrote: Arriving at read_kmem() with an offset representing a bogus kernel address (e.g. 0 from a simple "cat /dev/kmem") leads to copy_to_user faulting on the kernel-space rea

Re: [RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to attach DMA ops

is actually carried out. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> Cc: Will Deacon <will.dea...@arm.com> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: Robin Murphy <robin.mur...@arm.com> --- arch/arm64/mm/dma-mapping.c | 2 +- 1 file changed, 1 insertion

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

On 23/06/16 13:13, Manjeet Pawar wrote: From: Rohit Thapliyal swiotlb default size of 64M is too big as default value therefore it is made configurable through command line through swiotlb_size parameter. swiotlb allocation shall be done only when the swiotlb size is

Re: [RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to attach DMA ops

Hi Lorenzo, On 17/06/16 15:15, Lorenzo Pieralisi wrote: I think this patch makes sense even independent of the rest of the series, one nit inline notwithstanding. Thanks. Yes I added it to this series since it is not strictly necessary (ie it does not fix anything) in the mainline, but it

Re: [PATCH] arm64:swiotlb:Enable only when Input size through command line

Hi Konrad, On 24/06/16 11:46, Konrad Rzeszutek Wilk wrote: > On Fri, Jun 24, 2016 at 10:57:29AM +0800, Jisheng Zhang wrote: >> Dear Konrad, >> >> On Thu, 23 Jun 2016 12:06:10 -0400 Konrad Rzeszutek Wilk wrote: >> >>> On June 23, 2016 10:30:34 AM EDT, Catalin Marinas >>>

Re: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO access

On 01/02/16 19:58, Stephen Boyd wrote: On 02/01, Robin Murphy wrote: So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame frame are already enabled. Whilst it's the firmware's job to give us non-secure access

Re: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO access

On 05/02/16 15:32, Daniel Lezcano wrote: On 02/05/2016 04:29 PM, Robin Murphy wrote: On 01/02/16 19:58, Stephen Boyd wrote: On 02/01, Robin Murphy wrote: So far, we have been blindly assuming that having access to a memory-mapped timer frame implies that the individual elements of that frame

[PATCH] of/irq: Fix msi-map calculation for nonzero rid-base

this, and at the same time add a sanity check against having msi-map-mask clash with a nonzero rid-base, as that's another thing one can easily get wrong. CC: <sta...@vger.kernel.org> Signed-off-by: Robin Murphy <robin.mur...@arm.com> --- drivers/of/irq.c | 9 - 1 file changed,

Re: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

Hi Mark, On 08/02/16 17:50, Mark Rutland wrote: On Mon, Feb 08, 2016 at 05:30:49PM +, Brian Starkey wrote: Hi, I'm resending these again to try and garner some interest. Without this series, dma-coherent cannot be used on arm64 platforms. I think you need to characterize that a bit

Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base

On 09/02/16 16:08, Mark Rutland wrote: [...] having msi-map-mask clash with a nonzero rid-base, as that's another thing one can easily get wrong. [...] + if (rid_base & ~map_mask) { + dev_err(parent_dev, + "Invalid msi-map

Re: [PATCH v3 3/8] dma-mapping: add dma_{map,unmap}_resource

Hi Niklas, Thanks for doing this, it looks good. Just a couple of minor comments on this and the next patch... On 10/02/16 00:57, Niklas Söderlund wrote: Map/Unmap a device resource from a physical address. If no dma_map_ops method is available the operation is a no-op. Signed-off-by:

  1   2   3   4   5   6   7   8   9   10   >