Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Monday 07 July 2008, Michael Ellerman wrote: It turned out that the firmware sets up the south bridge to never set the 'S' bit on incoming transactions, which overrides the IOPTE_SO_RW bits, on all existing cell hardware. It seems strange to me that the southbridge is allowed to override the setting in the IOMMU page table, but if that's what the doc says .. That's what I thought at first as well, but it actually makes sense: If the bridge knows that a data packet has been reordered already by the originator or one of its own busses, there is no point in enforcing strong ordering at the IOMMU again. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Sunday 06 July 2008, Benjamin Herrenschmidt wrote: I need to look closely at what the various bridge settings are. Drivers do expect DMA requests from one device to stay in order, at least up to what's defined in the PCI spec, which is pretty much fully ordered unless those devices set the PCIe (or X) relaxed ordering attribute. However, AFAIK, Axon doesn't convey that sort of ordering attributes from incoming transactions between the PCIe segment and the PLB5. Yes, it would be very helpful if you can look into this a bit more. The Axon specification is particularly confusing in this regard and even though everyone I have asked so far told us that it's totally fine, an extra person with more insight in the complete picture looking into this would be good. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Sat, 2008-07-05 at 23:51 +0200, Arnd Bergmann wrote: On Saturday 05 July 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-07-05 at 15:43 +1000, Michael Ellerman wrote: The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs (for both the dynamic and fixed mappings) which enforces strong ordering of both reads and writes. This patch makes the default behaviour weak ordering (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the new DMA_ATTR_STRONG_ORDERING needs to be used. We're sure that's safe? I'd say it's not... It turned out that the firmware sets up the south bridge to never set the 'S' bit on incoming transactions, which overrides the IOPTE_SO_RW bits, on all existing cell hardware. It seems strange to me that the southbridge is allowed to override the setting in the IOMMU page table, but if that's what the doc says .. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Sat, 2008-07-05 at 15:43 +1000, Michael Ellerman wrote: The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs (for both the dynamic and fixed mappings) which enforces strong ordering of both reads and writes. This patch makes the default behaviour weak ordering (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the new DMA_ATTR_STRONG_ORDERING needs to be used. We're sure that's safe? I'd say it's not... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Saturday 05 July 2008, Benjamin Herrenschmidt wrote: On Sat, 2008-07-05 at 15:43 +1000, Michael Ellerman wrote: The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs (for both the dynamic and fixed mappings) which enforces strong ordering of both reads and writes. This patch makes the default behaviour weak ordering (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the new DMA_ATTR_STRONG_ORDERING needs to be used. We're sure that's safe? I'd say it's not... It turned out that the firmware sets up the south bridge to never set the 'S' bit on incoming transactions, which overrides the IOPTE_SO_RW bits, on all existing cell hardware. This weak ordering gives the same ordering guarantees as the default ordering for DMA on other PowerPC machines. Setting strong ordering on both the host bridge *and* the page table will give further ordering guarantees, i.e. it will make sure that no DMA requests on the bus can ever overtake each other. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Sat, 2008-07-05 at 23:51 +0200, Arnd Bergmann wrote: It turned out that the firmware sets up the south bridge to never set the 'S' bit on incoming transactions, which overrides the IOPTE_SO_RW bits, on all existing cell hardware. This weak ordering gives the same ordering guarantees as the default ordering for DMA on other PowerPC machines. Setting strong ordering on both the host bridge *and* the page table will give further ordering guarantees, i.e. it will make sure that no DMA requests on the bus can ever overtake each other I need to look closely at what the various bridge settings are. Drivers do expect DMA requests from one device to stay in order, at least up to what's defined in the PCI spec, which is pretty much fully ordered unless those devices set the PCIe (or X) relaxed ordering attribute. However, AFAIK, Axon doesn't convey that sort of ordering attributes from incoming transactions between the PCIe segment and the PLB5. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
Introduce a new dma attriblue DMA_ATTR_STRONG_ORDERING to use strong ordering
on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
implementation to use this.
The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs
(for both the dynamic and fixed mappings) which enforces strong ordering of
both reads and writes. This patch makes the default behaviour weak ordering
(the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the
new DMA_ATTR_STRONG_ORDERING needs to be used.
Dynamic mappings can be weakly or strongly ordered on an individual basis
but the fixed mapping is always weakly ordered.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
Documentation/DMA-attributes.txt| 12 +
arch/powerpc/platforms/cell/iommu.c | 93 ---
include/linux/dma-attrs.h |1 +
3 files changed, 99 insertions(+), 7 deletions(-)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 6d772f8..f2d2800 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -22,3 +22,15 @@ ready and available in memory. The DMA of the completion
indication
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
+
+DMA_ATTR_STRONG_ORDERING
+--
+
+DMA_ATTR_STRONG_ORDERING specifies that previous reads and writes are
+performed in the order in which they're received by the IOMMU; thus
+reads and writes may not pass each other.
+
+Platforms that are strongly ordered by default will ignore this new
+attribute but platforms that are weakly ordered by default should not
+ignore this new attribute. Instead, they should return an error if a
+strongly ordered mapping cannot be used when one is requested.
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 3b70784..7f6ed20 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -194,11 +194,13 @@ static void tce_build_cell(struct iommu_table *tbl, long
index, long npages,
const unsigned long prot = 0xc48;
base_pte =
((prot (52 + 4 * direction)) (IOPTE_PP_W | IOPTE_PP_R))
- | IOPTE_M | IOPTE_SO_RW | (window-ioid IOPTE_IOID_Mask);
+ | IOPTE_M | (window-ioid IOPTE_IOID_Mask);
#else
- base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW |
+ base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M |
(window-ioid IOPTE_IOID_Mask);
#endif
+ if (unlikely(dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs)))
+ base_pte |= IOPTE_SO_RW;
io_pte = (unsigned long *)tbl-it_base + (index - tbl-it_offset);
@@ -539,7 +541,6 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
static unsigned long dma_iommu_fixed_base;
-struct dma_mapping_ops dma_iommu_fixed_ops;
static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
@@ -563,6 +564,85 @@ static struct iommu_table *cell_get_iommu_table(struct
device *dev)
return window-table;
}
+static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ return dma_direct_ops.alloc_coherent(dev, size, dma_handle, flag);
+}
+
+static void dma_fixed_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle)
+{
+ dma_direct_ops.free_coherent(dev, size, vaddr, dma_handle);
+}
+
+static dma_addr_t dma_fixed_map_single(struct device *dev, void *ptr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs))
+ return iommu_map_single(dev, cell_get_iommu_table(dev), ptr,
+ size, device_to_mask(dev), direction,
+ attrs);
+ else
+ return dma_direct_ops.map_single(dev, ptr, size, direction,
+attrs);
+}
+
+static void dma_fixed_unmap_single(struct device *dev, dma_addr_t dma_addr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs))
+ iommu_unmap_single(cell_get_iommu_table(dev), dma_addr, size,
+ direction, attrs);
+ else
+ dma_direct_ops.unmap_single(dev, dma_addr, size, direction,
+ attrs);
+}
+
+static int
Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Fri, 2008-07-04 at 21:05 +0200, [EMAIL PROTECTED] wrote: Introduce a new dma attriblue DMA_ATTR_STRONG_ORDERING to use strong ordering on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU implementation to use this. The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs (for both the dynamic and fixed mappings) which enforces strong ordering of both reads and writes. This patch makes the default behaviour weak ordering (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the new DMA_ATTR_STRONG_ORDERING needs to be used. We're sure that's safe? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
