Hi All,
On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
> On 1/5/21 7:41 PM, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes in the device tree.
> >
> > Signed-off-by: Claire Chang
> > ---
> > include/linu
So far this function was only used locally in powerpc, some other
architectures might benefit from it. Move it into
scripts/Makefile.defconf.
Signed-off-by: Nicolas Saenz Julienne
---
arch/powerpc/Makefile| 12 +---
scripts/Makefile.defconf | 15 +++
2 files changed, 16
e RFC:
- Move merge function into the scripts directory.
Nicolas Saenz Julienne (2):
kbuild: Add config fragment merge functionality
ARM: add multi_v7_lpae_defconfig
arch/arm/Makefile| 4
arch/arm/configs/lpae.config | 1 +
arch/powerpc/Makefile
fig, built off multi_v7_defconfig, which will
avoid us having to duplicate and maintain multiple similar configurations.
Needless to say the Raspberry Pi 4 is not the only platform that can
benefit from this new configuration.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since RFC:
- M
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
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
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 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
On Wed, 2019-11-13 at 17:13 +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 one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
On Tue, 2019-11-19 at 10:27 +0100, Marek Szyprowski wrote:
> Hi Christoph,
>
> On 13.11.2019 08:35, Christoph Hellwig wrote:
> > Currently each architectures that wants to override dma_to_phys and
> > phys_to_dma also has to provide dma_capable. But there isn't really
> > any good reason for that
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
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 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
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
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 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.
> >
>
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 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 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
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
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 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
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_
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
> >
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
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
26 matches
Mail list logo
