Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
S
Simple PCIe FMC carrier SPEC - Software
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
3
Issues
3
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
Simple PCIe FMC carrier SPEC - Software
Commits
cd6a8dcb
Commit
cd6a8dcb
authored
Oct 09, 2012
by
Alessandro Rubini
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
doc: documented new gpio engine
Signed-off-by:
Alessandro Rubini
<
rubini@gnudd.com
>
parent
4dc04e31
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
82 additions
and
1 deletion
+82
-1
fmc-bus.in
doc/fmc-bus.in
+82
-1
No files found.
doc/fmc-bus.in
View file @
cd6a8dcb
...
...
@@ -199,6 +199,8 @@ struct fmc_operations {
char *name, int flags);
void (*irq
_
ack)(struct fmc
_
device *fmc);
int (*irq
_
free)(struct fmc
_
device *fmc);
int (*gpio
_
config)(struct fmc
_
device *fmc, struct fmc
_
gpio *gpio,
int ngpio);
int (*read
_
ee)(struct fmc
_
device *fmc, int pos, void *d, int l);
int (*write
_
ee)(struct fmc
_
device *fmc, int pos, const void *d, int l);
}
;
...
...
@@ -254,6 +256,12 @@ The individual methods perform the following tasks:
The handler will receive the @i
{
fmc
}
pointer as @i
{
dev
_
id
}
; the
@i
{
flags
}
argument is still to be defined.
@item gpio
_
config
The method allows to configure a GPIO pin in the carrier, and
read its current value if it is configured as input. See
@ref
{
The GPIO Abstraction
}
for details.
@item read
_
ee
@itemx write
_
ee
...
...
@@ -270,7 +278,80 @@ The individual methods perform the following tasks:
@end table
@c ##########################################################################
@node The GPIO Abstraction
@chapter The GPIO Abstraction
Support for GPIO pins in the @i
{
fmc-bus
}
environment is a little
heavy, and deserves special discussion.
While the general idea of a carrier-independent driver seems to fly,
configuration of specific signals within the carrier needs at least
some knowledge of the carrier itself. For this reason, the specific
driver can request to configure carrier-specific GPIO pins, numbered
from 0 to at most 4095. Configuration is performed by passing
a pointer to an array of @t
{
struct fmc
_
gpio
}
items, as well as
the number of those items:
@example
struct fmc
_
gpio
{
char *carrier
_
name;
int gpio;
int
_
gpio; /* internal use by the carrier */
int mode; /* GPIOF
_
DIR
_
OUT etc, from <linux/gpio.h> */
int irqmode; /* IRQF
_
TRIGGER
_
LOW and so on */
}
;
@end example
By specifying a @i
{
carrier
_
name
}
for each pin, the driver may access
different pins in different carriers. The @i
{
gpio
_
config
}
method
returns the number of pins successfully configured, and each carrier
just ignores requests for other carriers. So, for example, a driver
that has been developed and tested on both the SPEC and the SVEC may
request configuration of two different GPIO pins, and expect one such
configuration to succeed -- if none succeeds it most likely means that
the current carrier is a still-unknown one. (FIXME: the return value
is not actually used this way in current code).
If, however, your GPIO pin has a specific known role, you can
pass a special number in the @t
{
gpio
}
field. The header defines
the following macros:
@example
#define FMC
_
GPIO
_
RAW(x) (x) /* 4096 of them */
#define FMC
_
GPIO
_
IRQ(x) ((x) + 0x1000) /* 256 of them */
#define FMC
_
GPIO
_
LED(x) ((x) + 0x1100) /* 256 of them */
#define FMC
_
GPIO
_
KEY(x) ((x) + 0x1200) /* 256 of them */
#define FMC
_
GPIO
_
TP(x) ((x) + 0x1300) /* 256 of them */
#define FMC
_
GPIO
_
USER(x) ((x) + 0x1400) /* 256 of them */
@end example
Use of virtual GPIO numbers (anything but @t
{
FMC
_
GPIO
_
RAW
}
) is allowed
provided the @i
{
carrier
_
name
}
field is left unspecified (NULL). Each
carrier is responsible for providing a mapping between virtual and
physical GPIO numbers (and possibly cache the raw number in the
@t
{_
gpio
}
field). All carriers must map their I/O lines
to the sets above starting from zero. The SPEC, for example, maps
interrupt 0 and 1, and test points 0 through 3.
If, for example, a driver requires a free led and a test point (for a
scope probe to be plugged at some point during development) it may ask
for @t
{
FMC
_
GPIO
_
LED(0)
}
and @t
{
FMC
_
GPIO
_
TP(0)
}
. Each carrier will
provide suitable GPIO pins. Clearly, the person running the drivers
will know the order used by the specific carrier driver in assigning
leds and testpoints, so to make a carrier-dependent use of the diagnostic tools.
In theory, some form of autodetection should be possible: a driver
like the @i
{
wr-nic
}
(which uses IRQ(1) on the SPEC card) should
configure IRQ(0), make a test with software-generated interrupts and
configure IRQ(1) if the test fails -- the @i
{
wr-nic
}
gateware is
known to use IRQ1 on the SPEC, but the driver should be
carrier-independent if possible and thus use IRQ(0) as a first bet.
If a pin is configured as input, the @i
{
gpio
_
config
}
method returns 0
or 1, to report its current value. Invalid GPIO numbers will cause
@code
{
-ENODEV
}
to be returned for physical numbers and @code
{
-ENOENT
}
for virtual mappings.
@bye
@c LocalWords: gnudd titlepage iftex texinfo CERN documentlanguage settitle
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment