Hi Jim,
thanks for having a go at this! My two cents.
On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> The device variable 'dma_pfn_offset' is used to do a single
> linear map between cpu addrs and dma addrs. The variable
> 'dma_map' is added to struct device to point to an array
> of mult
Hi Jim,
one thing comes to mind, there is a small test suite in drivers/of/unittest.c
(specifically of_unittest_pci_dma_ranges()) you could extend it to include your
use cases.
On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> The new field in struct device 'dma_pfn_offset_map' is used to fa
Hi Jim,
On Wed, 2020-05-27 at 11:43 -0400, Jim Quinlan wrote:
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> wrote:
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in
> > drivers/of/unittest.c
> > (specifical
Hi Jim,
On Wed, 2020-06-03 at 15:20 -0400, Jim Quinlan wrote:
> The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> the use of multiple pfn offsets between cpu addrs and dma addrs. It
> subsumes the role of dev->dma_pfn_offset -- a uniform offset -- and
> designates the si
Hi Jim,
On Thu, 2020-06-04 at 10:35 -0400, Jim Quinlan wrote:
[...]
> > > --- a/arch/sh/kernel/dma-coherent.c
> > > +++ b/arch/sh/kernel/dma-coherent.c
> > > @@ -14,6 +14,8 @@ void *arch_dma_alloc(struct device *dev, size_t size,
> > > dma_addr_t *dma_handle,
> > > {
> > > void *ret, *ret
Hi Christoph,
a question arouse, is there a real value to dealing with PFNs (as opposed to
real addresses) in the core DMA code/structures? I see that in some cases it
eases interacting with mm, but the overwhelming usage of say,
dev->dma_pfn_offset, involves shifting it.
Hi Jim,
On Thu, 2020-06-0
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/of
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:
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/arm
o account devices with DMA offset.
- Rename new dma-direct variable 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_
'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 inserti
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
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 condit
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 co
herals where able 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/
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
a.
Signed-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/m
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
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
> &
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
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 the const
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 addressing limitation
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
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 on
itable 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:
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
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 +
arc
A ops 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
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 Jul
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
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 buffers
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
>
n
overflow 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
quisite 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
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.
> >
>
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) <
> >
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
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.
> >
>
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 able to catch inadv
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
n
overflow 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
quisite 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:
-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
- 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 (3):
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
bus 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: Nicol
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
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 in
bus 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: Nicol
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
- Use edge triggered 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 capabilit
-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
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 io
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
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
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
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
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
brcmstb: Add Broadcom STB PCIe host 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
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
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
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
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
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
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:
> &g
nd up 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/kerne
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
_mask' 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 deletio
l fit all devices. I made the algorithm as simple as possible, based 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,
Ni
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
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 able t
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 DMA32
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
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
y addressable by all 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(-)
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/
and memory 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/
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
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
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
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
the new runtime calculated min_mask*.
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 c
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
> >
Hi Christoph, thanks for the review.
On Thu, 2019-08-01 at 16:04 +0200, Christoph Hellwig wrote:
> A few nitpicks, otherwise this looks great:
>
> > @@ -201,7 +202,7 @@ static int __init mark_nonram_nosave(void)
> > * everything else. GFP_DMA32 page allocations automatically fall back to
> >
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
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 &#
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,
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
bility of using dma_pool_kernel for the non constrained ones.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp
mask")
Reported-by: Jeremy Linton
Suggested-by: Robin Murphy
Signed-off-by: Nicolas Saenz Julienne
---
kernel/dma/pool.c | 47 +++--
Hi Jim,
On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote:
> Hi,
>
> I spun this up on my 8G model using the PFTF firmware from:
>
> https://github.com/pftf/RPi4/releases
>
> Which allows me to switch between ACPI/DT on the machine. In DT mode it
> works fine now,
Nice, would that count
On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote:
> On Tue, Jul 07, 2020 at 02:28:04PM +0200, Nicolas Saenz Julienne wrote:
> > When allocating atomic DMA memory for a device, the dma-pool core
> > queries __dma_direct_optimal_gfp_mask() to check which atomic pool to
&g
Signed-off-by: Nicolas Saenz Julienne
---
An more costly alternative would be adding an option to
dma_alloc_from_contiguous() so it fails when the allocation doesn't fall
in a specific zone.
kernel/dma/pool.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a
[2] https://lkml.org/lkml/2020/7/8/1108
---
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: Make sure atomic pool suits device
include/linux/dma-dir
er) memory
zone.
To help mitigate this, introduce dma_guess_pool() which can be fed a
device's DMA constraints or an atomic pool already known to be faulty in
order for it to provide a better guess at 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
---
kernel/dma/pool.c | 53 +--
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 3d518de07617..d48d9acb585f 100644
--- a/ker
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
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 8cfa01243ed2..7363640fc91c 100644
--- a
On Thu, 2020-07-09 at 14:49 -0700, David Rientjes wrote:
> On Wed, 8 Jul 2020, Christoph Hellwig wrote:
>
> > On Wed, Jul 08, 2020 at 06:00:35PM +0200, Nicolas Saenz Julienne wrote:
> > > On Wed, 2020-07-08 at 17:35 +0200, Christoph Hellwig wrote:
> > > > On Tue,
nt pools to map to gfp
mask")
Reported-by: Jeremy Linton
Signed-off-by: Nicolas Saenz Julienne
---
This is a code intensive alternative to "dma-pool: Do not allocate pool
memory from CMA"[1].
[1] https://lkml.org/lkml/2020/7/8/1108
kernel/dma/pool.c | 36 ++
On Tue, 2020-07-14 at 13:22 +0200, Christoph Hellwig wrote:
> This one doesn't appear to actually apply on top of Linus' tree plus the
> two previous patches.
I'll take care of it.
signature.asc
Description: This is a digitally signed message part
___
1 - 100 of 220 matches
Mail list logo
