| Message ID | 20190820145821.27214-11-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:18PM +0200, Nicolas Saenz Julienne wrote: > - if (IS_ENABLED(CONFIG_ZONE_DMA)) > + if (IS_ENABLED(CONFIG_ZONE_DMA)) { > arm64_dma_phys_limit = max_zone_dma_phys(); > + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) & GENMASK_ULL(31, 0)) + 1; This adds a way too long line. I also find the use of GENMASK_ULL horribly obsfucating, but I know that opinion is't shared by everyone.
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_limit = max_zone_dma_phys(); > > + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) & > > GENMASK_ULL(31, 0)) + 1; > Hi Christoph, thanks for the rewiews. > This adds a way too long line. I know, I couldn't find a way to split the operation without making it even harder to read. I'll find a solution. > I also find the use of GENMASK_ULL > horribly obsfucating, but I know that opinion is't shared by everyone. Don't have any preference so I'll happily change it. Any suggestions? Using the explicit 0xffffffffULL seems hard to read, how about SZ_4GB - 1?
On Mon, 26 Aug 2019 13:08:50 +0200 Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > 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_limit = max_zone_dma_phys(); > > > + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) & > > > GENMASK_ULL(31, 0)) + 1; > > > Hi Christoph, > thanks for the rewiews. > > > This adds a way too long line. > > I know, I couldn't find a way to split the operation without making it even > harder to read. I'll find a solution. If all else fails, move the code to an inline function and call it e.g. phys_limit_to_dma_bits(). Just my two cents, Petr T
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index c51ce79b692b..c5e619f21ad8 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -22,6 +22,7 @@ #include <linux/of_fdt.h> #include <linux/dma-mapping.h> #include <linux/dma-contiguous.h> +#include <linux/dma-direct.h> #include <linux/efi.h> #include <linux/swiotlb.h> #include <linux/vmalloc.h> @@ -437,8 +438,10 @@ void __init arm64_memblock_init(void) early_init_fdt_scan_reserved_mem(); - if (IS_ENABLED(CONFIG_ZONE_DMA)) + if (IS_ENABLED(CONFIG_ZONE_DMA)) { arm64_dma_phys_limit = max_zone_dma_phys(); + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) & GENMASK_ULL(31, 0)) + 1; + } if (IS_ENABLED(CONFIG_ZONE_DMA32)) arm64_dma32_phys_limit = max_zone_dma32_phys();
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 <nsaenzjulienne@suse.de> --- Changes in v2: - Make sure to filter the higher part of arm64_dma_phys_limit - Rename variable to zone_dma_bits arch/arm64/mm/init.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)