From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "demumfd002.nsn-inter.net", Issuer "VeriSign Class 3 Secure Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 48265DE084 for ; Fri, 15 May 2009 17:33:39 +1000 (EST) Subject: Re: RapidIO - general questions From: Jan Neskudla To: ext Li Yang In-Reply-To: <2a27d3730905130357re0adf41l19f5603a70dac57b@mail.gmail.com> References: <1242119872.16400.113.camel@demuxf9c> <2a27d3730905130357re0adf41l19f5603a70dac57b@mail.gmail.com> Content-Type: text/plain Date: Fri, 15 May 2009 09:33:11 +0200 Message-Id: <1242372791.26759.34.camel@demuxf9c> Mime-Version: 1.0 Cc: linuxppc-dev , linux-kernel@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote: > cc'ed LKML > > On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla wrote: > > Hallo > > > > we'd likes to use a RapidIO as a general communication bus on our new > > product, and so I have some questions about general design of Linux RIO > > subsystem. I did not find any better mailing list for RapidIO > > discussion. > > > > [1] - we'd like to implement following features > > * Hot-plug (hot-insert/hot-remove) of devices > > * Error handling (port-write packets - configuration, handling of > > them) > > * Static ID configuration based on port numbers > > * Aux driver - basic driver, for sending messages over different > > mboxes, handling ranges of doorbells > > > > Is it here anyone who is working on any improvement, or anyone who > > knows the development plans for RapidIO subsystem? > > > > AFAIK, there is no one currently working on these features for Linux. > It will be good if you can add these useful features. Yes it looks like that, currently we are analyzing current rapidIO system, and how we can add these features. > > > [2] - I have a following problem with a current implementation of > > loading drivers. The driver probe-function call is based on comparison > > of VendorID (VID) and DeviceID (DID) only. Thus if I have 3 devices with > > same DID and VID connected to the same network (bus), the driver is > > loaded 3times, instead only once for the actual device Master port. > > This should be the correct way as you actually have 3 instances of the device. > > > > > Rionet driver solved this by enabling to call initialization function > > just once, and it expect that this is the Master port. > > Rionet is kind of special. It's not working like a simple device > driver, but more like a customized protocol stack to support multiple > ethernet over rio links. > > > > > Is it this correct behavior ? It looks to me that RapidIO is handled > > like a local bus (like PCI) > > This is correct behavior. All of them are using Linux device/driver > infrastructure, but rionet is a special device. But I do not have a 3 devices on one silicon. I am talking about 3 devices (3 x EP8548 boards + IDT switch) connected over rapidIO through the switch. And in this case I'd like to have only one driver siting on the top of Linux RapidIO subsystem. I don't see the advantage of loading a driver locally for remote device. Am I missing something ? And one more think, I am getting so much Bus errors OOPSes. Whenever there is a problem with a comunication over Rio I get such a kernel OPS. I had to add some delays into some function to be able to finish the enum+discovery process. Did you have some experience with some bigger rio network running under linux ? Jan