[PATCH 1/8] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys()

2019-07-31 Thread Nicolas Saenz Julienne
By the time we call zones_sizes_init() arm64_dma_phys_limit already contains the result of max_zone_dma_phys(). We use the variable instead of calling the function directly to save some precious cpu time. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c | 2 +- 1 file changed, 1

[PATCH 7/8] arm64: update arch_zone_dma_bits to fine tune dma-direct min mask

2019-07-31 Thread Nicolas Saenz Julienne
With the introduction of ZONE_DMA in arm64 devices are not forced to support 32 bit DMA masks. We have to inform dma-direct of this limitation whenever it happens. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions

[PATCH 2/8] arm64: rename variables used to calculate ZONE_DMA32's size

2019-07-31 Thread Nicolas Saenz Julienne
Let the name indicate that they are used to calculate ZONE_DMA32's size as opposed to ZONE_DMA. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64

[PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size

2019-07-31 Thread Nicolas Saenz Julienne
zones. Signed-off-by: Nicolas Saenz Julienne --- drivers/of/fdt.c | 72 ++ include/linux/of_fdt.h | 2 ++ 2 files changed, 74 insertions(+) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 9cdf14b9aaab..f2444c61a136 100644 --- a/drivers

[PATCH 6/8] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-07-31 Thread Nicolas Saenz Julienne
Some architectures, notably arm64, are interested in tweaking this depending on their runtime dma addressing limitations. Signed-off-by: Nicolas Saenz Julienne --- arch/powerpc/include/asm/page.h | 9 - arch/powerpc/mm/mem.c | 14 -- arch/s390/include/asm/page.h

[PATCH 8/8] mm: comment arm64's usage of 'enum zone_type'

2019-07-31 Thread Nicolas Saenz Julienne
arm64 uses both ZONE_DMA and ZONE_DMA32 for the same reasons x86_64 does: peripherals with different DMA addressing limitations. This updates both ZONE_DMAs comments to inform about the usage. Signed-off-by: Nicolas Saenz Julienne --- include/linux/mmzone.h | 21 +++-- 1 file

[PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices

2019-07-31 Thread Nicolas Saenz Julienne
the SoC's devices and ZONE_DMA32 the rest of the 32 bit addressable memory. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/Kconfig | 4 arch/arm64/mm/init.c | 38 -- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/arch/arm64

[PATCH 0/8] Raspberry Pi 4 DMA addressing support

2019-07-31 Thread Nicolas Saenz Julienne
*. That's all. Regards, Nicolas * These solutions where already discussed on the previous RFC (see link above). --- Nicolas Saenz Julienne (8): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size of/fdt: add

[PATCH 4/8] arm64: re-introduce max_zone_dma_phys()

2019-07-31 Thread Nicolas Saenz Julienne
Some devices might have multiple interconnects with different DMA addressing limitations. This function provides the higher physical address accessible by all peripherals on the SoC. If such limitation doesn't exist it'll return 0. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c

Re: [PATCH v2 03/11] of/fdt: add of_fdt_machine_is_compatible function

2019-08-20 Thread Nicolas Saenz Julienne
Hi Rob, thanks for the rewiew. On Tue, 2019-08-20 at 12:16 -0500, Rob Herring wrote: > On Tue, Aug 20, 2019 at 9:58 AM Nicolas Saenz Julienne > wrote: > > Provides the same functionality as of_machine_is_compatible. > > > > Signed-off-by: Nicolas Saenz Julienne > &

[PATCH v2 05/11] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys()

2019-08-20 Thread Nicolas Saenz Julienne
By the time we call zones_sizes_init() arm64_dma_phys_limit already contains the result of max_zone_dma_phys(). We use the variable instead of calling the function directly to save some precious cpu time. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: None arch/arm64/mm/init.c | 2

[PATCH v2 03/11] of/fdt: add of_fdt_machine_is_compatible function

2019-08-20 Thread Nicolas Saenz Julienne
Provides the same functionality as of_machine_is_compatible. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: None drivers/of/fdt.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 9cdf14b9aaab..06ffbd39d9af 100644 --- a/drivers

[PATCH v2 01/11] asm-generic: add dma_zone_size

2019-08-20 Thread Nicolas Saenz Julienne
Some architectures have platform specific DMA addressing limitations. This will allow for hardware description code to provide the constraints in a generic manner, so as for arch code to properly setup it's memory zones and DMA mask. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: None

[PATCH v2 06/11] arm64: rename variables used to calculate ZONE_DMA32's size

2019-08-20 Thread Nicolas Saenz Julienne
Let the name indicate that they are used to calculate ZONE_DMA32's size as opposed to ZONE_DMA. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: None arch/arm64/mm/init.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/arm64/mm

[PATCH v2 00/11] Raspberry Pi 4 DMA addressing support

2019-08-20 Thread Nicolas Saenz Julienne
to zone_dma_bits. - Try new approach by merging both ZONE_DMA and ZONE_DMA32 comments in mmzone.h, add new up to date examples. Nicolas Saenz Julienne (11): asm-generic: add dma_zone_size arm: use generic dma_zone_size of/fdt: add of_fdt_machine_is_compatible function of/fdt: add

[PATCH v2 02/11] arm: use generic dma_zone_size

2019-08-20 Thread Nicolas Saenz Julienne
'dma_zone_size' was created as a generic replacement to 'arm_dma_zone_size'. Use it accordingly. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: None arch/arm/include/asm/dma.h | 8 +--- arch/arm/mm/init.c | 12 2 files changed, 9 insertions(+), 11 deletions

[PATCH v2 07/11] arm64: re-introduce max_zone_dma_phys()

2019-08-20 Thread Nicolas Saenz Julienne
-off-by: Nicolas Saenz Julienne --- Changes in v2: - Update function's behavior to fit new dma zones split - Use dma_zone_size - Take into account devices with a hardcoded DMA offset arch/arm64/mm/init.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/mm/init.c b/arch

[PATCH v2 04/11] of/fdt: add early_init_dt_get_dma_zone_size()

2019-08-20 Thread Nicolas Saenz Julienne
simply hardcode the device wide DMA addressable memory size conditionally to the machine compatible name and set 'dma_zone_size' accordingly. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - New approach to getting dma_zone_size, instead of parsing the dts we hardcode it conditionally

[PATCH v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-08-20 Thread Nicolas Saenz Julienne
Some architectures, notably arm64, are interested in tweaking this depending on their runtime dma addressing limitations. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - Rename new variable to zone_dma_bits - Update comment with Christoph's suggestion - Remove old powerpc comment

[PATCH v2 08/11] arm64: use both ZONE_DMA and ZONE_DMA32

2019-08-20 Thread Nicolas Saenz Julienne
to address the whole 32 bit addressable space ZONE_DMA32 will be left empty. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - ZONE_DMA will never be left empty - Update comment to reflect new zones split arch/arm64/Kconfig | 4 arch/arm64/mm/init.c | 39

[PATCH v2 11/11] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'

2019-08-20 Thread Nicolas Saenz Julienne
These zones usage has evolved with time and the comments were outdated. This joins both ZONE_DMA and ZONE_DMA32 explanation and gives up to date examples on how they are used on different architectures. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - Try another approach merging

[PATCH v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask

2019-08-20 Thread Nicolas Saenz Julienne
With the introduction of ZONE_DMA in arm64 devices are not forced to support 32 bit DMA masks. We have to inform dma-direct of this limitation whenever it happens. Signed-off-by: Nicolas Saenz Julienne --- Changes in v2: - Make sure to filter the higher part of arm64_dma_phys_limit - Rename

Re: [PATCH v2 01/11] asm-generic: add dma_zone_size

2019-08-30 Thread Nicolas Saenz Julienne
On Fri, 2019-08-30 at 15:45 +0100, Catalin Marinas wrote: > On Mon, Aug 26, 2019 at 03:46:52PM +0200, Nicolas Saenz Julienne wrote: > > On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote: > > > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne w

PCIe DMA addressing issues on Raspberry Pi 4

2019-09-03 Thread Nicolas Saenz Julienne
Hi all, sorry for the long read, I kept it as short as possible. So, the wrapper around the PCIe block available on the Raspberry Pi 4 has a bug preventing it from accessing anything beyond the first 3G of ram [1]. I'm trying to figure out the best way to integrate this upstream. Note that the

Re: [PATCH v2 01/11] asm-generic: add dma_zone_size

2019-08-28 Thread Nicolas Saenz Julienne
On Mon, 2019-08-26 at 15:46 +0200, Nicolas Saenz Julienne wrote: > On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote: > > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote: > > > Some architectures have platform specific DMA addr

Re: [PATCH v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask

2019-08-26 Thread Nicolas Saenz Julienne
On Mon, 2019-08-26 at 09:06 +0200, Christoph Hellwig wrote: > On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote: > > - if (IS_ENABLED(CONFIG_ZONE_DMA)) > > + if (IS_ENABLED(CONFIG_ZONE_DMA)) { > > arm64_dma_phys_limi

Re: [PATCH v2 01/11] asm-generic: add dma_zone_size

2019-08-26 Thread Nicolas Saenz Julienne
On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote: > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote: > > Some architectures have platform specific DMA addressing limitations. > > This will allow for hardware description code to provide

Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size

2019-08-05 Thread Nicolas Saenz Julienne
Hi Rob, Thanks for the review! On Fri, 2019-08-02 at 11:17 -0600, Rob Herring wrote: > On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne > wrote: > > Some SoCs might have multiple interconnects each with their own DMA > > addressing limitations. This function parses the 'd

Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size

2019-08-06 Thread Nicolas Saenz Julienne
Hi Rob, On Mon, 2019-08-05 at 13:23 -0600, Rob Herring wrote: > On Mon, Aug 5, 2019 at 10:03 AM Nicolas Saenz Julienne > wrote: > > Hi Rob, > > Thanks for the review! > > > > On Fri, 2019-08-02 at 11:17 -0600, Rob Herring wrote: > > > On Wed, Jul 31,

Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size

2019-08-08 Thread Nicolas Saenz Julienne
On Thu, 2019-08-08 at 09:02 -0600, Rob Herring wrote: > On Tue, Aug 6, 2019 at 12:12 PM Nicolas Saenz Julienne > wrote: > > Hi Rob, > > > > On Mon, 2019-08-05 at 13:23 -0600, Rob Herring wrote: > > > On Mon, Aug 5, 2019 at 10:03 AM Nicolas Saenz Juli

Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices

2019-08-01 Thread Nicolas Saenz Julienne
On Thu, 2019-08-01 at 17:07 +0100, Robin Murphy wrote: > On 2019-08-01 4:44 pm, Nicolas Saenz Julienne wrote: > > On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote: > > > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > > > > diff --git

Re: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices

2019-08-01 Thread Nicolas Saenz Julienne
On Wed, 2019-07-31 at 18:07 +0100, Catalin Marinas wrote: > On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote: > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index 1c4ffabbe1cb..f5279ef85756 100644 > > --- a/arch/arm64/mm/init.c > >

[RFC 0/4] Raspberry Pi 4 DMA addressing support

2019-07-17 Thread Nicolas Saenz Julienne
on the existing devices limitations. On the other I've added a new variable in dma-direct that allows modifying the min_mask during the init process and taken care of setting it accordingly in the arm64's init code. Regards, Nicolas --- Nicolas Saenz Julienne (4): arm64: mm: use arm64_dma_phys_limit instead

[RFC 3/4] dma-direct: add dma_direct_min_mask

2019-07-17 Thread Nicolas Saenz Julienne
' isn't properly set. We create 'dma_direct_min_mask' in order for the arch init code to be able to fine-tune dma direct's 'min_dma' mask. Signed-off-by: Nicolas Saenz Julienne --- kernel/dma/direct.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/dma/direct.c b

Re: [RFC 3/4] dma-direct: add dma_direct_min_mask

2019-07-18 Thread Nicolas Saenz Julienne
On Thu, 2019-07-18 at 11:15 +0200, Christoph Hellwig wrote: > On Wed, Jul 17, 2019 at 05:31:34PM +0200, Nicolas Saenz Julienne wrote: > > Historically devices with ZONE_DMA32 have been assumed to be able to > > address at least the lower 4GB of ram for DMA. This is still the defua

Re: [RFC 3/4] dma-direct: add dma_direct_min_mask

2019-07-19 Thread Nicolas Saenz Julienne
On Thu, 2019-07-18 at 13:18 +0200, Nicolas Saenz Julienne wrote: > On Thu, 2019-07-18 at 11:15 +0200, Christoph Hellwig wrote: > > On Wed, Jul 17, 2019 at 05:31:34PM +0200, Nicolas Saenz Julienne wrote: > > > Historically devices with ZONE_DMA32 have been assumed to be abl

Re: [RFC 3/4] dma-direct: add dma_direct_min_mask

2019-07-24 Thread Nicolas Saenz Julienne
On Wed, 2019-07-24 at 15:56 +0200, Christoph Hellwig wrote: > On Wed, Jul 24, 2019 at 02:51:24PM +0100, Catalin Marinas wrote: > > I think it may be better if we have both ZONE_DMA and ZONE_DMA32 on > > arm64. ZONE_DMA would be based on the smallest dma-ranges as described > > in the DT while

Re: [PATCH 2/2] arm: use swiotlb for bounce buffer on LPAE configs

2019-07-24 Thread Nicolas Saenz Julienne
On Tue, 2019-07-09 at 07:20 -0700, Christoph Hellwig wrote: > The DMA API requires that 32-bit DMA masks are always supported, but on > arm LPAE configs they do not currently work when memory is present > above 4GB. Wire up the swiotlb code like for all other architectures > to provide the bounce

[PATCH v3 0/2] x86: Get rid of custom DMA functions

2019-11-07 Thread Nicolas Saenz Julienne
to get proper DMA support on the Raspberry Pi 4[1]. [1] https://lkml.org/lkml/2019/10/15/523 --- Changes since v2: - cleanup dma-direct.h Changes since v1: - Small cleanups in sta2x11-fixup.x - add patch checking DMA addresses lower bounds Nicolas Saenz Julienne (2): dma-direct: check

[PATCH v3 1/2] dma-direct: check for overflows on 32 bit DMA addresses

2019-11-07 Thread Nicolas Saenz Julienne
which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne

[PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-31 Thread Nicolas Saenz Julienne
Some architectures, notably ARM, are interested in tweaking this depending on their runtime DMA addressing limitations. Signed-off-by: Nicolas Saenz Julienne --- Changes since RFC: - Rebased to v5.4-rc6, fixed arm64 code. NOTE: This will only apply to linux-next, where arch/arm64/mm/init.c

Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-31 Thread Nicolas Saenz Julienne
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote: > > > > +#define ARM64_ZONE_DMA_BITS30 > > > > + > > > > /* > > > > * We need to be ab

Re: [PATCH] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-31 Thread Nicolas Saenz Julienne
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote: > > Some architectures, notably ARM, are interested in tweaking this > > depending on their runtime DMA addressing limitations. > > >

Re: [PATCH RFC 1/5] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-31 Thread Nicolas Saenz Julienne
On Thu, 2019-10-31 at 06:38 -0700, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 11:30:36AM +0100, Nicolas Saenz Julienne wrote: > > On Wed, 2019-10-30 at 14:49 -0700, Christoph Hellwig wrote: > > > On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne w

Re: unify the dma_capable definition

2019-11-13 Thread Nicolas Saenz Julienne
On Wed, 2019-11-13 at 08:35 +0100, Christoph Hellwig wrote: > Hi all, > > there is no good reason to have different version of dma_capable. > This series removes the arch overrides and also adds a few cleanups > in the same area. Reviewed-by: Nicolas Saenz Julienne for the whole

[PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-13 Thread Nicolas Saenz Julienne
DMA limits to the next power of two, which is unacceptable in this case. In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all over the tree and treat it as such. Note that dev->bus_dma_limit is meant to contain the higher accesible DMA address. Signed-off-by: Nicolas Sa

[PATCH v2 0/6] Raspberry Pi 4 PCIe support

2019-11-12 Thread Nicolas Saenz Julienne
MSI implementation - Fix multiple cosmetic issues - Remove supend/resume code Jim Quinlan (3): dt-bindings: PCI: Add bindings for brcmstb's PCIe device PCI: brcmstb: add Broadcom STB PCIe host controller driver PCI: brcmstb: add MSI capability Nicolas Saenz Julienne (3): linux/log2.h

[PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions

2019-11-12 Thread Nicolas Saenz Julienne
-off-by: Nicolas Saenz Julienne --- drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +- drivers/pci/controller/pcie-cadence-ep.c | 7 +-- drivers/pci/controller/pcie-cadence.c | 7 +-- drivers/pci/controller/pcie-rockchip-ep.c | 9 ++-- include/linux/log2.h

Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Nicolas Saenz Julienne
On Thu, 2019-11-21 at 08:31 +0100, Christoph Hellwig wrote: > On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote: > > TBH I can't see it being a massive problem even if the DMA patch, driver > > and DTS patch went entirely separately via the respective DMA, PCI, and > > arm-soc trees

[PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Nicolas Saenz Julienne
DMA limits to the next power of two, which is unacceptable in this case. In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all over the tree and treat it as such. Note that dev->bus_dma_limit should contain the higher accesible DMA address. Signed-off-by: Nicolas Sa

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Nicolas Saenz Julienne
On Thu, 2019-11-21 at 16:24 +0100, Christoph Hellwig wrote: > On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: > > Using a mask to represent bus DMA constraints has a set of limitations. > > The biggest one being it can only hold a power of two (minus on

[PATCH v4 8/8] linux/log2.h: Use roundup/dow_pow_two() on 64bit calculations

2019-12-03 Thread Nicolas Saenz Julienne
The function now is safe to use while expecting a 64bit value. Use it where relevant. Signed-off-by: Nicolas Saenz Julienne --- drivers/acpi/arm64/iort.c| 2 +- drivers/net/ethernet/mellanox/mlx4/en_clock.c| 3 ++- drivers/of/device.c | 3

[PATCH v4 0/8] Raspberry Pi 4 PCIe support

2019-12-03 Thread Nicolas Saenz Julienne
controller driver PCI: brcmstb: Add MSI support Nicolas Saenz Julienne (5): ARM: dts: bcm2711: Enable PCIe controller MAINTAINERS: Add brcmstb PCIe controller arm64: defconfig: Enable Broadcom's STB PCIe controller linux/log2.h: Fix 64bit calculations in roundup/down_pow_two() linux/log2.h

[PATCH v4 7/8] linux/log2.h: Fix 64bit calculations in roundup/down_pow_two()

2019-12-03 Thread Nicolas Saenz Julienne
to the round functions we can rework them as a wrapper around it. Suggested-by: Robin Murphy Signed-off-by: Nicolas Saenz Julienne --- drivers/clk/clk-divider.c| 8 ++-- drivers/clk/sunxi/clk-sunxi.c| 2 +- drivers/infiniband/hw/hfi1/chip.c| 4

Re: [PATCH v4 8/8] linux/log2.h: Use roundup/dow_pow_two() on 64bit calculations

2019-12-03 Thread Nicolas Saenz Julienne
Hi Rob, On Tue, 2019-12-03 at 09:53 -0600, Rob Herring wrote: > On Tue, Dec 3, 2019 at 5:48 AM Nicolas Saenz Julienne > wrote: > > The function now is safe to use while expecting a 64bit value. Use it > > where relevant. > > What was wrong with the existing code? This

Re: [PATCH v4 8/8] linux/log2.h: Use roundup/dow_pow_two() on 64bit calculations

2019-12-12 Thread Nicolas Saenz Julienne
On Thu, 2019-12-05 at 14:38 -0600, Bjorn Helgaas wrote: > The subject contains a couple typos: it's missing "of" and it's > missing the "n" on "down". Noted > > On Tue, Dec 03, 2019 at 12:47:41PM +0100, Nicolas Saenz Julienne wrote: > > The fun

Re: [PATCH v4 7/8] linux/log2.h: Fix 64bit calculations in roundup/down_pow_two()

2019-12-12 Thread Nicolas Saenz Julienne
On Thu, 2019-12-05 at 16:30 -0600, Bjorn Helgaas wrote: > You got the "n" on "down" in the subject, but still missing "of" ;) Yes, sorry about that, I tend to re-read what I meant to say instead of what it's actually written. > On Tue, Dec 03, 2019 at 12:4

Re: [PATCH v4 7/8] linux/log2.h: Fix 64bit calculations in roundup/down_pow_two()

2019-12-12 Thread Nicolas Saenz Julienne
Hi Robin, On Thu, 2019-12-05 at 17:48 +, Robin Murphy wrote: > On 03/12/2019 11:47 am, Nicolas Saenz Julienne wrote: > > Some users need to make sure their rounding function accepts and returns > > 64bit long variables regardless of the architecture. Sadly > > roun

Re: [PATCH v2] iommu/dma: Rationalise types for DMA masks

2019-12-11 Thread Nicolas Saenz Julienne
discrepancy against the domain geometry with a cheeky > cast to keep things simple. > > Signed-off-by: Robin Murphy Thanks! Reviewed-by: Nicolas Saenz Julienne signature.asc Description: This is a digitally signed message part ___ iom

[PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses

2019-10-18 Thread Nicolas Saenz Julienne
which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne

[PATCH v2 0/2] x86: Get rid of custom DMA functions

2019-10-18 Thread Nicolas Saenz Julienne
to get proper DMA support on the Raspberry Pi 4[1]. [1] https://lkml.org/lkml/2019/10/15/523 --- Changes since v1: - Small cleanups in sta2x11-fixup.x - add patch checking DMA addresses lower bounds Nicolas Saenz Julienne (2): dma-direct: check for overflows on 32 bit DMA addresses x86/PCI

Re: [PATCH RFC 0/5] ARM: Raspberry Pi 4 DMA support

2019-10-15 Thread Nicolas Saenz Julienne
On Mon, 2019-10-14 at 21:59 +0100, Catalin Marinas wrote: > On Mon, Oct 14, 2019 at 08:31:02PM +0200, Nicolas Saenz Julienne wrote: > > the Raspberry Pi 4 offers up to 4GB of memory, of which only the first > > is DMA capable device wide. This forces us to use of bounce buf

Re: [PATCH RFC 4/5] dma/direct: check for overflows in ARM's dma_capable()

2019-10-15 Thread Nicolas Saenz Julienne
On Tue, 2019-10-15 at 03:23 -0700, Christoph Hellwig wrote: > On Mon, Oct 14, 2019 at 08:31:06PM +0200, Nicolas Saenz Julienne wrote: > > The Raspberry Pi 4 has a 1GB ZONE_DMA area starting at address > > 0x and a mapping between physical and DMA memory offset by

[PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions

2019-11-26 Thread Nicolas Saenz Julienne
-off-by: Nicolas Saenz Julienne --- Changes since v2: - Use u64 - Rename function to roundup/down_pow_two_u64() - Use 1ULL instead of 1UL - Include function usage in of/device.c and acpi/arm64/iort.c drivers/acpi/arm64/iort.c | 2 +- drivers/net/ethernet/mellanox/mlx4

[PATCH v3 0/7] Raspberry Pi 4 PCIe support

2019-11-26 Thread Nicolas Saenz Julienne
setup for MSI - Cleanup MSI implementation - Fix multiple cosmetic issues - Remove supend/resume code Jim Quinlan (3): dt-bindings: PCI: Add bindings for brcmstb's PCIe device PCI: brcmstb: add Broadcom STB PCIe host controller driver PCI: brcmstb: add MSI capability Nicolas Saenz Julienne

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-26 Thread Nicolas Saenz Julienne
On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote: > On 25/11/2019 7:44 am, Christoph Hellwig wrote: > > On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: > > > Just as an FYI, this introduces a warning on arm32 allyesconfig for me: > > > > I think the dma_limit argument to

Re: [PATCH v3 0/7] Raspberry Pi 4 PCIe support

2019-11-27 Thread Nicolas Saenz Julienne
Hi Bjorn, On Tue, 2019-11-26 at 15:50 -0600, Bjorn Helgaas wrote: > On Tue, Nov 26, 2019 at 10:19:38AM +0100, Nicolas Saenz Julienne wrote: > > This series aims at providing support for Raspberry Pi 4's PCIe > > controller, which is also shared with the Broadcom STB family of >

Re: [PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions

2019-11-27 Thread Nicolas Saenz Julienne
On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote: > On 26/11/2019 12:51 pm, Leon Romanovsky wrote: > > On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne wrote: > > > Some users need to make sure their rounding function accepts and returns > > > 64bi

Re: [PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions

2019-11-27 Thread Nicolas Saenz Julienne
On Wed, 2019-11-27 at 19:06 +, Robin Murphy wrote: > On 27/11/2019 6:24 pm, Nicolas Saenz Julienne wrote: > > On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote: > > > On 26/11/2019 12:51 pm, Leon Romanovsky wrote: > > > > On Tue, Nov 26, 2019 at 10:19:39AM

Re: [PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions

2019-11-27 Thread Nicolas Saenz Julienne
On Tue, 2019-11-26 at 10:19 +0100, Nicolas Saenz Julienne wrote: > Some users need to make sure their rounding function accepts and returns > 64bit long variables regardless of the architecture. Sadly > roundup/rounddown_pow_two() takes and returns unsigned longs. Create a > new g

Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses

2019-10-31 Thread Nicolas Saenz Julienne
On Wed, 2019-10-30 at 14:41 -0700, Christoph Hellwig wrote: > On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote: > > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT > > + /* Check if DMA address overflowed */ > > + if (min(addr, addr + size - 1) < > >

Re: [PATCH RFC 1/5] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-31 Thread Nicolas Saenz Julienne
On Wed, 2019-10-30 at 14:49 -0700, Christoph Hellwig wrote: > On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote: > > Some architectures, notably ARM, are interested in tweaking this > > depending on their runtime DMA addressing limitations. > > >

Re: [PATCH] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-14 Thread Nicolas Saenz Julienne
On Wed, 2019-11-13 at 20:34 +, Robin Murphy wrote: > On 13/11/2019 4:13 pm, Nicolas Saenz Julienne wrote: > > Using a mask to represent bus DMA constraints has a set of limitations. > > The biggest one being it can only hold a power of two (minus one). The > > DMA mapping

[PATCH RFC 0/5] ARM: Raspberry Pi 4 DMA support

2019-10-14 Thread Nicolas Saenz Julienne
for high memory. Instead of fixing it, this series introduces a way of selecting dma-direct as the default DMA ops provider which allows for the Raspberry Pi to make use of swiotlb. Regards, Nicolas --- Nicolas Saenz Julienne (5): dma/direct: turn ARCH_ZONE_DMA_BITS into a variable ARM: introduce

[PATCH RFC 1/5] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-14 Thread Nicolas Saenz Julienne
Some architectures, notably ARM, are interested in tweaking this depending on their runtime DMA addressing limitations. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/include/asm/page.h | 2 -- arch/arm64/mm/init.c| 9 +++-- arch/powerpc/include/asm/page.h | 9

[PATCH RFC 5/5] ARM: bcm2711: use dma-direct

2019-10-14 Thread Nicolas Saenz Julienne
The Raspberry Pi 4 supports up to 4GB of memory yet most of its devices are only able to address the fist GB. Enable dma-direct for that board in order to benefit from swiotlb's bounce buffering mechanism. Signed-off-by: Nicolas Saenz Julienne --- arch/arm/mach-bcm/Kconfig | 1 + arch/arm

[PATCH RFC 2/5] ARM: introduce arm_dma_direct

2019-10-14 Thread Nicolas Saenz Julienne
with arm_dma_direct, a global variable which will be set accordingly during init. Signed-off-by: Nicolas Saenz Julienne --- arch/arm/include/asm/dma-mapping.h | 3 ++- arch/arm/include/asm/dma.h | 2 ++ arch/arm/mm/dma-mapping.c | 10 ++ arch/arm/mm/init.c | 13

[PATCH RFC 3/5] ARM: let machines select dma-direct over arch's DMA implementation

2019-10-14 Thread Nicolas Saenz Julienne
A bounce buffering feature is already available in ARM, dmabounce.c, yet it doesn't support high memory which some devices need. Instead of fixing it, provide a means for devices to enable dma-direct, which is the preferred way of doing DMA now days. Signed-off-by: Nicolas Saenz Julienne

[PATCH RFC 4/5] dma/direct: check for overflows in ARM's dma_capable()

2019-10-14 Thread Nicolas Saenz Julienne
addresses will not be detected by arm's dma_capable() as they still fit in the device's DMA mask. Fix this by failing to validate a DMA address smaller than the lowest possible DMA address. Signed-off-by: Nicolas Saenz Julienne --- arch/arm/include/asm/dma-direct.h | 6 ++ 1 file changed, 6

Re: [PATCH] dma-contiguous: CMA: give precedence to cmdline

2020-01-30 Thread Nicolas Saenz Julienne
On Thu Jan 30, 2020 at 2:42 PM, Christoph Hellwig wrote: > I've picked this up for Linux 5.6, sorry for the delay. Thanks! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] dma-contiguous: CMA: give precedence to cmdline

2020-01-10 Thread Nicolas Saenz Julienne
freeing the memblock and allow the command line CMA configuration routine to run. Signed-off-by: Nicolas Saenz Julienne --- NOTE: Tested this on arm and arm64 with the Raspberry Pi 4. kernel/dma/contiguous.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/kernel/dma

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-07 Thread Nicolas Saenz Julienne
On Mon, 2020-09-07 at 13:40 -0400, Jim Quinlan wrote: > On Mon, Sep 7, 2020 at 11:01 AM Nicolas Saenz Julienne > wrote: > > > > > > Hi Nicolas, > > > > > > Can you please help us out here? It appears that your commit > > > > It's dma_offse

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-08 Thread Nicolas Saenz Julienne
On Tue, 2020-09-08 at 11:43 +0200, Christoph Hellwig wrote: > And because I like replying to myself so much, here is a link to the > version with the arm cleanup patch applied. Unlike the previous two > attempts this has at least survived very basic sanity testing: > >

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-07 Thread Nicolas Saenz Julienne
Hi Jim, sorry I'm a little late to the party, but was on vacation. On Thu, 2020-09-03 at 13:32 -0400, Jim Quinlan wrote: > On Wed, Sep 2, 2020 at 8:52 PM Nathan Chancellor > wrote: > > On Wed, Sep 02, 2020 at 05:36:29PM -0700, Florian Fainelli wrote: > > > > > > On 9/2/2020 3:38 PM, Nathan

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset

2020-09-07 Thread Nicolas Saenz Julienne
Hi Christoph, a small fix to your fixes: On Tue, 2020-09-01 at 10:24 +0200, Christoph Hellwig wrote: > I've applied this to the dma-mapping tree. > > I had to resolve a conflict in drivers/of/address.c with a recent > mainline commit. I also applied the minor tweaks Andy pointed out > plus a

Re: [PATCH v3 1/8] arm64: mm: Move reserve_crashkernel() into mem_init()

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 09:40 +0100, Will Deacon wrote: > On Wed, Oct 14, 2020 at 09:12:03PM +0200, Nicolas Saenz Julienne wrote: > > crashkernel might reserve memory located in ZONE_DMA. We plan to delay > > ZONE_DMA's initialization after unflattening the devicetree and ACPI's

Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:42 +0200, Christoph Hellwig wrote: > > +phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np) > > +{ > > + phys_addr_t max_cpu_addr = PHYS_ADDR_MAX; > > + struct of_range_parser parser; > > + phys_addr_t subtree_max_addr; > > + struct device_node

Re: [PATCH v3 5/8] dma-direct: Turn zone_dma_bits default value into a define

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:38 +0200, Christoph Hellwig wrote: > On Wed, Oct 14, 2020 at 09:12:07PM +0200, Nicolas Saenz Julienne wrote: > > Set zone_dma_bits default value through a define so as for architectures > > to be able to override it with their default value. > >

Re: [PATCH v3 4/8] of: unittest: Add test for of_dma_get_max_cpu_address()

2020-10-15 Thread Nicolas Saenz Julienne
On Wed, 2020-10-14 at 17:04 -0500, Rob Herring wrote: > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > wrote: > > Introduce a test for of_dma_get_max_cup_address(), it uses the same DT > > data as the rest of dma-ranges unit tests. > > > > Signed-

Re: [PATCH v3 6/8] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 07:39 +0200, Christoph Hellwig wrote: > On Wed, Oct 14, 2020 at 09:12:08PM +0200, Nicolas Saenz Julienne wrote: > > + zone_dma_bits = min(zone_dma_bits, > > + (unsigned > > int)ilog2(of_dma_get_max_cpu_address(NULL))); > &

Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 08:56 +0200, Ard Biesheuvel wrote: > On Thu, 15 Oct 2020 at 00:03, Rob Herring wrote: > > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > > wrote: > > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > > > ph

Re: [PATCH v3 3/8] of/address: Introduce of_dma_get_max_cpu_address()

2020-10-15 Thread Nicolas Saenz Julienne
On Wed, 2020-10-14 at 17:02 -0500, Rob Herring wrote: > On Wed, Oct 14, 2020 at 2:12 PM Nicolas Saenz Julienne > wrote: > > Introduce of_dma_get_max_cpu_address(), which provides the highest CPU > > physical address addressable by all DMA masters in the system. It's &g

Re: [PATCH v3 7/8] arm64: mm: Set ZONE_DMA size based on early IORT scan

2020-10-15 Thread Nicolas Saenz Julienne
On Thu, 2020-10-15 at 22:26 +0800, Hanjun Guo wrote: > On 2020/10/15 3:12, Nicolas Saenz Julienne wrote: > > From: Ard Biesheuvel > > > > We recently introduced a 1 GB sized ZONE_DMA to cater for platforms > > incorporating masters that can address less than 32 bit

[PATCH v2 5/5] mm: Update DMA zones description

2020-10-10 Thread Nicolas Saenz Julienne
The default behavior for arm64 changed, so reflect that. Signed-off-by: Nicolas Saenz Julienne Acked-by: Catalin Marinas --- include/linux/mmzone.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index fb3bf696c05e

[PATCH v2 2/5] of/address: Introduce of_dma_lower_bus_limit()

2020-10-10 Thread Nicolas Saenz Julienne
The function provides the CPU physical address addressable by the most constrained bus in the system. It might be useful in order to dynamically set up memory zones during boot. Signed-off-by: Nicolas Saenz Julienne --- drivers/of/address.c | 34 ++ include/linux

[PATCH v2 0/5] arm64: Default to 32-bit wide ZONE_DMA

2020-10-10 Thread Nicolas Saenz Julienne
dma-ranges instead of using machine compatible string Nicolas Saenz Julienne (5): arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() of/address: Introduce of_dma_lower_bus_limit() dma-direct: Turn zone_dma_bits default value into a define arm64: mm: Dynamically resize zon

[PATCH v2 3/5] dma-direct: Turn zone_dma_bits default value into a define

2020-10-10 Thread Nicolas Saenz Julienne
So as for architecture code to set their own default values when relevant. Signed-off-by: Nicolas Saenz Julienne --- Note: This is not really needed, but I think it nicer having architectures use this than setting zone_dma_bits in a random place in arch code. That said, I'll hapily edit it out

[PATCH v2 4/5] arm64: mm: Dynamically resize zone_dma_bits based on system's constraints

2020-10-10 Thread Nicolas Saenz Julienne
With the help of of_dma_safe_phys_limit() we can get the topmost physical address accessible for DMA to the whole system and use that information to properly setup zone_dma_bits. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/include/asm/processor.h | 1 + arch/arm64/mm/init.c

[PATCH v2 1/5] arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()

2020-10-10 Thread Nicolas Saenz Julienne
There no use for initializing it earlier in arm64_memblock_init(). Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/mm/init.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index f6902a2b4ea6..0eca5865dcb1 100644

Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711

2020-10-10 Thread Nicolas Saenz Julienne
On Sat, 2020-10-10 at 12:36 +0200, Ard Biesheuvel wrote: > On Fri, 9 Oct 2020 at 19:10, Catalin Marinas wrote: > > On Fri, Oct 09, 2020 at 06:23:06PM +0200, Ard Biesheuvel wrote: > > > On Fri, 9 Oct 2020 at 17:24, Lorenzo Pieralisi > > > wrote: > > > > We can move this check to IORT code and

  1   2   3   >