linux-toradex.git/drivers/rapidio/rio-scan.c, branch v3.10.62

rapidio: add enumeration/discovery start from user space

2013-05-24T23:22:50+00:00

Add RapidIO enumeration/discovery start from user space.  User space
start allows to defer RapidIO fabric scan until the moment when all
participating endpoints are initialized avoiding mandatory synchronized
start of all endpoints (which may be challenging in systems with large
number of RapidIO endpoints).

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Cc: Kumar Gala 
Cc: Andre van Herk 
Cc: Micha Nelissen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: make enumeration/discovery configurable

2013-05-24T23:22:50+00:00

Systems that use RapidIO fabric may need to implement their own
enumeration and discovery methods which are better suitable for needs of
a target application.

The following set of patches is intended to simplify process of
introduction of new RapidIO fabric enumeration/discovery methods.

The first patch offers ability to add new RapidIO enumeration/discovery
methods using kernel configuration options.  This new configuration
option mechanism allows to select statically linked or modular
enumeration/discovery method(s) from the list of existing methods or use
external module(s).

This patch also updates the currently existing enumeration/discovery
code to be used as a statically linked or modular method.

The corresponding configuration option is named "Basic
enumeration/discovery" method.  This is the only one configuration
option available today but new methods are expected to be introduced
after adoption of provided patches.

The second patch address a long time complaint of RapidIO subsystem
users regarding fabric enumeration/discovery start sequence.  Existing
implementation offers only a boot-time enumeration/discovery start which
requires synchronized boot of all endpoints in RapidIO network.  While
it works for small closed configurations with limited number of
endpoints, using this approach in systems with large number of endpoints
is quite challenging.

To eliminate requirement for synchronized start the second patch
introduces RapidIO enumeration/discovery start from user space.

For compatibility with the existing RapidIO subsystem implementation,
automatic boot time enumeration/discovery start can be configured in by
specifying "rio-scan.scan=1" command line parameter if statically linked
basic enumeration method is selected.

This patch:

Rework to implement RapidIO enumeration/discovery method selection
combined with ability to use enumeration/discovery as a kernel module.

This patch adds ability to introduce new RapidIO enumeration/discovery
methods using kernel configuration options.  Configuration option
mechanism allows to select statically linked or modular
enumeration/discovery method from the list of existing methods or use
external modules.  If a modular enumeration/discovery is selected each
RapidIO mport device can have its own method attached to it.

The existing enumeration/discovery code was updated to be used as
statically linked or modular method.  This configuration option is named
"Basic enumeration/discovery" method.

Several common routines have been moved from rio-scan.c to make them
available to other enumeration methods and reduce number of exported
symbols.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Cc: Kumar Gala 
Cc: Andre van Herk 
Cc: Micha Nelissen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: remove use of __devinit

2012-11-28T20:11:31+00:00

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.

Signed-off-by: Bill Pemberton 
Cc: Matt Porter 
Acked-by: Alexandre Bounine 
Signed-off-by: Greg Kroah-Hartman

rapidio: update for destination ID allocation

2012-10-10T23:50:15+00:00

Address comments provided by Andrew Morton:
https://lkml.org/lkml/2012/10/3/550

 - Keeps consistent kerneldoc compatible comments style for new static
   functions.
 - Removes unnecessary complexity from destination ID allocation
   routine.
 - Uses kcalloc() for code clarity.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: use msleep in discovery wait

2012-10-10T23:50:14+00:00

Use msleep() for code clarity as suggested by Andrew Morton in his
comments for the original patch: https://lkml.org/lkml/2012/10/3/546.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: add destination ID allocation mechanism

2012-10-05T18:05:23+00:00

Replace the single global destination ID counter with per-net allocation
mechanism to allow independent destID management for each available
RapidIO network.  Using bitmap based mechanism instead of counters allows
destination ID release and reuse in systems that support hot-swap.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: run discovery as an asynchronous process

2012-10-05T18:05:22+00:00

Modify mport initialization routine to run the RapidIO discovery process
asynchronously.  This allows to have an arbitrary order of enumerating and
discovering ports in systems with multiple RapidIO controllers without
creating a deadlock situation if enumerator port is registered after a
discovering one.

Making netID matching to mportID ensures consistent net ID assignment in
multiport RapidIO systems with asynchronous discovery process (global
counter implementation is affected by race between threads).

[akpm@linux-foundation.org: tweak code layput]
Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: use device lists handling on per-net basis

2012-10-05T18:05:22+00:00

