| Message ID | 20190820145821.27214-2-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Raspberry Pi 4 DMA addressing support | expand |
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 constraints > in a generic manner, so as for arch code to properly setup it's memory > zones and DMA mask. I know this just spreads the arm code, but I still kinda hate it. MAX_DMA_ADDRESS is such an oddly defined concepts. We have the mm code that uses it to start allocating after the dma zones, but I think that would better be done using a function returning 1 << max(zone_dma_bits, 32) or so. Then we have about a handful of drivers using it that all seem rather bogus, and one of which I think are usable on arm64.
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 constraints > > in a generic manner, so as for arch code to properly setup it's memory > > zones and DMA mask. > > I know this just spreads the arm code, but I still kinda hate it. Rob's main concern was finding a way to pass the constraint from HW definition to arch without widening fdt's architecture specific function surface. I'd say it's fair to argue that having a generic mechanism makes sense as it'll now traverse multiple archs and subsystems. I get adding globals like this is not very appealing, yet I went with it as it was the easier to integrate with arm's code. Any alternative suggestions? > MAX_DMA_ADDRESS is such an oddly defined concepts. We have the mm > code that uses it to start allocating after the dma zones, but > I think that would better be done using a function returning > 1 << max(zone_dma_bits, 32) or so. Then we have about a handful > of drivers using it that all seem rather bogus, and one of which > I think are usable on arm64. Is it safe to assume DMA limitations will always be a power of 2? I ask as RPi4 kinda isn't: ZONE_DMA is 0x3c000000 bytes big, I'm approximating the zone mask to 30 as [0x3c000000 0x3fffffff] isn't defined as memory so it's unlikely that we´ll encounter buffers there. But I don't know how it could affect mm initialization code. This also rules out 'zone_dma_bits' as a mechanism to pass ZONE_DMA's size from HW definition code to arch's.
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 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. > > > > I know this just spreads the arm code, but I still kinda hate it. > > Rob's main concern was finding a way to pass the constraint from HW definition > to arch without widening fdt's architecture specific function surface. I'd say > it's fair to argue that having a generic mechanism makes sense as it'll now > traverse multiple archs and subsystems. > > I get adding globals like this is not very appealing, yet I went with it as it > was the easier to integrate with arm's code. Any alternative suggestions? > > > MAX_DMA_ADDRESS is such an oddly defined concepts. We have the mm > > code that uses it to start allocating after the dma zones, but > > I think that would better be done using a function returning > > 1 << max(zone_dma_bits, 32) or so. Then we have about a handful > > of drivers using it that all seem rather bogus, and one of which > > I think are usable on arm64. > > Is it safe to assume DMA limitations will always be a power of 2? I ask as > RPi4 > kinda isn't: ZONE_DMA is 0x3c000000 bytes big, I'm approximating the zone mask > to 30 as [0x3c000000 0x3fffffff] isn't defined as memory so it's unlikely that > we´ll encounter buffers there. But I don't know how it could affect mm > initialization code. > > This also rules out 'zone_dma_bits' as a mechanism to pass ZONE_DMA's size > from > HW definition code to arch's. Hi Christoph, I gave it a thought and think this whole MAX_DMA_ADDRESS topic falls out of the scope of the series. I agree it's something that we should get rid of, but fixing it isn't going to affect the overall enhancement intended here. I'd rather focus on how are we going to pass the DMA zone data into the arch code and fix MAX_DMA_ADDRESS on another series. Regards, Nicolas
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 wrote: > > > 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. > > > > I know this just spreads the arm code, but I still kinda hate it. > > Rob's main concern was finding a way to pass the constraint from HW definition > to arch without widening fdt's architecture specific function surface. I'd say > it's fair to argue that having a generic mechanism makes sense as it'll now > traverse multiple archs and subsystems. > > I get adding globals like this is not very appealing, yet I went with it as it > was the easier to integrate with arm's code. Any alternative suggestions? In some discussion with Robin, since it's just RPi4 that we are aware of having such requirement on arm64, he suggested that we have a permanent ZONE_DMA on arm64 with a default size of 1GB. It should cover all arm64 SoCs we know of without breaking the single Image binary. The arch/arm can use its current mach-* support. I may like this more than the proposed early_init_dt_get_dma_zone_size() here which checks for specific SoCs (my preferred way was to build the mask from all buses described in DT but I hadn't realised the complications).
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 wrote: > > > > 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. > > > > > > I know this just spreads the arm code, but I still kinda hate it. > > > > Rob's main concern was finding a way to pass the constraint from HW > > definition > > to arch without widening fdt's architecture specific function surface. I'd > > say > > it's fair to argue that having a generic mechanism makes sense as it'll now > > traverse multiple archs and subsystems. > > > > I get adding globals like this is not very appealing, yet I went with it as > > it > > was the easier to integrate with arm's code. Any alternative suggestions? > > In some discussion with Robin, since it's just RPi4 that we are aware of > having such requirement on arm64, he suggested that we have a permanent > ZONE_DMA on arm64 with a default size of 1GB. It should cover all arm64 > SoCs we know of without breaking the single Image binary. The arch/arm > can use its current mach-* support. > > I may like this more than the proposed early_init_dt_get_dma_zone_size() > here which checks for specific SoCs (my preferred way was to build the > mask from all buses described in DT but I hadn't realised the > complications). Hi Catalin, thanks for giving it a thought. I'll be happy to implement it that way. I agree it's a good compromise. @Christoph, do you still want the patch where I create 'zone_dma_bits'? With a hardcoded ZONE_DMA it's not absolutely necessary. Though I remember you said it was a first step towards being able to initialize dma-direct's min_mask in meminit. Regards, Nicolas
On Fri, Aug 30, 2019 at 07:24:25PM +0200, Nicolas Saenz Julienne wrote: > I'll be happy to implement it that way. I agree it's a good compromise. > > @Christoph, do you still want the patch where I create 'zone_dma_bits'? With a > hardcoded ZONE_DMA it's not absolutely necessary. Though I remember you said it > was a first step towards being able to initialize dma-direct's min_mask in > meminit. I do like the variable better than the current #define. I wonder if really want a mask or a max_zone_dma_address like variable. So for this series feel free to drop the patch. I'll see if I'll pick it up later or if we can find some way to automatically propagate that information from the zone initialization.
diff --git a/include/asm-generic/dma.h b/include/asm-generic/dma.h index 43d0c8af8058..c2f39cdb64f6 100644 --- a/include/asm-generic/dma.h +++ b/include/asm-generic/dma.h @@ -8,7 +8,13 @@ * * Some code relies on seeing MAX_DMA_ADDRESS though. */ -#define MAX_DMA_ADDRESS PAGE_OFFSET +#define MAX_DMA_ADDRESS (PAGE_OFFSET + dma_zone_size) + +/* + * Some architectures may have platform specific DMA addressing constraints. + * Firmware can use this to fine tune the device's DMA memory zone. + */ +extern u64 dma_zone_size __ro_after_init; extern int request_dma(unsigned int dmanr, const char *device_id); extern void free_dma(unsigned int dmanr); diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 272c6de1bf4e..b514afee5451 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -133,6 +133,9 @@ EXPORT_SYMBOL(_totalram_pages); unsigned long totalreserve_pages __read_mostly; unsigned long totalcma_pages __read_mostly; +u64 dma_zone_size __ro_after_init; +EXPORT_SYMBOL(dma_zone_size); + int percpu_pagelist_fraction; gfp_t gfp_allowed_mask __read_mostly = GFP_BOOT_MASK; #ifdef CONFIG_INIT_ON_ALLOC_DEFAULT_ON
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 <nsaenzjulienne@suse.de> --- Changes in v2: None include/asm-generic/dma.h | 8 +++++++- mm/page_alloc.c | 3 +++ 2 files changed, 10 insertions(+), 1 deletion(-)