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
> ---
... skip ...
> +
> +int fsl_map_inb_mem(struct rio_mport *mport, dma_addr_t l
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"
> >
On Fri, 26 Apr 2013 6:53 PM Andrew Morton 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 support for RapidI
On Wednesday, April 24, 2013 5:37 PM Andrew Morton wrote:
>
> On Wed, 24 Apr 2013 10:31:57 -0400 Alexandre Bounine
> 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:36 PM
Andrew Morton wrote:
>
> On Wed, 3 Oct 2012 15:18:43 -0400
> Alexandre Bounine wrote:
>
> > ...
> >
> > +static u16 rio_destid_alloc(struct rio_net *net)
> > +{
> > + int destid;
> > + struct rio_id_table *idtab = &net->destid_table;
> > +
> > + spin_lock
On Wed, October 03, 2012 6:30 PM
Andrew Morton wrote:
>
> On Wed, 3 Oct 2012 15:18:41 -0400
> Alexandre Bounine wrote:
>
> > ...
> >
> > +static void __devinit disc_work_handler(struct work_struct *_work)
> > +{
> > + struct rio_disc_work *work = container_of(_work,
> > +
On Wed, October 03, 2012 6:20 PM
Andrew Morton wrote:
>
> On Wed, 3 Oct 2012 15:18:39 -0400
> Alexandre Bounine wrote:
>
> > Fix blocking wait loop in the RapidIO discovery routine to avoid
> > warning dumps about stalled CPU on x86 platforms.
> >
> > ...
> >
> > + to_end = jiffies +
On Friday, August 24, 2012 5:02 PM
Andrew Morton
>
> On Tue, 21 Aug 2012 10:23:54 -0400
> Alexandre Bounine wrote:
>
>> Modify mport device name assignment to provide clear reference to devices
>> in systems with multiple Tsi721 bridges.
>>
>> This patch is applicable to kernel versions startin
On Friday, August 24, 2012 5:04 PM
Andrew Morton
>
> On Tue, 21 Aug 2012 10:23:55 -0400
> Alexandre Bounine wrote:
>
>> Modify RIO enumeration to apply RX/TX enable operations only to
>> active switch ports. This will leave inactive ports in condition consistent
>> with their state.
>
> It's u
re unable 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 s
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 Drive
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 sec
On Mon, March 05, 2012 3:37 PM Andrew Morton wrote:
> Alexandre Bounine 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 to backport the
> fi
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 the
: 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:03 AM
> To: linuxppc-dev@lists.ozlabs.org; Bounine, Alexandre
> Cc: a...@linux-foundation.org; linux-ker...@vger.kernel.org;
> r58...@freescale.com; b11...@
> -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...@
> -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...@
> -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@list
> -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...@
On Fri, Nov 11, 2011 at 8:48 AM Liu Gang 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...@fre
On Tue, Oct 25, 2011 at 6:40 AM, Liu Gang-B34182
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 l
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182
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
> Sub
On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
>
> From: Liu Gang
>
> 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?
Can we have two
On Mon, Oct 17, 2011 at 1:01 PM, Vinod Koul wrote:
>
> On Mon, 2011-10-17 at 21:22 +0530, Jassi Brar wrote:
> > On 15 October 2011 23:05, Vinod Koul wrote:
> >
> > > Another alternate approach could be to add one more argument to
> > > prep_slave_sg API which allows us to pass additional runtime
On Mon, Oct 17, 2011 at 11:53 AM, Jassi Brar
wrote:
>
> On 15 October 2011 23:05, Vinod Koul wrote:
>
> > Another alternate approach could be to add one more argument to
> > prep_slave_sg API which allows us to pass additional runtime
specific
> > parameters. This can be NULL and unused for exi
On Sat, Oct 15, 2011 at 1:36 PM, Vinod Koul 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 y
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
>
Dan J Williams wrote:
>
> On Mon, Oct 3, 2011 at 9:52 AM, 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
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
Andrew Morton wrote:
>
> On Mon, 3 Oct 2011 10:53:45 -0700
> "Bounine, Alexandre" wrote:
>
> > > > + memset(bd_ptr, 0, bd_num * sizeof(struct
tsi721_dma_desc));
> > > > +
> > > > + dev_dbg(dev, "DMA descriptors @ %p (
Andrew Morton wroye:
>
> On Fri, 30 Sep 2011 17:38:35 -0400
> Alexandre Bounine 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 RIO Mainte
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
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
On Thursday, September 01, 2011 5:52 AM
Liu Gang wrote:
> Subject: [PATCH] fsl-rio: Release rapidio port I/O region resource if
> portfailed to initialize
>
...
>
> Signed-off-by: Liu Gang
> ---
> arch/powerpc/sysdev/fsl_rio.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>
Andrew Morton wrote:
> On Tue, 26 Jul 2011 14:07:26 -0400
> Alexandre Bounine 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. 1.3 removed Write Port CSR, Doorbell CS
Andrew Morton wrote:
> On Fri, 12 Aug 2011 15:45:34 -0400
> Alexandre Bounine 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 RAPIDIO_TSI721
> >
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
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-R61
uxppc-dev-
> 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-B
Andrew Morton 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-
> bounces+alexandre.bounine=idt...
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 leas
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 o
Andrew Morton wrote:
> I held
> rapidio-use-common-destid-storage-for-endpoints-and-switches.patch and
> rapidio-integrate-rio_switch-into-rio_dev.patch back from 2.6.37 due
to
> ongoing discussion. What is the situation now?
Sorry, it took me too long to do this follow-up.
Patches in this set a
Andrew Morton 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 describe the proposed i
g]
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.
Gala; Roy
Zang; 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 EPW
Gala; Roy
Zang; Bounine, Alexandre
> Subject: [PATCH 1/2][v4] fsl_rio: move machine_check handler into
machine_check_e500 &
> machine_check_e500mc
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/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 an
> 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-
Shaohui Xie 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
> #include
> +#include
>
> #if defined(CONFIG_DEBUGGER
Kumar Gala 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)
> > printk(
Kumar Gala 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 case.
Yes, this one
Shaohui Xie 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
> #include
> +#include
>
> #if defined(CONFIG_DEBUG
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 Rapid
Micha Nelissen 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
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 w
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
Micha Nelissen 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.
Existing method of form
Micha Nelissen 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 that during debu
Micha Nelissen 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
Micha Nelissen 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 c
Micha Nelissen 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
Micha Nelissen 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
> > switches
Bastiaan Nijkamp 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 endpoint. I will take
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 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 booting linux with a Rapi
Hi John,
John Traill wrote:
> 2. Make sure the target has "Accept All" set - in fsl_rio.c look for
> >/* Set to receive any dist ID for serial RapidIO controller.
*/
> > if (port->phy_type == RIO_PHY_SERIAL)
> > out_be32((priv->regs_win + RIO_ISR_AACR),
RIO_ISR_AAC
Hi Bastiaan,
Bastiaan Nijkamp 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 0068 len
4
... skip
Hi Bastiaan,
Are you trying board-to-board connection?
I am not familiar with WRS SBC8548 board - which type of connector they
use for SRIO?
Assuming that all configuration is correct,
I would recommend first to try setting up x1 link mode at the lowest
link speed.
The x4 mode may present challen
Hi Micha,
Sorry for delayed reply.
Micha Nelissen wrote:
>
> Bounine, Alexandre wrote:
> > struct rio_dev {
> > struct list_head global_list;
> > struct list_head net_list;
> > .
> > . rest of rio_dev
> > .
> >
Andrew Morton 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 only.
No number of s
Andrew Morton 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
> > * @hopcount: Hopcou
Andrew Morton wrote:
> What is the locking for rdev? In other patches I see pointer chases
> with no obvious locking against concurrent changes?
This rdev should be safe because it is intended for use only by
rio_switch
attached to the same rdev. Therefore rio_global_list_lock will work
here.
Anderson, Trevor wrote:
>
> Keep it in please. We lurkers in the embedded community do use the
per-port routing tables.
> One of the problems with SRIO switch tables is that access to routes
is not atomic; we can use
> restricted access to per-port routing tables to reduce the risk of
interferenc
Andrew Morton 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 switches (at least all
Andrew Morton 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
early stage).
___
Andrew Morton 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 indicates which device f
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:
>
> 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) i
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:
>
> 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:
>
> 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 Tsi57
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, hopcoun
Micha Nelissen wrote:
>
> Alexandre Bounine wrote:
> > This set of RapidIO patches adds support for new IDT Gen2 sRIO
switch
> > devices - CPS-1848 and CPS-1616.
> > Adding these sRIO switches required to implement standard error
recovery
> > mechanism defined by the RapidIO specification.
>
> Th
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
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_att
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 so
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:
> > 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
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 us
> 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 err
/
Can anyone pick 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; Al
To: Bounine, Alexandre
> Cc: Michael Neuling; Alexandre Bounine; linuxppc-dev@lists.ozlabs.org;
linux-ker...@vger.kernel.org;
> thomas.m...@sysgo.com; Kumar Gala
> Subject: Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO
port
>
> On Tue, Aug 3, 2010 at 7:17 AM, Bounine, A
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;
linux-ker..
Andrew Morton wrote:
> On Tue, 6 Apr 2010 17:22:38 -0400 Alexandre Bounine
wrote:
>
> >
> > From: Alexandre Bounine
> >
> > Add RapidIO Port-Write message handling in the context
> > of Error Management Extensions Specification Rev.1.3.
> >
> > ...
> >
> > +static struct rio_dev *rio_get_comptag
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
1 - 100 of 103 matches
Mail list logo