Modify handling of device lists to resolve issues caused by using single
global list of RIO devices during enumeration/discovery.  The most common
sign of existing issue is incorrect contents of switch routing tables in
systems with multiple mport controllers while single-port configuration
performs as expected.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: fix blocking wait for discovery ready

2012-10-05T18:05:22+00:00

The following set of patches provides modifications targeting support of
multiple RapidIO master port (mport) devices on a CPU-side of
RapidIO-capable board.  While the RapidIO subsystem code has definitions
suitable for multi-controller/multi-net support, the existing
implementation cannot be considered ready for multiple mport
configurations.

=========== NOTES: =============

a) The patches below do not address RapidIO side view of multiport
   processing elements defined in Part 6 of RapidIO spec Rev.2.1 (section
   6.4.1).  These devices have Base Device ID CSR (0x60) and Component Tag
   CSR (0x6C) shared by all SRIO ports.  For example, Freescale's P4080,
   P3041 and P5020 have a dual-port SRIO controller implemented according
   the specification.  Enumeration/discovery of such devices from RapidIO
   side may require device-specific fixups.

b) Devices referenced above may also require implementation specific
   code to setup a host device ID for mport device.  These operations are
   not addressed by patches in this package.

=================================

Details about provided patches:

1. Fix blocking wait for discovery ready

   While it does not happen on PowerPC based platforms, there is
   possibility of stalled CPU warning dump on x86 based platforms that run
   RapidIO discovery process if they wait too long for being enumerated.

   Currently users can avoid it by disabling the soft-lockup detector
   using "nosoftlockup" kernel parameter OR by ensuring that enumeration
   is completed before soft-lockup is detected.

   This patch eliminates blocking wait and keeps a scheduler running.
   It also is required for patch 3 below which introduces asynchronous
   discovery process.

2. Use device lists handling on per-net basis

   This patch allows to correctly support multiple RapidIO nets and
   resolves possible issues caused by using single global list of devices
   during RapidIO system enumeration/discovery.  The most common sign of
   existing issue is incorrect contents of switch routing tables in
   systems with multiple mport controllers while single-port configuration
   performs as expected.

   The patch does not eliminate the global RapidIO device list but
   changes some routines in enumeration/discovery to use per-net device
   lists instead.  This way compatibility with upper layer RIO routines is
   preserved.

3.  Run discovery as an asynchronous process

   This patch modifies RapidIO initialization routine to asynchronously
   run the discovery process for each corresponding mport.  This allows
   having an arbitrary order of enumerating and discovering mports without
   creating a deadlock situation if an enumerator port was registered
   after a discovering one.

   On boards with multiple discovering mports it also eliminates order
   dependency between mports and may reduce total time of RapidIO
   subsystem initialization.

   Making netID matching to mportID ensures consistent netID assignment
   in multiport RapidIO systems with asynchronous discovery process
   (global counter implementation is affected by race between threads).

4. Rework RIONET to support multiple RIO master ports

   In the current version of the driver rionet_probe() has comment "XXX
   Make multi-net safe".  Now it is a good time to address this comment.

   This patch makes RIONET driver multi-net safe/capable by introducing
   per-net lists of RapidIO network peers.  It also enables to register
   network adapters for all available mport devices.

5. Add destination ID allocation mechanism

   The patch replaces a single global destination ID counter with
   per-net allocation mechanism to allow independent destID management for
   each available RapidIO network.  Using bitmap based mechanism instead
   of counters allows destination ID release and reuse in systems that
   support hot-swap.

This patch:

Fix blocking wait loop in the RapidIO discovery routine to avoid warning
dumps about stalled CPU on x86 platforms.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Cc: Li Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rapidio: apply RX/TX enable to active switch ports only

2012-10-05T18:05:22+00:00

Apply port RX/TX enable operations only to active switch ports.

RapidIO specification (Part 6: LP-Serial Physical Layer) recommends to
keep Output Port Enable (TX) and Input Port Enable (RX) control bits in
disabled state (0b0) after device reset.  It also allows to have
implementation specific reset state for these bits.

This patch ensures that TX/RX enable action is applied only to active
switch's ports while preserving an initial state of inactive ones.

This patch is intended to keep inactive switch ports with inbound and
outbound packet transfers disabled to block unexpected packets during hot
insertion event.  While it does not fix any visible malfunction it is
intended to prevent such events in future.

Signed-off-by: Alexandre Bounine 
Cc: Matt Porter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds