[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a27d3730905150056m7298b66ckb9db92f9432953d6@mail.gmail.com>
Date: Fri, 15 May 2009 15:56:49 +0800
From: Li Yang <leoli@...escale.com>
To: Jan Neskudla <jan.neskudla.ext@....com>
Cc: linuxppc-dev <linuxppc-dev@...abs.org>,
linux-kernel@...r.kernel.org
Subject: Re: RapidIO - general questions
On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla <jan.neskudla.ext@....com> wrote:
> 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 <jan.neskudla.ext@....com> 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
You are having one driver, but it probes 3 times for each device using
the driver.
> a driver locally for remote device. Am I missing something ?
If you want to interact with the remote device, you need the driver to
do the work locally.
>
> 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 ?
It looks like an known issue for switched rio network, but I don't
have the correct equipment to reproduce the problem here. Could you
do some basic debugging and share your findings? Thanks.
- Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists