From: Christoph Hellwig <hch@lst.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
Christoph Hellwig <hch@lst.de>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
will@kernel.org, phil@raspberrypi.org, stefan.wahren@i2se.com,
f.fainelli@gmail.com, mbrugger@suse.com,
Jisheng.Zhang@synaptics.com, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC 3/4] dma-direct: add dma_direct_min_mask
Date: Wed, 24 Jul 2019 15:56:57 +0200 [thread overview]
Message-ID: <20190724135657.GA9075@lst.de> (raw)
In-Reply-To: <20190724135124.GA44864@arrakis.emea.arm.com>
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 covers the first naturally aligned 4GB of RAM
> (unchanged). When a smaller ZONE_DMA is not needed, it could be expanded
> to cover what would normally be ZONE_DMA32 (or could we have ZONE_DMA as
> 0-bytes? I don't think GFP_DMA can still allocate memory in this case).
>
> We'd probably have to define ARCH_ZONE_DMA_BITS for arm64 to something
> smaller than 32-bit but sufficient to cover the known platforms like
> RPi4 (the current 24 is too small, so maybe 30). AFAICT,
> __dma_direct_optimal_gfp_mask() figures out whether GFP_DMA or GFP_DMA32
> should be passed.
ARCH_ZONE_DMA_BITS should probably become a variable. That way we can
just initialize it to the default 24 bits in kernel/dma/direct.c and
allow architectures to override it in their early boot code.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: stefan.wahren@i2se.com, f.fainelli@gmail.com,
Robin Murphy <robin.murphy@arm.com>,
phil@raspberrypi.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Jisheng.Zhang@synaptics.com,
mbrugger@suse.com,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
will@kernel.org, Christoph Hellwig <hch@lst.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 3/4] dma-direct: add dma_direct_min_mask
Date: Wed, 24 Jul 2019 15:56:57 +0200 [thread overview]
Message-ID: <20190724135657.GA9075@lst.de> (raw)
In-Reply-To: <20190724135124.GA44864@arrakis.emea.arm.com>
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 covers the first naturally aligned 4GB of RAM
> (unchanged). When a smaller ZONE_DMA is not needed, it could be expanded
> to cover what would normally be ZONE_DMA32 (or could we have ZONE_DMA as
> 0-bytes? I don't think GFP_DMA can still allocate memory in this case).
>
> We'd probably have to define ARCH_ZONE_DMA_BITS for arm64 to something
> smaller than 32-bit but sufficient to cover the known platforms like
> RPi4 (the current 24 is too small, so maybe 30). AFAICT,
> __dma_direct_optimal_gfp_mask() figures out whether GFP_DMA or GFP_DMA32
> should be passed.
ARCH_ZONE_DMA_BITS should probably become a variable. That way we can
just initialize it to the default 24 bits in kernel/dma/direct.c and
allow architectures to override it in their early boot code.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: stefan.wahren@i2se.com, f.fainelli@gmail.com,
Robin Murphy <robin.murphy@arm.com>,
phil@raspberrypi.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Jisheng.Zhang@synaptics.com,
mbrugger@suse.com,
Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
will@kernel.org, Christoph Hellwig <hch@lst.de>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RFC 3/4] dma-direct: add dma_direct_min_mask
Date: Wed, 24 Jul 2019 15:56:57 +0200 [thread overview]
Message-ID: <20190724135657.GA9075@lst.de> (raw)
In-Reply-To: <20190724135124.GA44864@arrakis.emea.arm.com>
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 covers the first naturally aligned 4GB of RAM
> (unchanged). When a smaller ZONE_DMA is not needed, it could be expanded
> to cover what would normally be ZONE_DMA32 (or could we have ZONE_DMA as
> 0-bytes? I don't think GFP_DMA can still allocate memory in this case).
>
> We'd probably have to define ARCH_ZONE_DMA_BITS for arm64 to something
> smaller than 32-bit but sufficient to cover the known platforms like
> RPi4 (the current 24 is too small, so maybe 30). AFAICT,
> __dma_direct_optimal_gfp_mask() figures out whether GFP_DMA or GFP_DMA32
> should be passed.
ARCH_ZONE_DMA_BITS should probably become a variable. That way we can
just initialize it to the default 24 bits in kernel/dma/direct.c and
allow architectures to override it in their early boot code.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-07-24 13:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 15:31 [RFC 0/4] Raspberry Pi 4 DMA addressing support Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 2/4] arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-24 13:54 ` Catalin Marinas
2019-07-24 13:54 ` Catalin Marinas
2019-07-17 15:31 ` [RFC 3/4] dma-direct: add dma_direct_min_mask Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-18 9:15 ` Christoph Hellwig
2019-07-18 9:15 ` Christoph Hellwig
2019-07-18 9:15 ` Christoph Hellwig
2019-07-18 11:18 ` Nicolas Saenz Julienne
2019-07-18 11:18 ` Nicolas Saenz Julienne
2019-07-18 11:18 ` Nicolas Saenz Julienne
2019-07-19 13:08 ` Nicolas Saenz Julienne
2019-07-19 13:08 ` Nicolas Saenz Julienne
2019-07-19 13:08 ` Nicolas Saenz Julienne
2019-07-24 13:51 ` Catalin Marinas
2019-07-24 13:51 ` Catalin Marinas
2019-07-24 13:51 ` Catalin Marinas
2019-07-24 13:56 ` Christoph Hellwig [this message]
2019-07-24 13:56 ` Christoph Hellwig
2019-07-24 13:56 ` Christoph Hellwig
2019-07-24 14:27 ` Nicolas Saenz Julienne
2019-07-24 14:27 ` Nicolas Saenz Julienne
2019-07-24 14:27 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 4/4] arm64: mm: set direct_dma_min_mask according to dma-ranges Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190724135657.GA9075@lst.de \
--to=hch@lst.de \
--cc=Jisheng.Zhang@synaptics.com \
--cc=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mbrugger@suse.com \
--cc=nsaenzjulienne@suse.de \
--cc=phil@raspberrypi.org \
--cc=robin.murphy@arm.com \
--cc=stefan.wahren@i2se.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.