RE: RapidIO - general questions

With regards to your Oops: we sometimes find that, although a switch may
report a port being active, whenever
we try to discover what lies behind it, transfer errors occur that are
non-recoverable.

As a solution, on Freescale MPC8641D, we use a DMA transfer to perform a
simple MAINT read on a new device, just to see if it responds. Transfer
errors may still happen, but they are recoverable in that case, and you
can train your code to avoid that port or try it later. (The DMA engine
will report the error, not the processor.)



-----Original Message-----
From: linuxppc-dev-bounces+tanderson=curtisswright.com@xxxxxxxxxx
[mailto:linuxppc-dev-
bounces+tanderson=curtisswright.com@xxxxxxxxxx] On Behalf Of Jan
Neskudla
Sent: Wednesday, May 20, 2009 12:00 AM
To: ext Li Yang
Cc: linuxppc-dev; linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: RapidIO - general questions

n Fri, 2009-05-15 at 15:56 +0800, ext Li Yang wrote:
On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla
<jan.neskudla.ext@xxxxxxx> 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@xxxxxxx> 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.

We are going to use a RapidIO as a bigger network of active devices,
and
each will have each own driver (sitting on its own), and all the
settings will be done over maintenance packets.

May be it will be solved by the fact, that we are going to use a
staticIDs, so there will be no discovery as it is now. And thus there
will be only one device visible in the internal structures of the
subsystem, and thus only one drive will be loaded.



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.

I tried to acquired some info about the problem, I found that the OOPS
always occur when there is no respond from the device or the respond
is
too slow. I always got that error during function call
rio_get_host_deviceid_lock when it tries to access a remote device or
switch. This function is the first call of the
rio_mport_read_config_32
so is also first try of remote access to any device.

It is a timing issue, and after placing a printk into the
rio_get_host_deviceid_lock the OOPSing almost disappeared.

Jan


- Leo

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@xxxxxxxxxx
https://ozlabs.org/mailman/listinfo/linuxppc-dev

_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries. Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations. The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: RapidIO - general questions
    ... we'd like to contribute to the Linux RapidIO subsystem, ... during enumeration of domains and later on during enumeration of ... MCUs trying to configure the same switch in certain situation, ... Aux driver - basic driver, ...
    (Linux-Kernel)
  • [git patches] IDE updates (part 4)
    ... ide: add IDE_HFLAG_BOOTABLE host flag ... alim15x3: always tune PIO ... Fix siimage driver accessing beyond array boundary ... There is a 25/33MHz switch in configuration ...
    (Linux-Kernel)
  • Re: RapidIO - general questions
    ... and so I have some questions about general design of Linux RIO ... I did not find any better mailing list for RapidIO ... Aux driver - basic driver, ... there is no one currently working on these features for Linux. ...
    (Linux-Kernel)
  • Re: [PATCH] atmel_serial: update the powersave handler to match serial core
    ... I think that a driver can do the request to a the gpio layer (may can be implemented ... pin change interrupt. ... For waking up, we need to switch on the main oscillator, wait until it ...
    (Linux-Kernel)
  • Re: [PATCH][RESEND] New type of DTV2000H TV Card
    ... But I had installed GPG and signed my patch, maybe this is what I should have done earlier. ... This piece of code used to switch the input of RF signal to "Air Antenna" ... if this patch (and driver) would be able to switch RF ... inputs in DVB-T mode somehow. ...
    (Linux-Kernel)