RE: [PATCH 4/6] Add multi mport support.
Hi, Matt, So glad to see you again! > -Original Message- > From: Matt Porter [mailto:[EMAIL PROTECTED] > On Thu, Jan 31, 2008 at 02:30:13PM +0800, Zhang Wei wrote: > > > -Original Message- > > > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > > when we have multiple ports are the device IDs on the > ports intended > > > to be unique only to a port or unique across all ports? > > > > > I consider each RIO controller will has its own network, > the device IDs > > should be > > unique only in its port network. > > This is a bad assumption IMHO. It pushes policy on to the system > designer of a RapidIO network. I know it is a real bad assumption. However, the RIO initial ID is only transported to driver by kernel parameter "riohdid", which can not distinguish the multi rio controllers. It may be more better add a "rio-id" property in RIO dts node, but the u-boot need some changes to support the rio-id assignment. Cheers! Wei. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
Hi, Matt, So glad to see you again! -Original Message- From: Matt Porter [mailto:[EMAIL PROTECTED] On Thu, Jan 31, 2008 at 02:30:13PM +0800, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] when we have multiple ports are the device IDs on the ports intended to be unique only to a port or unique across all ports? I consider each RIO controller will has its own network, the device IDs should be unique only in its port network. This is a bad assumption IMHO. It pushes policy on to the system designer of a RapidIO network. I know it is a real bad assumption. However, the RIO initial ID is only transported to driver by kernel parameter riohdid, which can not distinguish the multi rio controllers. It may be more better add a rio-id property in RIO dts node, but the u-boot need some changes to support the rio-id assignment. Cheers! Wei. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Thu, Jan 31, 2008 at 02:30:13PM +0800, Zhang Wei wrote: > > -Original Message- > > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > when we have multiple ports are the device IDs on the ports intended > > to be unique only to a port or unique across all ports? > > > I consider each RIO controller will has its own network, the device IDs > should be > unique only in its port network. This is a bad assumption IMHO. It pushes policy on to the system designer of a RapidIO network. It is very possible to use multiple controllers as entry points in a single RapidIO network fabric space. The reason one would do this is to provide optimized paths to some endpoints in the system. If possible, there should never be a policy assumption like this in kernel space. It's much better to assume that one may or may not have a unique id space. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Thu, Jan 31, 2008 at 01:57:25PM +0800, Zhang Wei wrote: > > > > -Original Message- > > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > > > On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: > > > > > Change lots of static variable to mport private. And add > > mport to some > > > function declaration. > > > > Can you explain this patch further. Its not clear exactly from this > > commit message why we are doing this. > > > > - k > > Sorry about I have a little hurry about it. > > The original RapidIO driver suppose there is only one mpc85xx RIO > controller > in system. So, some data structures are defined as mpc85xx_rio global, > such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to > mport's private members. And you can define multi RIO OF-nodes in dts > file > for multi RapidIO controller in one processor, such as PCI/PCI-Ex host > controllers > in Freescale's silicon. And the mport operation function declaration > should be changed > to know which RapidIO controller is target. Right, the RapidIO subsystem itself has had the concept of multiple master ports from the beginning. However, when I did the MPC85xx support I chose to just implement it for the known silicon available at the time. I'm not surprised there's new silicon with multiple controllers now. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Thu, Jan 31, 2008 at 01:57:25PM +0800, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. Right, the RapidIO subsystem itself has had the concept of multiple master ports from the beginning. However, when I did the MPC85xx support I chose to just implement it for the known silicon available at the time. I'm not surprised there's new silicon with multiple controllers now. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Thu, Jan 31, 2008 at 02:30:13PM +0800, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] when we have multiple ports are the device IDs on the ports intended to be unique only to a port or unique across all ports? I consider each RIO controller will has its own network, the device IDs should be unique only in its port network. This is a bad assumption IMHO. It pushes policy on to the system designer of a RapidIO network. It is very possible to use multiple controllers as entry points in a single RapidIO network fabric space. The reason one would do this is to provide optimized paths to some endpoints in the system. If possible, there should never be a policy assumption like this in kernel space. It's much better to assume that one may or may not have a unique id space. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
Hi, Phil, > -Original Message- > From: Phil Terry [mailto:[EMAIL PROTECTED] > > On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: > > > > > > > > I consider each RIO controller will has its own network, > the device IDs > > should be > > unique only in its port network. > Hmmm, I see two cases: Good questions! They are very important and also my concern now. > > 1. I have two mport to two controllers each connected to different > physical fabrics. This system can act as an application bridge between > the two fabrics. > The current driver just looks two mport as two independent fabrics. We can add bridge driver to implement your idea. > 2. I have two mports to two controllers each connected directly or > indirectly to the same fabric. I want to use the extra bandwidth and > load balance and/or have a fall back redundant connection via an > alternate physical connection to the fabric etc. > That's a terrible thing in the current driver. Two mports get the same ID in one fabric. About the port bound, it's a good idea, I also need a new driver to support it. In fact, our first mission is to make the RapidIO driver ported from ppc to powerpc can be compiled and run. Fortunately, there is no more than one port in processor now, we have time to implement it. > What should be the rules for allocating the initial IDs to the two > mports to allow system wide enumeration to work in both of the above > cases? > A choice is add ID option into dts node. I have some ideas about RapidIO driver in u-boot. U-boot can assign ID in dts and tell kernel. > What do you expect the semantics of higher level addressing to be: > a pair , where is a different device from , > a pair , where is the same device as ,or > a singleton n, where n is unique and identifies the first > routing step > of which controller, x or y, to use. It seems the address pair is a must-be selection as pci bus. But now, no connection between ports. Every operations in only in its own port view. > I smell a can of worms :-) A good nose! Thanks! :) Cheers! Wei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: > > > -Original Message- > > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > > > On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: > > > > > > > > On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: > > > > > >> > > >> > > >>> -Original Message- > > >>> From: Kumar Gala [mailto:[EMAIL PROTECTED] > > >>> > > >>> On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: > > >>> > > Change lots of static variable to mport private. And add > > >>> mport to some > > function declaration. > > >>> > > >>> Can you explain this patch further. Its not clear > > exactly from this > > >>> commit message why we are doing this. > > >>> > > >>> - k > > >> > > >> Sorry about I have a little hurry about it. > > >> > > >> The original RapidIO driver suppose there is only one mpc85xx RIO > > >> controller > > >> in system. So, some data structures are defined as mpc85xx_rio > > >> global, > > >> such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I > > changed them > > >> to > > >> mport's private members. And you can define multi RIO > > OF-nodes in dts > > >> file > > >> for multi RapidIO controller in one processor, such as PCI/PCI-Ex > > >> host > > >> controllers > > >> in Freescale's silicon. And the mport operation function > > declaration > > >> should be changed > > >> to know which RapidIO controller is target. > > > > > > thanks, this makes a lot of sense and now reviewing the patch will > > > make some sense to me :) > > > > when we have multiple ports are the device IDs on the ports intended > > to be unique only to a port or unique across all ports? > > > I consider each RIO controller will has its own network, the device IDs > should be > unique only in its port network. Hmmm, I see two cases: 1. I have two mport to two controllers each connected to different physical fabrics. This system can act as an application bridge between the two fabrics. 2. I have two mports to two controllers each connected directly or indirectly to the same fabric. I want to use the extra bandwidth and load balance and/or have a fall back redundant connection via an alternate physical connection to the fabric etc. What should be the rules for allocating the initial IDs to the two mports to allow system wide enumeration to work in both of the above cases? What do you expect the semantics of higher level addressing to be: a pair , where is a different device from , a pair , where is the same device as ,or a singleton n, where n is unique and identifies the first routing step of which controller, x or y, to use. I smell a can of worms :-) Cheers Phil > > Cheers! > Wei > ___ > Linuxppc-dev mailing list > [EMAIL PROTECTED] > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. thanks, this makes a lot of sense and now reviewing the patch will make some sense to me :) when we have multiple ports are the device IDs on the ports intended to be unique only to a port or unique across all ports? I consider each RIO controller will has its own network, the device IDs should be unique only in its port network. Hmmm, I see two cases: 1. I have two mport to two controllers each connected to different physical fabrics. This system can act as an application bridge between the two fabrics. 2. I have two mports to two controllers each connected directly or indirectly to the same fabric. I want to use the extra bandwidth and load balance and/or have a fall back redundant connection via an alternate physical connection to the fabric etc. What should be the rules for allocating the initial IDs to the two mports to allow system wide enumeration to work in both of the above cases? What do you expect the semantics of higher level addressing to be: a pair mport,id, where x,n is a different device from y,n, a pair mport,id, where x,n is the same device as y,n,or a singleton n, where n is unique and identifies the first routing step of which controller, x or y, to use. I smell a can of worms :-) Cheers Phil Cheers! Wei ___ Linuxppc-dev mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
Hi, Phil, -Original Message- From: Phil Terry [mailto:[EMAIL PROTECTED] On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote: I consider each RIO controller will has its own network, the device IDs should be unique only in its port network. Hmmm, I see two cases: Good questions! They are very important and also my concern now. 1. I have two mport to two controllers each connected to different physical fabrics. This system can act as an application bridge between the two fabrics. The current driver just looks two mport as two independent fabrics. We can add bridge driver to implement your idea. 2. I have two mports to two controllers each connected directly or indirectly to the same fabric. I want to use the extra bandwidth and load balance and/or have a fall back redundant connection via an alternate physical connection to the fabric etc. That's a terrible thing in the current driver. Two mports get the same ID in one fabric. About the port bound, it's a good idea, I also need a new driver to support it. In fact, our first mission is to make the RapidIO driver ported from ppc to powerpc can be compiled and run. Fortunately, there is no more than one port in processor now, we have time to implement it. What should be the rules for allocating the initial IDs to the two mports to allow system wide enumeration to work in both of the above cases? A choice is add ID option into dts node. I have some ideas about RapidIO driver in u-boot. U-boot can assign ID in dts and tell kernel. What do you expect the semantics of higher level addressing to be: a pair mport,id, where x,n is a different device from y,n, a pair mport,id, where x,n is the same device as y,n,or a singleton n, where n is unique and identifies the first routing step of which controller, x or y, to use. It seems the address pair is a must-be selection as pci bus. But now, no connection between ports. Every operations in only in its own port view. I smell a can of worms :-) A good nose! Thanks! :) Cheers! Wei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: > > > > > On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: > > > >> > >> > >>> -Original Message- > >>> From: Kumar Gala [mailto:[EMAIL PROTECTED] > >>> > >>> On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: > >>> > Change lots of static variable to mport private. And add > >>> mport to some > function declaration. > >>> > >>> Can you explain this patch further. Its not clear > exactly from this > >>> commit message why we are doing this. > >>> > >>> - k > >> > >> Sorry about I have a little hurry about it. > >> > >> The original RapidIO driver suppose there is only one mpc85xx RIO > >> controller > >> in system. So, some data structures are defined as mpc85xx_rio > >> global, > >> such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I > changed them > >> to > >> mport's private members. And you can define multi RIO > OF-nodes in dts > >> file > >> for multi RapidIO controller in one processor, such as PCI/PCI-Ex > >> host > >> controllers > >> in Freescale's silicon. And the mport operation function > declaration > >> should be changed > >> to know which RapidIO controller is target. > > > > thanks, this makes a lot of sense and now reviewing the patch will > > make some sense to me :) > > when we have multiple ports are the device IDs on the ports intended > to be unique only to a port or unique across all ports? > I consider each RIO controller will has its own network, the device IDs should be unique only in its port network. Cheers! Wei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. thanks, this makes a lot of sense and now reviewing the patch will make some sense to me :) when we have multiple ports are the device IDs on the ports intended to be unique only to a port or unique across all ports? - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. thanks, this makes a lot of sense and now reviewing the patch will make some sense to me :) - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
> -Original Message- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > > On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: > > > Change lots of static variable to mport private. And add > mport to some > > function declaration. > > Can you explain this patch further. Its not clear exactly from this > commit message why we are doing this. > > - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. Thanks! Wei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] Add multi mport support.
Change lots of static variable to mport private. And add mport to some
function declaration.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_rio.c | 353 +++--
drivers/rapidio/rio-access.c | 10 +-
include/linux/rio.h | 18 ++-
3 files changed, 218 insertions(+), 163 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 36c4be4..3907a2c 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1,6 +1,9 @@
/*
* Freescale MPC85xx/MPC86xx RapidIO support
*
+ * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Zhang Wei <[EMAIL PROTECTED]>
+ *
* Copyright 2005 MontaVista Software, Inc.
* Matt Porter <[EMAIL PROTECTED]>
*
@@ -20,6 +23,11 @@
#include
+/* RapidIO definition irq, which read from OF-tree */
+#define IRQ_RIO_BELL(m)(((struct rio_priv
*)(m->priv))->bellirq)
+#define IRQ_RIO_TX(m) (((struct rio_priv *)(m->priv))->txirq)
+#define IRQ_RIO_RX(m) (((struct rio_priv *)(m->priv))->rxirq)
+
#define RIO_REGS_BASE (CCSRBAR + 0xc)
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_MSG_REGS_OFFSET0x11000
@@ -112,20 +120,12 @@ struct rio_tx_desc {
u32 res4;
};
-static u32 regs_win;
-static struct rio_atmu_regs *atmu_regs;
-static struct rio_atmu_regs *maint_atmu_regs;
-static struct rio_atmu_regs *dbell_atmu_regs;
-static u32 dbell_win;
-static u32 maint_win;
-static struct rio_msg_regs *msg_regs;
-
-static struct rio_dbell_ring {
+struct rio_dbell_ring {
void *virt;
dma_addr_t phys;
-} dbell_ring;
+};
-static struct rio_msg_tx_ring {
+struct rio_msg_tx_ring {
void *virt;
dma_addr_t phys;
void *virt_buffer[RIO_MAX_TX_RING_SIZE];
@@ -133,16 +133,32 @@ static struct rio_msg_tx_ring {
int tx_slot;
int size;
void *dev_id;
-} msg_tx_ring;
+};
-static struct rio_msg_rx_ring {
+struct rio_msg_rx_ring {
void *virt;
dma_addr_t phys;
void *virt_buffer[RIO_MAX_RX_RING_SIZE];
int rx_slot;
int size;
void *dev_id;
-} msg_rx_ring;
+};
+
+struct rio_priv {
+ void __iomem *regs_win;
+ struct rio_atmu_regs __iomem *atmu_regs;
+ struct rio_atmu_regs __iomem *maint_atmu_regs;
+ struct rio_atmu_regs __iomem *dbell_atmu_regs;
+ void __iomem *dbell_win;
+ void __iomem *maint_win;
+ struct rio_msg_regs __iomem *msg_regs;
+ struct rio_dbell_ring dbell_ring;
+ struct rio_msg_tx_ring msg_tx_ring;
+ struct rio_msg_rx_ring msg_rx_ring;
+ int bellirq;
+ int txirq;
+ int rxirq;
+};
/**
* fsl_rio_doorbell_send - Send a MPC85xx doorbell message
@@ -153,12 +169,14 @@ static struct rio_msg_rx_ring {
* Sends a MPC85xx doorbell message. Returns %0 on success or
* %-EINVAL on failure.
*/
-static int fsl_rio_doorbell_send(int index, u16 destid, u16 data)
+static int fsl_rio_doorbell_send(struct rio_mport *mport,
+ int index, u16 destid, u16 data)
{
+ struct rio_priv *priv = mport->priv;
pr_debug("fsl_doorbell_send: index %d destid %4.4x data %4.4x\n",
index, destid, data);
- out_be32((void *)_atmu_regs->rowtar, destid << 22);
- out_be16((void *)(dbell_win), data);
+ out_be32(>dbell_atmu_regs->rowtar, destid << 22);
+ out_be16(priv->dbell_win, data);
return 0;
}
@@ -173,11 +191,13 @@ static int fsl_rio_doorbell_send(int index, u16 destid,
u16 data)
* Generates a MPC85xx local configuration space read. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int fsl_local_config_read(int index, u32 offset, int len, u32 * data)
+static int fsl_local_config_read(struct rio_mport *mport,
+ int index, u32 offset, int len, u32 * data)
{
+ struct rio_priv *priv = mport->priv;
pr_debug("fsl_local_config_read: index %d offset %8.8x\n", index,
offset);
- *data = in_be32((void *)(regs_win + offset));
+ *data = in_be32(priv->regs_win + offset);
return 0;
}
@@ -192,12 +212,14 @@ static int fsl_local_config_read(int index, u32 offset,
int len, u32 * data)
* Generates a MPC85xx local configuration space write. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int fsl_local_config_write(int index, u32 offset, int len, u32 data)
+static int fsl_local_config_write(struct rio_mport *mport,
+ int index, u32 offset, int len, u32 data)
{
+ struct rio_priv *priv = mport->priv;
pr_debug
("fsl_local_config_write: index %d offset %8.8x data %8.8x\n",
index, offset, data);
- out_be32((void *)(regs_win + offset), data);
+ out_be32(priv->regs_win + offset, data);
return 0;
}
@@ -215,18 +237,19 @@ static int fsl_local_config_write(int index, u32 offset,
[PATCH 4/6] Add multi mport support.
Change lots of static variable to mport private. And add mport to some
function declaration.
Signed-off-by: Zhang Wei [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_rio.c | 353 +++--
drivers/rapidio/rio-access.c | 10 +-
include/linux/rio.h | 18 ++-
3 files changed, 218 insertions(+), 163 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 36c4be4..3907a2c 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1,6 +1,9 @@
/*
* Freescale MPC85xx/MPC86xx RapidIO support
*
+ * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc.
+ * Zhang Wei [EMAIL PROTECTED]
+ *
* Copyright 2005 MontaVista Software, Inc.
* Matt Porter [EMAIL PROTECTED]
*
@@ -20,6 +23,11 @@
#include asm/io.h
+/* RapidIO definition irq, which read from OF-tree */
+#define IRQ_RIO_BELL(m)(((struct rio_priv
*)(m-priv))-bellirq)
+#define IRQ_RIO_TX(m) (((struct rio_priv *)(m-priv))-txirq)
+#define IRQ_RIO_RX(m) (((struct rio_priv *)(m-priv))-rxirq)
+
#define RIO_REGS_BASE (CCSRBAR + 0xc)
#define RIO_ATMU_REGS_OFFSET 0x10c00
#define RIO_MSG_REGS_OFFSET0x11000
@@ -112,20 +120,12 @@ struct rio_tx_desc {
u32 res4;
};
-static u32 regs_win;
-static struct rio_atmu_regs *atmu_regs;
-static struct rio_atmu_regs *maint_atmu_regs;
-static struct rio_atmu_regs *dbell_atmu_regs;
-static u32 dbell_win;
-static u32 maint_win;
-static struct rio_msg_regs *msg_regs;
-
-static struct rio_dbell_ring {
+struct rio_dbell_ring {
void *virt;
dma_addr_t phys;
-} dbell_ring;
+};
-static struct rio_msg_tx_ring {
+struct rio_msg_tx_ring {
void *virt;
dma_addr_t phys;
void *virt_buffer[RIO_MAX_TX_RING_SIZE];
@@ -133,16 +133,32 @@ static struct rio_msg_tx_ring {
int tx_slot;
int size;
void *dev_id;
-} msg_tx_ring;
+};
-static struct rio_msg_rx_ring {
+struct rio_msg_rx_ring {
void *virt;
dma_addr_t phys;
void *virt_buffer[RIO_MAX_RX_RING_SIZE];
int rx_slot;
int size;
void *dev_id;
-} msg_rx_ring;
+};
+
+struct rio_priv {
+ void __iomem *regs_win;
+ struct rio_atmu_regs __iomem *atmu_regs;
+ struct rio_atmu_regs __iomem *maint_atmu_regs;
+ struct rio_atmu_regs __iomem *dbell_atmu_regs;
+ void __iomem *dbell_win;
+ void __iomem *maint_win;
+ struct rio_msg_regs __iomem *msg_regs;
+ struct rio_dbell_ring dbell_ring;
+ struct rio_msg_tx_ring msg_tx_ring;
+ struct rio_msg_rx_ring msg_rx_ring;
+ int bellirq;
+ int txirq;
+ int rxirq;
+};
/**
* fsl_rio_doorbell_send - Send a MPC85xx doorbell message
@@ -153,12 +169,14 @@ static struct rio_msg_rx_ring {
* Sends a MPC85xx doorbell message. Returns %0 on success or
* %-EINVAL on failure.
*/
-static int fsl_rio_doorbell_send(int index, u16 destid, u16 data)
+static int fsl_rio_doorbell_send(struct rio_mport *mport,
+ int index, u16 destid, u16 data)
{
+ struct rio_priv *priv = mport-priv;
pr_debug(fsl_doorbell_send: index %d destid %4.4x data %4.4x\n,
index, destid, data);
- out_be32((void *)dbell_atmu_regs-rowtar, destid 22);
- out_be16((void *)(dbell_win), data);
+ out_be32(priv-dbell_atmu_regs-rowtar, destid 22);
+ out_be16(priv-dbell_win, data);
return 0;
}
@@ -173,11 +191,13 @@ static int fsl_rio_doorbell_send(int index, u16 destid,
u16 data)
* Generates a MPC85xx local configuration space read. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int fsl_local_config_read(int index, u32 offset, int len, u32 * data)
+static int fsl_local_config_read(struct rio_mport *mport,
+ int index, u32 offset, int len, u32 * data)
{
+ struct rio_priv *priv = mport-priv;
pr_debug(fsl_local_config_read: index %d offset %8.8x\n, index,
offset);
- *data = in_be32((void *)(regs_win + offset));
+ *data = in_be32(priv-regs_win + offset);
return 0;
}
@@ -192,12 +212,14 @@ static int fsl_local_config_read(int index, u32 offset,
int len, u32 * data)
* Generates a MPC85xx local configuration space write. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int fsl_local_config_write(int index, u32 offset, int len, u32 data)
+static int fsl_local_config_write(struct rio_mport *mport,
+ int index, u32 offset, int len, u32 data)
{
+ struct rio_priv *priv = mport-priv;
pr_debug
(fsl_local_config_write: index %d offset %8.8x data %8.8x\n,
index, offset, data);
- out_be32((void *)(regs_win + offset), data);
+ out_be32(priv-regs_win + offset, data);
return 0;
}
@@ -215,18 +237,19 @@ static int fsl_local_config_write(int index, u32 offset,
int len,
Re: [PATCH 4/6] Add multi mport support.
On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/6] Add multi mport support.
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. Thanks! Wei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. thanks, this makes a lot of sense and now reviewing the patch will make some sense to me :) - k -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] Add multi mport support.
On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote: On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote: Change lots of static variable to mport private. And add mport to some function declaration. Can you explain this patch further. Its not clear exactly from this commit message why we are doing this. - k Sorry about I have a little hurry about it. The original RapidIO driver suppose there is only one mpc85xx RIO controller in system. So, some data structures are defined as mpc85xx_rio global, such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I changed them to mport's private members. And you can define multi RIO OF-nodes in dts file for multi RapidIO controller in one processor, such as PCI/PCI-Ex host controllers in Freescale's silicon. And the mport operation function declaration should be changed to know which RapidIO controller is target. thanks, this makes a lot of sense and now reviewing the patch will make some sense to me :) when we have multiple ports are the device IDs on the ports intended to be unique only to a port or unique across all ports? - k -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
