[PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Isaac J. Manjarres]

Currently, IOMMU_QCOM_SYS_CACHE exists to allow non-coherent
I/O masters on Qualcomm SoCs to upgrade to caching their
buffers in the outer-level/system cache on these platforms.
However, these masters are limited to managing the mapping
of these buffers themselves through the IOMMU framework,
as opposed to allowing the DMA-IOMMU framework to handle it,
since there is no DMA attribute that maps to the
IOMMU_QCOM_SYS_CACHE protection bit.

Thus, introduce DMA_ATTR_SYS_CACHE so that clients
can use the DMA-IOMMU layer to map their DMA buffers with
the correct memory attributes to allow the buffers to be
cached in the outer-level/system cache.

Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
---
 drivers/iommu/dma-iommu.c   | 2 ++
 include/linux/dma-mapping.h | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index f321279..c433ece 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -369,6 +369,8 @@ static int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
 
 	if (attrs & DMA_ATTR_PRIVILEGED)
 		prot |= IOMMU_PRIV;
+	if (attrs & DMA_ATTR_SYS_CACHE)
+		prot |= IOMMU_QCOM_SYS_CACHE;
 
 	switch (dir) {
 	case DMA_BIDIRECTIONAL:
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fc..bdd4dcf 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -71,6 +71,14 @@
 #define DMA_ATTR_PRIVILEGED		(1UL << 9)
 
 /*
+ * DMA_ATTR_SYS_CACHE: This is a hint that non-coherent masters can use to
+ * tell the DMA-IOMMU layer to map their DMA buffers with the correct memory
+ * attributes that allow these buffers to be cached in an outer-level/system
+ * cache.
+ */
+#define DMA_ATTR_SYS_CACHE		(1UL << 10)
+
+/*
  * A dma_addr_t can hold any valid DMA or bus address for the platform.
  * It can be given to a device to use as a DMA source or target.  A CPU cannot
  * reference a dma_addr_t directly because there may be translation between
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Christoph Hellwig]

The definition makes very little sense.  Any without a user in the
same series it is a complete no-go anyway.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[isaacm]

On 2019-10-25 22:30, Christoph Hellwig wrote:
> The definition makes very little sense.
Can you please clarify what part doesn’t make sense, and why? This is 
really just an extension of this patch that got mainlined, so that 
clients that use the DMA API can use IOMMU_QCOM_SYS_CACHE as well: 
https://patchwork.kernel.org/patch/10946099/
>  Any without a user in the same series it is a complete no-go anyway.
IOMMU_QCOM_SYS_CACHE does not have any current users in the mainline, 
nor did it have it in the patch series in which it got merged, yet it is 
still present? Furthermore, there are plans to upstream support for one 
of our SoCs that may benefit from this, as seen here: 
https://www.spinics.net/lists/iommu/msg39608.html.

Thanks,
Isaac
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Christoph Hellwig]

On Sat, Oct 26, 2019 at 03:12:57AM -0700, isaacm@codeaurora.org wrote:
> On 2019-10-25 22:30, Christoph Hellwig wrote:
>> The definition makes very little sense.
> Can you please clarify what part doesn’t make sense, and why?

It looks like complete garbage to me.  That might just be because it
uses tons of terms I've never heard of of and which aren't used anywhere
in the DMA API.  It also might be because it doesn't explain how the
flag might actually be practically useful.

> This is 
> really just an extension of this patch that got mainlined, so that clients 
> that use the DMA API can use IOMMU_QCOM_SYS_CACHE as well: 
> https://patchwork.kernel.org/patch/10946099/
>>  Any without a user in the same series it is a complete no-go anyway.
> IOMMU_QCOM_SYS_CACHE does not have any current users in the mainline, nor 
> did it have it in the patch series in which it got merged, yet it is still 
> present? Furthermore, there are plans to upstream support for one of our 
> SoCs that may benefit from this, as seen here: 
> https://www.spinics.net/lists/iommu/msg39608.html.

Which means it should have never been merged.  As a general policy we do
not add code to the Linux kernel without actual users.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Will Deacon]

Hi Christoph,

On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
> On Sat, Oct 26, 2019 at 03:12:57AM -0700, isaacm@codeaurora.org wrote:
> > On 2019-10-25 22:30, Christoph Hellwig wrote:
> >> The definition makes very little sense.
> > Can you please clarify what part doesn’t make sense, and why?
> 
> It looks like complete garbage to me.  That might just be because it
> uses tons of terms I've never heard of of and which aren't used anywhere
> in the DMA API.  It also might be because it doesn't explain how the
> flag might actually be practically useful.

Agreed. The way I /think/ it works is that on many SoCs there is a
system/last-level cache (LLC) which effectively sits in front of memory for
all masters. Even if a device isn't coherent with the CPU caches, we still
want to be able to allocate into the LLC. Why this doesn't happen
automatically is beyond me, but it appears that on these Qualcomm designs
you actually have to set the memory attributes up in the page-table to
ensure that the resulting memory transactions are non-cacheable for the CPU
but cacheable for the LLC. Without any changes, the transactions are
non-cacheable in both of them which assumedly has a performance cost.

But you can see that I'm piecing things together myself here. Isaac?

> > This is 
> > really just an extension of this patch that got mainlined, so that clients 
> > that use the DMA API can use IOMMU_QCOM_SYS_CACHE as well: 
> > https://patchwork.kernel.org/patch/10946099/
> >>  Any without a user in the same series it is a complete no-go anyway.
> > IOMMU_QCOM_SYS_CACHE does not have any current users in the mainline, nor 
> > did it have it in the patch series in which it got merged, yet it is still 
> > present? Furthermore, there are plans to upstream support for one of our 
> > SoCs that may benefit from this, as seen here: 
> > https://www.spinics.net/lists/iommu/msg39608.html.
> 
> Which means it should have never been merged.  As a general policy we do
> not add code to the Linux kernel without actual users.

Yes, in this case I was hoping a user would materialise via a different
tree, but it didn't happen, hence my post last week about removing this
altogether:

https://lore.kernel.org/linux-iommu/20191024153832.GA7966@jcrouse1-lnx.qualcomm.com/T/#t

which I suspect prompted this patch that unfortunately fails to solve the
problem.

Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Christoph Hellwig]

On Mon, Oct 28, 2019 at 11:24:58AM +0000, Will Deacon wrote:
> Agreed. The way I /think/ it works is that on many SoCs there is a
> system/last-level cache (LLC) which effectively sits in front of memory for
> all masters. Even if a device isn't coherent with the CPU caches, we still
> want to be able to allocate into the LLC. Why this doesn't happen
> automatically is beyond me, but it appears that on these Qualcomm designs
> you actually have to set the memory attributes up in the page-table to
> ensure that the resulting memory transactions are non-cacheable for the CPU
> but cacheable for the LLC. Without any changes, the transactions are
> non-cacheable in both of them which assumedly has a performance cost.
> 
> But you can see that I'm piecing things together myself here. Isaac?

If that is the case it sounds like we'd want to drive this through
DT properties, not the driver API.  But again, without an actual consumer
it pretty much is a moot point anyway.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Will Deacon]

On Mon, Oct 28, 2019 at 12:37:28PM +0100, Christoph Hellwig wrote:
> On Mon, Oct 28, 2019 at 11:24:58AM +0000, Will Deacon wrote:
> > Agreed. The way I /think/ it works is that on many SoCs there is a
> > system/last-level cache (LLC) which effectively sits in front of memory for
> > all masters. Even if a device isn't coherent with the CPU caches, we still
> > want to be able to allocate into the LLC. Why this doesn't happen
> > automatically is beyond me, but it appears that on these Qualcomm designs
> > you actually have to set the memory attributes up in the page-table to
> > ensure that the resulting memory transactions are non-cacheable for the CPU
> > but cacheable for the LLC. Without any changes, the transactions are
> > non-cacheable in both of them which assumedly has a performance cost.
> > 
> > But you can see that I'm piecing things together myself here. Isaac?
> 
> If that is the case it sounds like we'd want to drive this through
> DT properties, not the driver API.  But again, without an actual consumer
> it pretty much is a moot point anyway.

I think there's certainly a DT aspect to it so that the driver knows that
the SoC is hooked up this way, but I agree that we need a consumer so that
we can figure out how dynamic this needs to be. If it's just a
fire-and-forget thing then it needn't escape the IOMMU layer, but I fear
that it's probably more flexible than that.

If nothing shows up for 5.6, I'll send a patch to remove it (since Jordan
said there was something coming soon [1])

Will

[1] http://lkml.kernel.org/r/20191024153832.GA7966@jcrouse1-lnx.qualcomm.com
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Robin Murphy]

On 28/10/2019 11:24, Will Deacon wrote:
> Hi Christoph,
> 
> On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
>> On Sat, Oct 26, 2019 at 03:12:57AM -0700, isaacm@codeaurora.org wrote:
>>> On 2019-10-25 22:30, Christoph Hellwig wrote:
>>>> The definition makes very little sense.
>>> Can you please clarify what part doesn’t make sense, and why?
>>
>> It looks like complete garbage to me.  That might just be because it
>> uses tons of terms I've never heard of of and which aren't used anywhere
>> in the DMA API.  It also might be because it doesn't explain how the
>> flag might actually be practically useful.
> 
> Agreed. The way I /think/ it works is that on many SoCs there is a
> system/last-level cache (LLC) which effectively sits in front of memory for
> all masters. Even if a device isn't coherent with the CPU caches, we still
> want to be able to allocate into the LLC. Why this doesn't happen
> automatically is beyond me, but it appears that on these Qualcomm designs
> you actually have to set the memory attributes up in the page-table to
> ensure that the resulting memory transactions are non-cacheable for the CPU
> but cacheable for the LLC. Without any changes, the transactions are
> non-cacheable in both of them which assumedly has a performance cost.
> 
> But you can see that I'm piecing things together myself here. Isaac?

FWIW, that's pretty much how Pratik and Jordan explained it to me - the 
LLC sits directly in front of memory and is more or less transparent, 
although it might treat CPU and device accesses slightly differently (I 
don't remember exactly how the inner cacheablility attribute interacts). 
Certain devices don't get much benefit from the LLC, hence the desire 
for finer-grained control of their outer allocation policy to avoid more 
thrashing than necessary. Furthermore, for stuff in the 
video/GPU/display area certain jobs benefit more than others, hence the 
desire to go even finer-grained than a per-device control in order to 
maximise LLC effectiveness.

Robin.

>>> This is
>>> really just an extension of this patch that got mainlined, so that clients
>>> that use the DMA API can use IOMMU_QCOM_SYS_CACHE as well:
>>> https://patchwork.kernel.org/patch/10946099/
>>>>   Any without a user in the same series it is a complete no-go anyway.
>>> IOMMU_QCOM_SYS_CACHE does not have any current users in the mainline, nor
>>> did it have it in the patch series in which it got merged, yet it is still
>>> present? Furthermore, there are plans to upstream support for one of our
>>> SoCs that may benefit from this, as seen here:
>>> https://www.spinics.net/lists/iommu/msg39608.html.
>>
>> Which means it should have never been merged.  As a general policy we do
>> not add code to the Linux kernel without actual users.
> 
> Yes, in this case I was hoping a user would materialise via a different
> tree, but it didn't happen, hence my post last week about removing this
> altogether:
> 
> https://lore.kernel.org/linux-iommu/20191024153832.GA7966@jcrouse1-lnx.qualcomm.com/T/#t
> 
> which I suspect prompted this patch that unfortunately fails to solve the
> problem.
> 
> Will
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/dma: Add support for DMA_ATTR_SYS_CACHE

[Jordan Crouse]

On Mon, Oct 28, 2019 at 11:59:04AM +0000, Robin Murphy wrote:
> On 28/10/2019 11:24, Will Deacon wrote:
> >Hi Christoph,
> >
> >On Mon, Oct 28, 2019 at 08:41:56AM +0100, Christoph Hellwig wrote:
> >>On Sat, Oct 26, 2019 at 03:12:57AM -0700, isaacm@codeaurora.org wrote:
> >>>On 2019-10-25 22:30, Christoph Hellwig wrote:
> >>>>The definition makes very little sense.
> >>>Can you please clarify what part doesn’t make sense, and why?
> >>
> >>It looks like complete garbage to me.  That might just be because it
> >>uses tons of terms I've never heard of of and which aren't used anywhere
> >>in the DMA API.  It also might be because it doesn't explain how the
> >>flag might actually be practically useful.
> >
> >Agreed. The way I /think/ it works is that on many SoCs there is a
> >system/last-level cache (LLC) which effectively sits in front of memory for
> >all masters. Even if a device isn't coherent with the CPU caches, we still
> >want to be able to allocate into the LLC. Why this doesn't happen
> >automatically is beyond me, but it appears that on these Qualcomm designs
> >you actually have to set the memory attributes up in the page-table to
> >ensure that the resulting memory transactions are non-cacheable for the CPU
> >but cacheable for the LLC. Without any changes, the transactions are
> >non-cacheable in both of them which assumedly has a performance cost.
> >
> >But you can see that I'm piecing things together myself here. Isaac?
> 
> FWIW, that's pretty much how Pratik and Jordan explained it to me - the LLC
> sits directly in front of memory and is more or less transparent, although
> it might treat CPU and device accesses slightly differently (I don't
> remember exactly how the inner cacheablility attribute interacts). Certain
> devices don't get much benefit from the LLC, hence the desire for
> finer-grained control of their outer allocation policy to avoid more
> thrashing than necessary. Furthermore, for stuff in the video/GPU/display
> area certain jobs benefit more than others, hence the desire to go even
> finer-grained than a per-device control in order to maximise LLC
> effectiveness.

Robin's description is correct. And we did have a patch for an in-kernel user
but it got lost in the wash. I'm hoping Sharat can get a respin in time for 5.5.

https://lore.kernel.org/linux-arm-msm/1538744915-25490-8-git-send-email-smasetty@codeaurora.org/

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu