Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Fri, Jun 12, 2009 at 9:58 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 12, 2009, at 8:27 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 9:32 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? But in my understanding the current dma_map_*() APIs are preparing local memory for device to access which is similar to the inbound case. Is it suitable to also use them for mapping device's space for CPU access? Can you give an example of using this API for Address Translation and Mapping purpose? Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses the dma_map_ layer as the way to do address translation. IOMMU case is not very similar to the RapidIO scenario. RapidIO mapping is more like PCI address space mapping. To be specific, the DMA API return dma_addr_t not the rapidIO address type. And they can only handle inbound mapping not both ways. I don't think the DMA API is competent enough to be used here for RIO mapping. Unless we have a more universal mapping API, it can be justified to create its own API. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Thu, Jun 11, 2009 at 9:32 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? But in my understanding the current dma_map_*() APIs are preparing local memory for device to access which is similar to the inbound case. Is it suitable to also use them for mapping device's space for CPU access? Can you give an example of using this API for Address Translation and Mapping purpose? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Jun 12, 2009, at 8:27 AM, Li Yang wrote: On Thu, Jun 11, 2009 at 9:32 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. Ok, I see your point now. Do you mean dma_map_*() for DMA API layer? But in my understanding the current dma_map_*() APIs are preparing local memory for device to access which is similar to the inbound case. Is it suitable to also use them for mapping device's space for CPU access? Can you give an example of using this API for Address Translation and Mapping purpose? Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses the dma_map_ layer as the way to do address translation. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote: On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. This is a separate RIO block level ATMU. Although it looks like the system level ATMU, system ATMU doesn't have the knowledge of rapidIO target device ID. The mapping need to be dynamic, as it's easy to have more RIO devices than the outbound windows. I understand that. What I'm saying is the RIO block level ATMU is a Freescale specific detail and not part of any standard RIO bus programming model. We have mapping APIs that we can connect to for this via the DMA API layer. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
On May 12, 2009, at 3:35 AM, Li Yang wrote: Add the mapping functions used to support direct IO memory access of rapidIO. Signed-off-by: Zhang Wei z...@zh-kernel.org Signed-off-by: Li Yang le...@freescale.com Use inbnd/outbnd instead of inb/outb which make one think of byte level io accessors. As I look at this I don't think this is the correct API. I think we should be using the DMA mapping API to hide these details. The concept of mapping like this seems to be more a function of FSL's Address translation/mapping unit (ATMU) than anything specific to the RIO bus standard. --- drivers/rapidio/rio.c | 95 ++ + include/linux/rio.h | 25 include/linux/rio_drv.h | 24 +--- 3 files changed, 138 insertions(+), 6 deletions(-) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
Add the mapping functions used to support direct IO memory access of
rapidIO.
Signed-off-by: Zhang Wei z...@zh-kernel.org
Signed-off-by: Li Yang le...@freescale.com
---
drivers/rapidio/rio.c | 95 +++
include/linux/rio.h | 25
include/linux/rio_drv.h | 24 +---
3 files changed, 138 insertions(+), 6 deletions(-)
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index 6395c78..224a076 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -2,6 +2,8 @@
* RapidIO interconnect services
* (RapidIO Interconnect Specification, http://www.rapidio.org)
*
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc.
+ *
* Copyright 2005 MontaVista Software, Inc.
* Matt Porter mpor...@kernel.crashing.org
*
@@ -24,11 +26,23 @@
#include linux/spinlock.h
#include linux/slab.h
#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/hardirq.h
#include rio.h
static LIST_HEAD(rio_mports);
+static DEFINE_SPINLOCK(rio_config_lock);
+
+struct resource rio_resource = {
+ .name = RapidIO GSM,
+ .start = 0,
+ .end= -1,
+ .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL(rio_resource);
+
/**
* rio_local_get_device_id - Get the base/extended device id for a port
* @port: RIO master port from which to get the deviceid
@@ -333,6 +347,87 @@ int rio_release_outb_dbell(struct rio_dev *rdev, struct
resource *res)
}
/**
+ * rio_map_inb_region -- Mapping inbound memory region.
+ * @mport: Master port.
+ * @mem: Memory struction for mapping.
+ * @rflags: Flags for mapping.
+ *
+ * Return: 0 -- Success.
+ *
+ * This function will create the mapping from rio space to local mem.
+ */
+int rio_map_inb_region(struct rio_mport *mport, struct resource *rio_res,
+ dma_addr_t local, u32 rflags)
+{
+ int rc = 0;
+ unsigned long flags;
+
+ if (!mport-mops)
+ return -1;
+ spin_lock_irqsave(rio_config_lock, flags);
+ rc = mport-mops-map_inb(mport, local, rio_res-start,
+ resource_size(rio_res), rflags);
+ spin_unlock_irqrestore(rio_config_lock, flags);
+ return rc;
+}
+
+/**
+ * rio_map_outb_region -- Mapping outbound memory region.
+ * @mport: Master port.
+ * @tid: Target RapidIO device id.
+ * @mem: Memory struction for mapping.
+ * @rflags: Flags for mapping.
+ *
+ * Return: 0 -- Success.
+ *
+ * This function will create the mapping from local iomem to rio space.
+ */
+int rio_map_outb_region(struct rio_mport *mport, u16 tid,
+ struct resource *rio_res, phys_addr_t lstart, u32 rflags)
+{
+ int rc = 0;
+ unsigned long flags;
+
+ if (!mport-mops)
+ return -1;
+ spin_lock_irqsave(rio_config_lock, flags);
+ rc = mport-mops-map_outb(mport, lstart, rio_res-start,
+ resource_size(rio_res), tid, rflags);
+ spin_unlock_irqrestore(rio_config_lock, flags);
+ return rc;
+}
+
+/**
+ * rio_unmap_inb_region -- Unmap the inbound memory region
+ * @mport: Master port
+ * @mem: Memory struction for unmapping.
+ */
+void rio_unmap_inb_region(struct rio_mport *mport, dma_addr_t lstart)
+{
+ unsigned long flags;
+ if (!mport-mops)
+ return;
+ spin_lock_irqsave(rio_config_lock, flags);
+ mport-mops-unmap_inb(mport, lstart);
+ spin_unlock_irqrestore(rio_config_lock, flags);
+}
+
+/**
+ * rio_unmap_outb_region -- Unmap the outbound memory region
+ * @mport: Master port
+ * @mem: Memory struction for unmapping.
+ */
+void rio_unmap_outb_region(struct rio_mport *mport, phys_addr_t lstart)
+{
+ unsigned long flags;
+ if (!mport-mops)
+ return;
+ spin_lock_irqsave(rio_config_lock, flags);
+ mport-mops-unmap_outb(mport, lstart);
+ spin_unlock_irqrestore(rio_config_lock, flags);
+}
+
+/**
* rio_mport_get_feature - query for devices' extended features
* @port: Master port to issue transaction
* @local: Indicate a local master port or remote device access
diff --git a/include/linux/rio.h b/include/linux/rio.h
index dc0c755..dd61538 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -176,6 +176,7 @@ struct rio_mport {
struct rio_msg outb_msg[RIO_MAX_MBOX];
int host_deviceid; /* Host device ID */
struct rio_ops *ops;/* maintenance transaction functions */
+ struct rio_mem_ops *mops; /* Memory functions */
unsigned char id; /* port ID, unique among all ports */
unsigned char index;/* port index, unique among all port
interfaces of the same type */
@@ -185,6 +186,7 @@ struct rio_mport {
*/
enum rio_phy_type phy_type; /* RapidIO phy type */
unsigned char name[40];
+ struct device *dev;
void *priv; /* Master port private data */
};
