[2] https://lkml.org/lkml/2020/7/8/1108
---
Changes since v1:
- Rebase into linus' master
Nicolas Saenz Julienne (4):
dma-direct: Provide function to check physical memory area validity
dma-pool: Get rid of dma_in_atomic_pool()
dma-pool: Introduce dma_guess_pool()
dma-pool: Ma
dma_coherent_ok() checks if a physical memory area fits a device's DMA
constraints.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h b/in
er) memory
zone.
To help mitigate this, introduce dma_guess_pool() which can be fed a
device's DMA constraints and atomic pools already known to be faulty, in
order for it to provide an better guess on which pool to use.
Signed-off-by: Nicolas Saenz Julienne
---
kernel/dma/pool.c | 26
Linton
Suggested-by: Robin Murphy
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v1:
- Rebase to linus' master
kernel/dma/pool.c | 57 ++-
1 file changed, 37 insertions(+), 20 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/
The function is only used once and can be simplified to a one-liner.
Signed-off-by: Nicolas Saenz Julienne
---
kernel/dma/pool.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 39ca26fa41b5..318035e093fb 100644
--- a
Hi Chritoph,
On Fri, 2020-07-10 at 16:10 +0200, Nicolas Saenz Julienne wrote:
> There is no guarantee to CMA's placement, so allocating a zone specific
> atomic pool from CMA might return memory from a completely different
> memory zone. To get around this double check CMA'
Hi Amit,
On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote:
> On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne
> wrote:
> > There is no guarantee to CMA's placement, so allocating a zone
> > specific
> > atomic pool from CMA might return memory from a comple
On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> wrote:
> > Hi Amit,
> > > Hi Nicolas,
> > >
> > > I see a boot regression with this commit d9765e41d8e9 "dma-pool:
> > > Do no
On Tue, 2020-07-21 at 13:28 +0200, Christoph Hellwig wrote:
> On Tue, Jul 21, 2020 at 01:15:23PM +0200, Nicolas Saenz Julienne
> wrote:
> > I'm at loss at what could be failing here. Your device should be
> > able
> > to address the whole 8GB memory space, which A
On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote:
> On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
> wrote:
> > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> > > wrote:
> &g
On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote:
[...]
> > > > Can you try booting *without* my patch and this in the kernel
> > > > command
> > > > line: "cma=16M@0x1-0x2".
> > >
> > > It doesn't boot with this added kernel command line.
> >
> > For the record, this placed
Hi Amit,
On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote:
> Hi Nicolas,
>
> Sorry I got stuck on other things yesterday.
No worries :)
> On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne
[...]
> >
> > Let's get a bigger hammer, I'm just looking for
Hi Christoph,
thanks for having a look at this!
On Fri, 2020-07-24 at 15:41 +0200, Christoph Hellwig wrote:
> Yes, the iommu is an interesting case, and the current code is
> wrong for that.
Care to expand on this? I do get that checking dma_coherent_ok() on memory
that'll later on be mapped into
On Tue, 2020-07-28 at 11:13 +0200, Christoph Hellwig wrote:
> On Mon, Jul 27, 2020 at 07:56:56PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Christoph,
> > thanks for having a look at this!
> >
> > On Fri, 2020-07-24 at 15:41 +0200, Christoph Hellwig wrote:
> > &
On Tue, 2020-07-28 at 12:47 +0200, Christoph Hellwig wrote:
> When allocating coherent pool memory for an IOMMU mapping we don't care
> about the DMA mask. Move the guess for the initial GFP mask into the
> dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
> argument so that it
On Tue, 2020-07-28 at 17:30 +0200, Christoph Hellwig wrote:
> On Tue, Jul 28, 2020 at 06:18:41PM +0530, Amit Pundir wrote:
> > > Oh well, this leaves me confused again. It looks like your setup
> > > really needs a CMA in zone normal for the dma or dma32 pool.
> >
> > Anything I should look up in
On Thu, 2020-07-30 at 12:44 -0400, Jim Quinlan wrote:
> On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote:
> > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote:
> > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote:
> > > > I started using devm_kcalloc() but at least two revi
Hi Jim,
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> static void __init of_unittest_pci_dma_ranges(void)
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index bfc2542d54a8..8dacb9d3b7b6 100644
> --- a/drivers/pci/controller/pcie-brcmstb
On Thu, 2020-07-30 at 13:25 -0400, Jim Quinlan wrote:
> On Thu, Jul 30, 2020 at 1:05 PM Nicolas Saenz Julienne
> wrote:
> > Hi Jim,
> >
> > On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> > > static void __init of_unittest_pci_dma_ranges(void)
> >
Hi Nathan,
On Thu, 2020-07-30 at 18:10 -0700, Nathan Chancellor wrote:
> On Tue, Jul 28, 2020 at 12:09:18PM +0200, Christoph Hellwig wrote:
> > Ok, I found a slight bug that wasn't intended. I wanted to make sure
> > we can always fall back to a lower pool, but got that wrong. Should be
> > fixe
Hi Amit,
On Wed, 2020-07-29 at 17:52 +0530, Amit Pundir wrote:
> On Wed, 29 Jul 2020 at 16:15, Nicolas Saenz Julienne
> wrote:
> > On Tue, 2020-07-28 at 17:30 +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 28, 2020 at 06:18:41PM +0530, Amit Pundir wrote:
> > &g
On Fri, 2020-07-31 at 16:47 +0530, Amit Pundir wrote:
> On Fri, 31 Jul 2020 at 16:17, Nicolas Saenz Julienne
[...]
> > Ok, so lets see who's doing what and with what constraints:
>
> Here is the relevant dmesg log: https://pastebin.ubuntu.com/p/dh3pPnxS2v/
Sadly nothing
On Sat, 2020-08-01 at 17:27 +0530, Amit Pundir wrote:
[...]
> > I'm between a rock and a hard place here. If we simply want to revert
> > commits as-is to make sure both the Raspberry Pi 4 and thone phone do
> > not regress we'll have to go all the way back and revert the whole SEV
> > pool supp
Hi Jim, here's some comments after testing your series against RPi4.
On Fri, 2020-07-24 at 16:33 -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsum
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
S
or calling it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-direct.h | 3 -
include/linux/dma-mapping.h | 5
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
---
Change
On Tue, 2020-08-04 at 08:06 +0200, Christoph Hellwig wrote:
> On Mon, Aug 03, 2020 at 06:09:56PM +0200, Nicolas Saenz Julienne wrote:
> > + if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
> > + return end <= DMA_BIT_MASK(zone_dma_bits);
> >
On Thu, 2020-08-06 at 07:18 +0200, Christoph Hellwig wrote:
> On Tue, Aug 04, 2020 at 11:43:15AM +0200, Nicolas Saenz Julienne wrote:
> > > Second I don't see the need (and actually some harm) in preventing
> > > GFP_KERNEL
> > > allocations from dipping into
rior calling it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-direct.h | 3 -
include/linux/dma-mapping.h | 5 +-
kern
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
S
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebase
On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote:
> On Thu, Aug 06, 2020 at 08:47:55PM +0200, Nicolas Saenz Julienne wrote:
> > There is no guarantee to CMA's placement, so allocating a zone specific
> > atomic pool from CMA might return memory from a completely diffe
On Fri, 2020-08-14 at 08:06 +0200, Christoph Hellwig wrote:
> On Sat, Aug 08, 2020 at 08:33:54AM +0200, Christoph Hellwig wrote:
> > On Fri, Aug 07, 2020 at 10:50:19AM +0200, Nicolas Saenz Julienne wrote:
> > > On Fri, 2020-08-07 at 07:21 +0200, Christoph Hellwig wrote:
>
to true
now
- Check if phys_addr_ok() exists prior calling it
Christoph Hellwig (1):
dma-pool: fix coherent pool allocations for IOMMU mappings
Nicolas Saenz Julienne (1):
dma-pool: Only allocate from CMA when in same memory zone
drivers/iommu/dma-iommu.c | 4 +-
include/linux/dma-
From: Christoph Hellwig
When allocating coherent pool memory for an IOMMU mapping we don't care
about the DMA mask. Move the guess for the initial GFP mask into the
dma_direct_alloc_pages and pass dma_coherent_ok as a function pointer
argument so that it doesn't get applied to the IOMMU case.
S
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. To get around this double check CMA's placement before
allocating from it.
Signed-off-by: Nicolas Saenz Julienne
[hch: rebase
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 Chanc
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 few
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_
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:
>
> http://git.infradead.org/us
ome cases as it applies to all entries. 'contains' is the correct schema
> to use in the case of multiple entries.
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Eric Anholt
> Cc: Nicolas Saenz Julienne
> Cc: F
Hi Christoph,
On Sun, 2021-02-07 at 17:03 +0100, Christoph Hellwig wrote:
> Split out a bunch of a self-contained helpers to make the function easier
> to follow.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/swiotlb.c | 179 +--
> 1 file change
The default behavior for arm64 changed, so reflect that.
Signed-off-by: Nicolas Saenz Julienne
---
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..d28ce77ccc2a 100644
--- a
s the only platform interested in using this is the Raspberry Pi 4.
So update zone_dma_bits if the machine's compatible string matches
Raspberry Pi 4's, otherwise let arm64's mm code deal with it.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/fdt.c | 10 ++
1 file ch
ZONE_DMA and only define both zones if running on RPi4.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e1a69a618832..3c3f462466eb 100644
--- a/arch
Other code might need to reference it.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 38ed3b55034d
Using two distinct DMA zones turned out to be problematic. Here's an
attempt go back to a saner default.
I tested this on both a RPi4 and QEMU.
---
Nicolas Saenz Julienne (4):
of/fdt: Update zone_dma_bits when running in bcm2711
dma-direct: Turn zone_dma_bits default value into a d
On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > Hi Nicolas,
> >
> > Thanks for putting this together.
> >
> > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wro
Hi Catalin, sorry for the late reply.
On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas Saenz Julienne wrote:
> > On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> > > On Thu, Oct 01, 2020 at 06:15:01PM +010
On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > > Sadly I just realised that the series is incomplete, we have RPi4 users
> > &
Hi Jeremy.
On Thu, 2020-10-08 at 22:59 -0500, Jeremy Linton wrote:
> On 10/8/20 2:43 PM, Ard Biesheuvel wrote:
> > (+ Lorenzo)
> >
> > On Thu, 8 Oct 2020 at 12:14, Catalin Marinas
> > wrote:
> > > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Jul
On Fri, 2020-10-09 at 11:13 +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
> wrote:
> > On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> > > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > > > On Thu,
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 call
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
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
since v1:
- Parse 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: Dy
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 i
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
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
ed, I'll update all commit logs.
> On Sat, 10 Oct 2020 at 17:12, Nicolas Saenz Julienne
> wrote:
> > 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 memo
Hi Rob,
On Mon, 2020-10-12 at 10:25 -0500, Rob Herring wrote:
> On Sat, Oct 10, 2020 at 10:12 AM Nicolas Saenz Julienne
> wrote:
> > The function provides the CPU physical address addressable by the most
> > constrained bus in the system. It might be useful in order to
>
to reserve the memory before the page allocator kicks in and there is
no need to do it earlier.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index a53c1e0fb017..1d
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
ll changes
- Move crashkernel reservation later in boot process
Changes since v1:
- Parse dma-ranges instead of using machine compatible string
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (7):
arm64: mm: Move reserve_crashkernel() int
Set zone_dma_bits default value through a define so as for architectures
to be able to override it with their default value.
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/dma-direct.h | 3 +++
kernel/dma/direct.c| 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff
MA32 cover the rest of the 32-bit address
space.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Updated commit log by shamelessly copying Ard's ACPI counterpart commit log
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/mm/init.c | 5 ++---
2 files change
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Use PHYS_ADD
od if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Ans
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --
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-off-by: Nicolas Saenz Julienne
---
drivers/of/unittest.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of
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
&
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 A
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
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-
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 *ch
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.
>
> Arch
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)));
>
&
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 bits of
od if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Ans
MA32 cover the rest of the 32-bit address
space.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Simplify code for readability.
Changes since v2:
- Updated commit log by shamelessly copying Ard's ACPI commit log
arch/arm64/mm/init.c | 6 +++---
1 file changed, 3 insertions(
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-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- Remove HAS_DMA guards
drivers/of/unittest.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a
to reserve the memory before the page allocator kicks in. There
isn't any apparent reason for doing this earlier.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v3:
- use u64 with cp
We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: Christoph Hellwig
Signed-off-by: Nicolas Saenz Julienne
---
include/linux/mmzone.h
mpatible string
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (6):
arm64: mm: Move reserve_crashkernel() into mem_init()
arm64: mm: Move zone_dma_bits initialization into zone_sizes_init()
of/address: Introduce of_dma_get_max_cpu_address()
On Thu, 2020-10-22 at 14:23 +0200, Ard Biesheuvel wrote:
> > +/**
> > + * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
> > + * @np: The node to start searching from or NULL to start from the root
> > + *
> > + * Gets the highest CPU physical address that is addressable by
Hi Catalin,
On Thu, 2020-10-22 at 19:06 +0100, Catalin Marinas wrote:
> On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int
> > zone_bits)
> > static void __init zone_sizes_i
On Fri, 2020-10-23 at 14:05 -0500, Jeremy Linton wrote:
> Hi,
>
> On 10/21/20 7:34 AM, Nicolas Saenz Julienne wrote:
> > Using two distinct DMA zones turned out to be problematic. Here's an
> > attempt go back to a saner default.
> >
> > I tested this on
zone_dma_bits's initialization happens earlier that it's actually
needed, in arm64_memblock_init(). So move it into the more suitable
zone_sizes_init().
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Jeremy Linton
---
arch/arm64/mm/init.c | 7 ++-
1 file changed, 2 insert
to reserve the memory before the page allocator kicks in. There
isn't any apparent reason for doing this earlier.
Signed-off-by: Nicolas Saenz Julienne
Tested-by: Jeremy Linton
---
arch/arm64/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/init
Introduce of_dma_get_max_cpu_address(), which provides the highest CPU
physical address addressable by all DMA masters in the system. It's
specially useful for setting memory zones sizes at early boot time.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v4:
- Return max address
MA32 cover the rest of the 32-bit address
space.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v4:
- Use fls64 as we're now using the max address (as opposed to the
limit)
Changes since v3:
- Simplify code for readability.
Changes since v2:
- Updated commit log by shamelessl
We can't really list every setup in common code. On top of that they are
unlikely to stay true for long as things change in the arch trees
independently of this comment.
Suggested-by: Christoph Hellwig
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Christoph Hellwig
---
include/
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-off-by: Nicolas Saenz Julienne
Reviewed-by: Rob Herring
---
Changes since v3:
- Remove HAS_DMA guards
drivers/of/unittest.c | 18 ++
1 file changed, 18
ove crashkernel reservation later in boot process
Changes since v1:
- Parse dma-ranges instead of using machine compatible string
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (6):
arm64: mm: Move reserve_crashkernel() into mem_init()
od if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.
Cc: Jeremy Linton
Cc: Lorenzo Pieralisi
Cc: Nicolas Saenz Julienne
Cc: Rob Herring
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Ans
On Fri, 2020-10-30 at 18:11 +, Catalin Marinas wrote:
> On Thu, Oct 29, 2020 at 06:25:43PM +0100, Nicolas Saenz Julienne wrote:
> > Ard Biesheuvel (1):
> > arm64: mm: Set ZONE_DMA size based on early IORT scan
> >
> > Nicolas Saenz Julienne (6):
> > ar
for OF function
- Address small changes
- Move crashkernel reservation later in boot process
Changes since v1:
- Parse dma-ranges instead of using machine compatible string
Ard Biesheuvel (1):
arm64: mm: Set ZONE_DMA size based on early IORT scan
Nicolas Saenz Julienne (6):
101 - 200 of 220 matches
Mail list logo
