From: Christoph Hellwig <hch@lst.de>
To: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexandre Torgue <alexandre.torgue@st.com>,
info@metux.net, linux@armlinux.org.uk,
linux-stm32@st-md-mailman.stormreply.com,
Rob Herring <robh+dt@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
tglx@linutronix.de, dillon min <dillon.minfei@gmail.com>,
Christoph Hellwig <hch@lst.de>,
allison@lohutok.net
Subject: Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory
Date: Tue, 9 Jun 2020 19:34:55 +0200 [thread overview]
Message-ID: <20200609173455.GA25467@lst.de> (raw)
In-Reply-To: <b0c85637-4646-614b-d406-49aa72ce52e1@arm.com>
On Tue, Jun 09, 2020 at 05:25:04PM +0100, Vladimir Murzin wrote:
> Even though commit mentions ARM, I do not see how mmap would continue
> to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations
> only in cases where caches are implemented or active, in other cases it
> fully relies on dma-direct.
> It looks to me that we either should provide NOMMU variant for mmap in
> dma/direct or (carefully) fix dma/mapping.
I think dma-direct is the right place, the common helpers in
dma/mapping.c are basically the red headed stepchilds for misc
IOMMU drivers not covered by dma-iommu only.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Christoph Hellwig <hch@lst.de>,
dillon min <dillon.minfei@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
linux@armlinux.org.uk,
Kate Stewart <kstewart@linuxfoundation.org>,
allison@lohutok.net, info@metux.net, tglx@linutronix.de,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
linux-stm32@st-md-mailman.stormreply.com,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory
Date: Tue, 9 Jun 2020 19:34:55 +0200 [thread overview]
Message-ID: <20200609173455.GA25467@lst.de> (raw)
In-Reply-To: <b0c85637-4646-614b-d406-49aa72ce52e1@arm.com>
On Tue, Jun 09, 2020 at 05:25:04PM +0100, Vladimir Murzin wrote:
> Even though commit mentions ARM, I do not see how mmap would continue
> to work for NOMMU with dma-direct. ARM NOMMU needs it's own DMA operations
> only in cases where caches are implemented or active, in other cases it
> fully relies on dma-direct.
> It looks to me that we either should provide NOMMU variant for mmap in
> dma/direct or (carefully) fix dma/mapping.
I think dma-direct is the right place, the common helpers in
dma/mapping.c are basically the red headed stepchilds for misc
IOMMU drivers not covered by dma-iommu only.
next prev parent reply other threads:[~2020-06-09 17:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 8:30 [PATCH 0/2] Use 'arm_nommu_dma_ops' to handle dma memroy if device offer consistent dma memory region dillon.minfei
2020-06-08 8:30 ` dillon.minfei
2020-06-08 8:30 ` [PATCH 1/2] ARM: dts: stm32: Setup 4M bytes reserved memory for mmap dillon.minfei
2020-06-08 8:30 ` dillon.minfei
2020-06-09 15:58 ` dillon min
2020-06-09 15:58 ` dillon min
2020-06-08 8:30 ` [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory dillon.minfei
2020-06-08 8:30 ` dillon.minfei
2020-06-09 14:08 ` Vladimir Murzin
2020-06-09 14:08 ` Vladimir Murzin
2020-06-09 15:22 ` dillon min
2020-06-09 15:22 ` dillon min
2020-06-09 15:36 ` Christoph Hellwig
2020-06-09 15:36 ` Christoph Hellwig
2020-06-09 15:43 ` Vladimir Murzin
2020-06-09 15:43 ` Vladimir Murzin
2020-06-09 16:25 ` Vladimir Murzin
2020-06-09 16:25 ` Vladimir Murzin
2020-06-09 17:34 ` Christoph Hellwig [this message]
2020-06-09 17:34 ` Christoph Hellwig
2020-06-10 2:24 ` dillon min
2020-06-10 2:24 ` dillon min
2020-06-10 7:24 ` Christoph Hellwig
2020-06-10 7:24 ` Christoph Hellwig
2020-06-10 8:19 ` Vladimir Murzin
2020-06-10 8:19 ` Vladimir Murzin
2020-06-11 15:45 ` Vladimir Murzin
2020-06-11 15:45 ` Vladimir Murzin
2020-06-12 2:15 ` dillon min
2020-06-12 2:15 ` dillon min
2020-06-09 15:58 ` [PATCH 0/2] Use 'arm_nommu_dma_ops' to handle dma memroy if device offer consistent dma memory region dillon min
2020-06-09 15:58 ` dillon min
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=20200609173455.GA25467@lst.de \
--to=hch@lst.de \
--cc=alexandre.torgue@st.com \
--cc=allison@lohutok.net \
--cc=devicetree@vger.kernel.org \
--cc=dillon.minfei@gmail.com \
--cc=info@metux.net \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@armlinux.org.uk \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
--cc=vladimir.murzin@arm.com \
/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.