On Friday, June 13, 2014 7:09 AM Martijn de Gouw
[mailto:martijn.de.gouw@prodrive-
technologies.com] wrote:
Add support for mapping and unmapping of inbound rapidio windows.
Signed-off-by: Martijn de Gouw martijn.de.g...@prodrive.nl
---
... skip ...
+
+int fsl_map_inb_mem(struct
Hi Jean,
-Original Message-
From: Jean Delvare [mailto:jdelv...@suse.de]
Sent: Friday, July 26, 2013 7:01 AM
... skip
@@ -2246,11 +2246,11 @@ source drivers/pcmcia/Kconfig
source drivers/pci/hotplug/Kconfig
config RAPIDIO
- bool RapidIO support
+ tristate
On Fri, 26 Apr 2013 6:53 PM Andrew Morton a...@linux-foundation.org wrote:
Subject: Re: [PATCH 1/3] rapidio: make enumeration/discovery
configurable
This Kconfig change makes my kbuild do Weird Things.
make mrproper ; yes | make allmodconfig ; make 2/tmp/x
... skip ...
: DMA Engine
On Wednesday, April 24, 2013 5:37 PM Andrew Morton wrote:
On Wed, 24 Apr 2013 10:31:57 -0400 Alexandre Bounine
alexandre.boun...@idt.com wrote:
Rework to implement RapidIO enumeration/discovery method selection
combined with ability to use enumeration/discovery as a kernel module.
On Wed, October 03, 2012 6:20 PM
Andrew Morton a...@linux-foundation.org wrote:
On Wed, 3 Oct 2012 15:18:39 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Fix blocking wait loop in the RapidIO discovery routine to avoid
warning dumps about stalled CPU on x86 platforms.
...
On Wed, October 03, 2012 6:30 PM
Andrew Morton a...@linux-foundation.org wrote:
On Wed, 3 Oct 2012 15:18:41 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
...
+static void __devinit disc_work_handler(struct work_struct *_work)
+{
+ struct rio_disc_work *work =
On Wed, October 03, 2012 6:36 PM
Andrew Morton a...@linux-foundation.org wrote:
On Wed, 3 Oct 2012 15:18:43 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
...
+static u16 rio_destid_alloc(struct rio_net *net)
+{
+ int destid;
+ struct rio_id_table *idtab =
On Friday, August 24, 2012 5:04 PM
Andrew Morton a...@linux-foundation.org
On Tue, 21 Aug 2012 10:23:55 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Modify RIO enumeration to apply RX/TX enable operations only to
active switch ports. This will leave inactive ports in condition
On Friday, August 24, 2012 5:02 PM
Andrew Morton a...@linux-foundation.org
On Tue, 21 Aug 2012 10:23:54 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Modify mport device name assignment to provide clear reference to devices
in systems with multiple Tsi721 bridges.
This patch
to use one of the latest kernel versions.
Alex.
From: Saravanan S [mailto:sarans1...@gmail.com]
Sent: Saturday, July 14, 2012 2:25 AM
To: Bounine, Alexandre
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Standalone SRIO Driver for Linux
Hi ,
Thanks for the reply . i will try to share some
This should work. We use similar approach to test our mport HW drivers.
Alex.
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org] On
Behalf Of Saravanan S
Sent: Friday, July 13, 2012 2:16 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: Standalone SRIO
On Mon, March 05, 2012 9:58 PM, Liu Gang wrote:
Subject: [PATCH] powerpc/srio: Fix the relocation errors when building
with 64bit
For the file arch/powerpc/sysdev/fsl_rio.c, there will be some
relocation errors while using the corenet64_smp_defconfig:
WARNING: modpost: Found 6 section
On Mon, March 05, 2012 3:37 PM Andrew Morton wrote:
Alexandre Bounine alexandre.boun...@idt.com wrote:
Fixes queue wrapping bug in Inbound Doorbell handling routine.
The changelog doesn't describe the user-visible impact of the bug.
Please always include this so that people know whether
On Monday, January 30, 2012 at 4:31 AM, Vinod Koul wrote:
On Thu, 2012-01-26 at 16:22 -0500, Alexandre Bounine wrote:
As we agreed during our discussion about adding DMA Engine support for
RapidIO
subsystem, RapidIO and similar clients may benefit from adding an extra
context
On Monday, December 19, 2011 1:39 AM, Daniel Ng wrote:
Is there RapidIO Direct Memory I/O Support in the latest kernel?
I've seen these patches from Freescale, but it seems they were never
integrated-
http://kerneltrap.org/mailarchive/linux-netdev/2009/5/12/5686954
Does anyone know why these
: linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org on behalf
of Andrew Morton
Sent: Tue 12/6/2011 5:36 PM
To: Bounine, Alexandre
Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] rapidio/tsi721: Fix mailbox resource reporting
On Tue, 6 Dec 2011 14:01
-Original Message-
From: Liu Gang [mailto:gang@freescale.com]
Sent: Saturday, November 12, 2011 7:02 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
r58...@freescale.com; b11...@freescale.com; r61
-Original Message-
From: linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org
[mailto:linuxppc-dev-
bounces+alexandre.bounine=idt@lists.ozlabs.org] On Behalf Of Liu
Gang
Sent: Saturday, November 12, 2011 7:02 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
-Original Message-
From: Liu Gang [mailto:gang@freescale.com]
Sent: Saturday, November 12, 2011 7:03 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
r58...@freescale.com; b11...@freescale.com; r61
-Original Message-
From: Liu Gang [mailto:gang@freescale.com]
Sent: Saturday, November 12, 2011 7:03 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
r58...@freescale.com; b11...@freescale.com; r61
-Original Message-
From: Liu Gang [mailto:gang@freescale.com]
Sent: Saturday, November 12, 2011 7:03 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
r58...@freescale.com; b11...@freescale.com; r61
On Fri, Nov 11, 2011 at 8:48 AM Liu Gang gang@freescale.com wrote:
Sent: Friday, November 11, 2011 8:48 AM
To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
paul.gortma...@windriver.com; r58...@freescale.com;
b11
On Tue, Oct 25, 2011 at 6:40 AM, Liu Gang-B34182 b34...@freescale.com
wrote:
... skip ...
+
+ DBELL_TID(dmsg),
+ DBELL_INF(dmsg));
+ break;
+}
}
}
Do we need to check for matching DBELL_TID and mport destID here and
scan only doorbell list
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182 b34...@freescale.com
wrote:
From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
Sent: Thursday, October 20, 2011 3:54 AM
To: Kumar Gala; linuxppc-...@ozlabs.org
Cc: Andrew Morton; Liu Gang-B34182; linux-ker...@vger.kernel.org
Subject
On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
From: Liu Gang gang@freescale.com
Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
Serial
link interfaces, and rapidio message transactions can be implemented
by
two
Is the number of 1x ports described correctly?
On Sat, Oct 15, 2011 at 1:36 PM, Vinod Koul vinod.k...@intel.com wrote:
... skip ...
Second, having ability to pass private target information allows me to
pass
information about remote target device on per-transfer basis.
Okay, then why not pass the dma address and make
On Mon, Oct 17, 2011 at 11:53 AM, Jassi Brar
jaswinder.si...@linaro.org wrote:
On 15 October 2011 23:05, Vinod Koul vinod.k...@intel.com wrote:
Another alternate approach could be to add one more argument to
prep_slave_sg API which allows us to pass additional runtime
specific
On Mon, Oct 17, 2011 at 1:01 PM, Vinod Koul vinod.k...@intel.com wrote:
On Mon, 2011-10-17 at 21:22 +0530, Jassi Brar wrote:
On 15 October 2011 23:05, Vinod Koul vinod.k...@intel.com wrote:
Another alternate approach could be to add one more argument to
prep_slave_sg API which allows
Dan J Williams wrote:
On Mon, Oct 3, 2011 at 9:52 AM, Bounine, Alexandre
alexandre.boun...@idt.com wrote:
My concern here is that other subsystems may use/request DMA_SLAVE
channel(s) as well
and wrongfully acquire one that belongs to RapidIO. In this case
separation with another
flag
Vinod Koul wrote:
On Mon, 2011-10-03 at 09:52 -0700, Bounine, Alexandre wrote:
My concern here is that other subsystems may use/request DMA_SLAVE
channel(s) as well
and wrongfully acquire one that belongs to RapidIO. In this case separation
with another
flag may have a sense
Andrew Morton wrote:
On Mon, 3 Oct 2011 10:53:45 -0700
Bounine, Alexandre alexandre.boun...@idt.com wrote:
+ memset(bd_ptr, 0, bd_num * sizeof(struct
tsi721_dma_desc));
+
+ dev_dbg(dev, DMA descriptors @ %p (phys = %llx)\n,
+ bd_ptr, (unsigned long
Andrew Morton wrote:
No, it can be used all over the place:
drivers/net/irda/w83977af_ir.c,
drivers/scsi/bnx2fc/bnx2fc_tgt.c,
drivers/net/wireless/rt2x00/rt2x00pci.c,
drivers/crypto/amcc/crypto4xx_core.c and many nmore.
In this case I will happily use dma_zalloc_coherent() as
Vinod Koul wrote:
On Fri, 2011-09-30 at 17:38 -0400, Alexandre Bounine wrote:
Please CC *maintainers* on your patches, get_maintainers.pl will tell
you who. Adding Dan here
Based on https://lkml.org/lkml/2011/2/14/67 and use of DMA_SLAVE in this
patch I decided that you are the best match
Andrew Morton wroye:
On Fri, 30 Sep 2011 17:38:35 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Adds support for DMA Engine API.
Includes following changes:
- Modifies BDMA register offset definitions to support per-channel
handling
- Separates BDMA channel reserved for
Micha Nelissen wrote:
Alexandre Bounine wrote:
After the host has completed enumeration of the entire network it
releases
devices by clearing device ID locks (calls rio_clear_locks()). For
each endpoint
-in the system, it sets the Master Enable bit in the Port General
Control CSR
+in
On Thursday, September 01, 2011 5:52 AM
Liu Gang gang@freescale.com wrote:
Subject: [PATCH] fsl-rio: Release rapidio port I/O region resource if
portfailed to initialize
...
Signed-off-by: Liu Gang gang@freescale.com
---
arch/powerpc/sysdev/fsl_rio.c |1 +
1 files changed,
Andrew Morton a...@linux-foundation.org wrote:
On Tue, 26 Jul 2011 14:07:26 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Replace/remove use of RIO v.1.2 registers/bits that are not forward-
compatible
with newer versions of RapidIO specification.
RapidIO specification v.
Andrew Morton wrote:
On Fri, 12 Aug 2011 15:45:34 -0400
Alexandre Bounine alexandre.boun...@idt.com wrote:
Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge
device.
What a huge driver.
It is not over yet. We have plans to add more stuff later.
...
+config
On Monday, August 08, 2011 at 10:17 PM, Liu Gang wrote:
Subject: [PATCH] rio: Use discovered bit to test if enumeration is
complete
The discovered bit in PGCCSR register indicates if the device has
been discovered by system host. In Rapidio system, some agent devices
can also be master
-
bounces+alexandre.bounine=idt@lists.ozlabs.org] On Behalf Of Kumar
Gala
Sent: Friday, May 20, 2011 12:29 AM
To: Bounine, Alexandre
Cc: Li Yang-R58472; Xie Shaohui-B21989; Zang Roy-R61911; akpm@linux-
foundation.org; linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780
Subject: Re: [PATCH 2/2][v3
Not at all. I tested it earlier and it works for me on 8548 platform.
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Friday, May 20, 2011 8:42 AM
To: Bounine, Alexandre
Cc: Li Yang-R58472; Xie Shaohui-B21989; Zang Roy-R61911; akpm@linux-
foundation.org
Andrew Morton a...@linux-foundation.org wrote:
The changelog doesn't permit me to determine the importance of this
fix,
so I don't know whether to schedule it for 2.6.39 or for -stable.
Sorry, my fault. This patch is applicable to kernel versions starting
from 2.6.37.
18, 2011 4:49 PM
To: Bounine, Alexandre
Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; Matt Porter; Li Yang; Thomas Moll
Subject: Re: [PATCH -mm] RapidIO,powerpc/85xx: Fix configuration option
On Mar 18, 2011, at 12:18 PM, Alexandre Bounine wrote
Did you change anything in RIO initialization sequence?
For multiple mport support I had to adjust rio_init_mports/rio_init
sequence.
Alex.
-Original Message-
From: linuxppc-dev-bounces+alexandre.bounine=idt@lists.ozlabs.org
[mailto:linuxppc-dev-
Thomas Taranowski wrote:
I'm planning to add support for the multiple(2) mports supported by
the Freescale p2020 processor. I'm currently looking at the fsl layer
to add in support for multiple port enumeration, and work up from
there. It looks like the upper layers already have at least
Greg KH wrote:
Like Andrew pointed out, all sysfs files are required to have entries
in
Documentation/ABI. If the existing rapidio sysfs files are not
documented, please document them in there _before_ adding new ones.
I included RapidIO documentation update into my plan for next set of
Andrew Morton a...@linux-foundation.org wrote:
One would like to see documentation updates along with sysfs API
updates. But one fears that this entire interface wasn't documented
anyway :(
I think I have to find a time for that. I am adding it into my TODO
list.
Please at least fully
]
On Behalf Of Xie Shaohui-B21989
Sent: Thursday, December 02, 2010 10:29 PM
To: Bounine, Alexandre; linuxppc-dev@lists.ozlabs.org
Cc: a...@linux-foundation.org; Gala Kumar-B11780; Li Yang-R58472; Zang
Roy-R61911
Subject: RE: [PATCH 2/2][v3] rapidio,powerpc/85xx: Error interrupt
handler for sRIO.
Hi
Tested on my 8548/RIO setup - works as expected.
Alex.
-Original Message-
From: Shaohui Xie [mailto:b21...@freescale.com]
Sent: Thursday, November 18, 2010 1:58 AM
To: linuxppc-dev@lists.ozlabs.org
Cc: a...@linux-foundation.org; Shaohui Xie; Li Yang; Kumar Gala; Roy
Zang; Bounine
; Bounine, Alexandre
Subject: [PATCH 2/2][v3] rapidio, powerpc/85xx: Error interrupt
handler for sRIO.
The sRIO controller reports errors to the core with one signal, it
uses
register EPWISR to provides the core quick access to where the error
occurred.
The EPWISR indicates that there are 4
From: Xie Shaohui-B21989 [mailto:b21...@freescale.com]
Ok, I'll remove the ret, do you have any comment for the error handler
patch?
http://patchwork.ozlabs.org/patch/69962/
I will reply to the original patch message.
Alex.
___
Linuxppc-dev
From: Shaohui Xie [mailto:b21...@freescale.com]
The sRIO controller reports errors to the core with one signal, it
uses
register EPWISR to provides the core quick access to where the error
occurred.
The EPWISR indicates that there are 4 interrupts sources, port1,
port2, message
unit and
Shaohui Xie b21...@freescale.com wrote:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..9ab7b97 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include asm/kexec.h
#include asm/ppc-opcode.h
Kumar Gala ga...@kernel.crashing.org wrote:
[Xie Shaohui-B21989] Hi Alex, seems your suggestion is some kind of
conflict with Kumar, you can have a look at
http://patchwork.ozlabs.org/patch/67774/
I think Alex's comment is the fact we ignore the 'return' value in the
machine_check_e500
Kumar Gala kumar.g...@freescale.com wrote:
@@ -527,8 +535,12 @@ int machine_check_e500(struct pt_regs *regs)
To deal w/Alex's comment do:
machine_check_e500(...) {
int ret = 0;
printk(Bus - Write Address Error\n);
if (reason MCSR_BUS_IBERR)
Shaohui Xie b21...@freescale.com wrote:
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a45a63c..2a5fb9d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -55,6 +55,7 @@
#endif
#include asm/kexec.h
#include asm/ppc-opcode.h
Thomas Taranowski wrote:
Is there an official maintainer's repository for RapidIO related
changes to I should be tracking? I've been tracking Kumar's git
repository (off kernel.org), but I'm not clear on who the keeper of
this stuff is.
Currently Andrew Morton's -mm tree has most of RapidIO
Thomas Taranowski wrote:
Going through the code, it looks like the rapidio driver assumes
there's only going to be a single Port implemented.
Yes, this is true for the current implementation.
On the newer QorIQ P2020 processors there are 2 sets of port
registers, so the current code lays the
Thomas Taranowski wrote:
Yes, I tried pretty much all combinations of boot order, but I believe
the preferred approach is to boot the agents first, then the host
according to my freescale documentation. My problem was that all
three devices had the same device id. Once I programmed them with
Micha Nelissen mi...@neli.hopto.org wrote:
Bounine, Alexandre wrote:
In the current fsl_rio implementation initialization enables
ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I
think
you
Micha Nelissen mi...@neli.hopto.org wrote:
I look at it this way: it prevents the need for another layer of
indirection: translating component tag to a destid.
The destid alone is not enough. You will need an entire rio_dev object
for that device anyway.
Why no relation? My experience is
Micha Nelissen mi...@neli.hopto.org wrote:
In various parts of the enumeration and routing algorithm, it would
need
to lookup the tag to find the destid, if the destid is in the tag then
this lookup is not needed.
Let's keep this discussion within limits of the current implementation.
Micha Nelissen mi...@neli.hopto.org wrote:
Bounine, Alexandre wrote:
If we will need to identify the same physical switch by different
processors we may use the component tag which now is unique for
every
device.
Yes, identification is the point. I think it might be confusing to
have
Micha Nelissen mi...@neli.hopto.org wrote:
Bounine, Alexandre wrote:
1. The destid for the switch needs an additional mechanism to share
it
among processors in the RIO network,
? See comment for 2)
2. It takes ID value away from the pool of available IDs, what will
It does
Micha Nelissen mi...@neli.hopto.org wrote:
Alexandre Bounine wrote:
1. Using one storage location common for switches and endpoints
eliminates
unnecessary device type checks during maintenance access operations.
While destination IDs and hop counts have different meaning for
endpoints and
Micha Nelissen mi...@neli.hopto.org wrote:
Bounine, Alexandre wrote:
Looks like I formulated it bad - better would be: they have
different
interpretation by hardware but logically in RapidIO they have single
role - destid/hopcount are a device coordinates in the RIO network
used
Bastiaan Nijkamp wrote:
Has the driver ever been tested/used without a switch attached? Because when
the host (which has ID 0x0) enumerates the other board it also assigns ID 0x0
to the agent, it seems that the agent should have been assigned 0x1 as ID.
How the host ID is set on your host
Bastiaan Nijkamp bastiaan.nijk...@gmail.com wrote:
How the host ID is set on your host board?
Normally rio_enum_host() should increment next_destid in your case.
The hostID is set to 0x0 with the riohdid parameter as boot argument.
In this case I would expect to see ID=1 assigned to the
Hi Bastiaan,
Bastiaan Nijkamp bastiaan.nijk...@gmail.com wrote:
fsl-of-rio e00c.rapidio: LAW start 0xc000, RIO
Maintainance Window Size 0x40,New Main Start: 0xd108
RIO: enumerate master port 0, RIO0 mport
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset
Bastiaan Nijkamp bastiaan.nijk...@gmail.com wrote:
A interesting thing that i found out is that when the agent is reset while the
host is locked up (eg. it cannot be stopped nor can i read the registers and
memory trough a JTAG Interface), the host comes back online and just
continues
Andrew Morton a...@linux-foundation.org wrote:
@@ -219,6 +219,7 @@ struct rio_net {
/**
* struct rio_switch - RIO switch info
* @node: Node in global list of switches
+ * @rdev: Associated RIO device structure
* @switchid: Switch ID that is unique across a network
*
Andrew Morton a...@linux-foundation.org wrote:
The variable length array at the end of the struct thing is pretty
commonly used and works well. As long as we never want to change the
number of switches on the fly (hotplug?).
This is expected to be a strange array - its size can be 0 or 1
Andrew Morton a...@linux-foundation.org wrote:
This is also a non-back compatible userspace-visible change?
This should be a safe change because endpoints do not have a routing
table.
RapidIO differentiates devices by using naming templates for switches
and endpoints (:s: and :e:) and this
Andrew Morton a...@linux-foundation.org wrote:
Non-backward compatible change? What is the risk of breaking existing
setups with this change?
I think that risk is very low. Assuming that this change brings sysfs
entries
to their intended hierarchy, it has sense to do it now (at relatively
Andrew Morton a...@linux-foundation.org wrote:
The handling of `table' is strange. One would expect the caller of
this function to provide the correct table index, and for the caller
to
increment that index at an appropriate time.
Handling of the 'table' parameter is hardware-dependent.
RIO
Micha Nelissen wrote:
Perhaps an idea is to use the repeated port-write sending feature so
that dropped port-writes are not a problem anymore.
Unfortunately, this feature is not defined by RIO spec. This is
proprietary function, so we
cannot rely on it. Yes, this is nice feature of Tsi57x
Micha Nelissen wrote:
Primarily due to the single entry queue, the order of checking is
probably insignificant? :-)
Help sometimes only but gives a feeling that I did all that is possible
;)
Anyway, I don't mind changing the order.
Micha
___
Micha Nelissen wrote:
It's not problematic, but personally I find function calls that pass 0
or 1 as an argument hard to read. Likewise for boolean parameters. An
alternative would be to have defines SW_SYSFS_CREATE etc. It's a minor
item.
I will add defines.
Micha Nelissen wrote:
I agree it's desirable to have this information. Notes:
1) is rio_dev-prev used anywhere? (maybe I missed it)
It is used to scan route back when servicing an orphaned PW message.
I also see its future use when invalidating route(s) in case of device
removal.
2) is
Micha Nelissen wrote:
Can you explain what the difference what you mean with relied on
proprietary vs standard? E.g. setting the port-write destination ID
register is standardized? And the format of the port-write message
itself is also.
The original description should use error-stopped
Micha Nelissen wrote:
Alexandre Bounine wrote:
A switch ingress port number has to be saved for software assisted
error
recovery from the error-stopped state. Saving this information also
allows
to remove several register reads from the RIO enumeration process.
Why not keep using the
Micha Nelissen wrote:
Alexandre Bounine wrote:
Create back and forward links between RIO devices. These links are
intended for
use by error management and hot-plug extensions.
As RapidIO is a switched network, the concept of 'previous' and 'next'
devices is invalid. Perhaps it's just
Micha Nelissen wrote:
Alexandre Bounine wrote:
+
+ if (err_status RIO_PORT_N_ERR_STS_PW_OUT_ES) {
+ pr_debug(RIO_EM: servicing Output Error-Stopped
state\n);
+ /*
+* Send a Link-Request/Input-Status control symbol
+*/
+
+
Micha Nelissen wrote:
Alexandre Bounine wrote:
- Rearranged RIO port-write interrupt handling to perform message
buffering
as soon as possible.
I don't understand this comment: you still schedule work to read the
port-write queue; so how is this message buffering performed as soon
as
Micha Nelissen wrote:
Alexandre Bounine wrote:
- if (!rdev-rswitch)
- goto out;
-
Is it safe? All devices have a switch?
Yes. Because end-points should not have the routes attribute at all
(corrected by this patch).
@@ -63,10 +59,11 @@ struct device_attribute
Micha Nelissen wrote:
Alexandre Bounine wrote:
Add check if PW message source device is accessible and change PW
message
handler to recover if PW message source device is not available
anymore (power
down or link disconnect).
I am not quite sure what the point is of this patch. What do
Micha Nelissen wrote:
Alexandre Bounine wrote:
+ rio_mport_write_config_32(mport, destid, hopcount,
+ LOCAL_RTE_CONF_DESTID_SEL, table);
+
+ for (i = 0x8000; i = 0x80ff;) {
+ rio_mport_write_config_32(mport, destid, hopcount,
+
the patch series quickly as currently there is a compile
error when SRIO is enabled.
- Leo
-Original Message-
From: Michael Neuling [mailto:mi...@neuling.org]
Sent: Wednesday, August 04, 2010 11:34 PM
To: Bounine, Alexandre
Cc: Timur Tabi; Alexandre Bounine; linuxppc-dev
I'm looking at this now and wondering what we added the mcheck handler
for in the first place and what
its trying to accomplish.
- k
This protects system from hanging if RIO link fails or enters error
state. In some situations following maintenance read may initiate link
recovery from error
This happened after change to book-e definitions.
There are patches that address this issue.
-Original Message-
From: Michael Neuling [mailto:mi...@neuling.org]
Sent: Tuesday, August 03, 2010 2:07 AM
To: Timur Tabi
Cc: Alexandre Bounine; linuxppc-dev@lists.ozlabs.org;
Andrew Morton wrote:
On Tue, 6 Apr 2010 17:22:38 -0400 Alexandre Bounine
aboun...@tundra.com wrote:
From: Alexandre Bounine alexandre.boun...@idt.com
Add RapidIO Port-Write message handling in the context
of Error Management Extensions Specification Rev.1.3.
...
+static struct
Micha Nelissen wrote:
Bounine, Alexandre wrote:
Micha Nelissen wrote:
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a
particular
vendor switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the
vid
Micha Nelissen wrote:
Alexandre Bounine wrote:
@@ -369,6 +380,10 @@ static struct rio_dev __devinit *rio_set
rdev-rswitch-switchid);
rio_route_set_ops(rdev);
+ if (do_enum rdev-rswitch-clr_table)
+
Micha Nelissen wrote:
Alexandre Bounine wrote:
+ /* Attempt to acquire device lock */
+ rio_mport_write_config_32(port, destid,
+ hopcount,
+
RIO_HOST_DID_LOCK_CSR,
+
Micha Nelissen wrote:
Alexandre Bounine wrote:
/**
+ * rio_em_set_ops- Sets Error Managment operations for a particular
vendor switch
+ * @rdev: RIO device
+ *
+ * Searches the RIO EM ops table for known switch types. If the vid
+ * and did match a switch table entry, then set the
95 matches
Mail list logo
