Skip to content

F
FMC Bus
Commit cc039425 authored by Alessandro Rubini's avatar Alessandro Rubini
Browse files
Options

overall: typos, white space, and comment fixes 

Various changes to documentation in and outside the code. Most of them
are the result of a review by Emilio Cota and Samuel Iglesias (thanks!)
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
parent 418395f2
Hide whitespace changes
Inline Side-by-side
Showing with 51 additions and 45 deletions
doc/fmc-bus.in
View file @ cc039425
......@@ -60,7 +60,7 @@ Linux. @sc{fmc} (FPGA Mezzanine Card) is the standard we use for our
I/O devices, in the context of White Rabbit and related hardware.
In our I/O environments we need to write drivers for each mezzanine
card, and such drivers must work independent of the carrier being used.
card, and such drivers must work regardless of the carrier being used.
To achieve this, we abstract the @sc{fmc} interface.
We have a carrier for PCI-E called @sc{spec} and one for VME called
......@@ -99,15 +99,15 @@ Trade Association} and ratified by ANSI, the American National
Standard Institute. The official documentation is called ``ANSI-VITA
57.1''.
The @sc{fmc} card is an almost square @sc{psb}, around 70x75 millimetres, that
The @sc{fmc} card is an almost square @sc{pcb}, around 70x75 millimeters, that
is called @i{mezzanine} in this document. It usually lives plugged
into into another @sc{psb} for power supply and control; such bigger
into another @sc{pcb} for power supply and control; such bigger
circuit board is called @i{carrier} from now on, and a single carrier
may host more than one mezzanine.
In the typical application the mezzanine is mostly analogical while
In the typical application the mezzanine is mostly analog while
the carrier is mostly digital, and hosts an @sc{fpga} that must be
programmed to match the specific mezzanine and the desired
configured to match the specific mezzanine and the desired
application. Thus, you may need to load different @sc{fpga} images to
drive different instances of the same mezzanine.
......@@ -551,7 +551,7 @@ to cache the result of this mapping.
All carriers must map their I/O lines
to the sets above starting from zero. The @sc{spec}, for example, maps
interrupt pins 0 and 1, and test points 0 through 3 (even if the test
points on the @sc{psb} are called 5,6,7,8).
points on the @sc{pcb} are called 5,6,7,8).
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
......@@ -905,8 +905,8 @@ Please note that you'll most likely want to use @sc{sdbfs} to build your
environment. For this reason the TLV format is not expected to be used much
and is not expected to be developed further.
If you want to experiment with reflashing fake @sc{eeprom} devices,
you cn use the @t{fmc-fakedev.ko} module (see @ref{fmc-fakedev}).
If you want to try reflashing fake @sc{eeprom} devices,
you can use the @t{fmc-fakedev.ko} module (see @ref{fmc-fakedev}).
Whenever you change the image starting at offset 0, it will deregister
and register again after two seconds. Please note, however, that if
@i{fmc-write-eeprom} is still loaded, the system will associate it to
......@@ -948,15 +948,15 @@ Currently the driver only supports @i{read} and @i{write}: you can
The driver assumes all registers are 32-bit in size, and only accepts
a single read or write per system call. However, as a result of Unix
read and write semantics, users can simply @i{fread} or @i{fwrite}
bigger areas on order to dump or store bigger memory areas.
bigger areas in order to dump or store bigger memory areas.
There is currently no support for @i{mmap}, user-space interrupt
management and DMA buffers. They may be added in later versions, if
the need arises.
The example below shows raw access to a @sc{spec}
card programmed with it's @i{golden} @sc{fpga} file, that features
an @sc{sdb} structure at offset 256 -- i.e. 64 words. The
card programmed with its @i{golden} @sc{fpga} file, that features
an @sc{sdb} structure at offset 256 -- i.e. 64 words.
The mezzanine's @sc{eeprom} in this case is not programmed, so the
default name is @t{fmc-@i{<bus><devfn>}}, and there are two
cards in the system:
......@@ -1159,7 +1159,7 @@ fixed a bug in it), this is tracked by a commit in the supermodule,
because the hosting @i{tree} must be modified to record the new
submodule commit. It is correct, in general, to have a commit in the
supermodule that just updates the commit identifier of the submodule.
Sometimes, however, you commit the new submodule's version together
Sometimes with, however, you commit the new submodule's version together
with changes in the supermodule that use it (like they were parts of
the same package).
......@@ -1707,6 +1707,9 @@ badly.
@bye
@c LocalWords: gnudd titlepage iftex texinfo CERN documentlanguage settitle
@c LocalWords: documentencoding setfilename afourpaper paragraphindent @sc{svec}
@c LocalWords: documentencoding setfilename afourpaper paragraphindent svec
@c LocalWords: setchapternewpage finalout Etherbone eeprom gateware busid
@c LocalWords: GPIO fpga ohwr smallexample spusa insmod
@c LocalWords: GPIO fpga ohwr smallexample spusa insmod struct const inline
@c LocalWords: readl writel itemx config gpio modinfo sdbfs fakedev fdelay
@c LocalWords: hwdev morgana supermodule prereq ccflags KBUILD filesystem
@c LocalWords: linux uint
kernel/fmc-core.c
View file @ cc039425
......@@ -67,7 +67,7 @@ static struct bus_type fmc_bus_type = {
.shutdown = fmc_shutdown,
};
/* Every device must have a release method: provide a default */
/* We really have nothing to release in here */
static void __fmc_release(struct device *dev) { }
/* This is needed as parent for our devices and dir in sysfs */
......@@ -97,7 +97,7 @@ EXPORT_SYMBOL(fmc_driver_unregister);
/*
* When a device set is registered, all eeproms must be read
*and all FRU must be parsed
* and all FRUs must be parsed
*/
int fmc_device_register_n(struct fmc_device *fmcs, int n)
{
......@@ -136,7 +136,7 @@ int fmc_device_register_n(struct fmc_device *fmcs, int n)
if (ret)
break;
fmc->nr_slots = n;
fmc->nr_slots = n; /* each slot must know how many are there */
devarray[i] = fmc;
}
if (ret) {
......
kernel/fmc-dump.c
View file @ cc039425
......@@ -79,9 +79,10 @@ void fmc_dump_sdb(struct fmc_device *fmc)
/* If bigger than 1, dump it seriously, to help debugging */
/*
* FIXME: we should really use libsdbfs, but it doesn't
* support directories yet, and it requires better intergration
* (it should be used instead of fmc-specific code).
* Here we should really use libsdbfs (which is designed to
* work in kernel space as well) , but it doesn't support
* directories yet, and it requires better intergration (it
* should be used instead of fmc-specific code).
*
* So, lazily, just dump the top-level array
*/
......
kernel/fmc-fakedev.c
View file @ cc039425
......@@ -22,10 +22,10 @@ module_param_named(eeprom, ff_eeprom, charp, 0444);
/*
* Eeprom built from these commands:
../fru-generator -v fake-vendor -n fake-design-for-testing \
-s 01234 -p none > IPMI-FRU
../fru-generator -v fake-vendor -n fake-design-for-testing \
-s 01234 -p none > IPMI-FRU
gensdbfs . ../fake-eeprom.bin
gensdbfs . ../fake-eeprom.bin
*/
static char ff_eeimg[FF_EEPROM_SIZE] = {
0x01, 0x00, 0x00, 0x01, 0x00, 0x0c, 0x00, 0xf2, 0x01, 0x0b, 0x00, 0xb2,
......@@ -136,7 +136,7 @@ static void ff_work_fn(struct work_struct *work)
/* low-level i2c */
int ff_eeprom_read(struct fmc_device *fmc, uint32_t offset,
void *buf, size_t size)
void *buf, size_t size)
{
if (offset > FF_EEPROM_SIZE)
return -EINVAL;
......@@ -147,7 +147,7 @@ int ff_eeprom_read(struct fmc_device *fmc, uint32_t offset,
}
int ff_eeprom_write(struct fmc_device *fmc, uint32_t offset,
const void *buf, size_t size)
const void *buf, size_t size)
{
struct ff_dev *ff = container_of(fmc, struct ff_dev, fmc);
......@@ -155,7 +155,7 @@ int ff_eeprom_write(struct fmc_device *fmc, uint32_t offset,
return -EINVAL;
if (offset + size > FF_EEPROM_SIZE)
size = FF_EEPROM_SIZE - offset;
printk("size %i\n", size);
pr_info("%s: size %i\n", __func__, size);
memcpy(ff_eeimg + offset, buf, size);
schedule_delayed_work(&ff->work, HZ * 2); /* remove, replug, in 2s */
return size;
......@@ -200,7 +200,6 @@ static struct fmc_operations ff_fmc_operations = {
/* Every device must have a release method: provide a default */
static void __ff_release(struct device *dev)
{
printk("%s\n", __func__);
memset(dev, 0, sizeof(*dev));
dev->release = __ff_release;
}
......@@ -246,7 +245,7 @@ int ff_init(void)
dev_err(&ff->dev, "Can't load \"%s\" (error %i)\n",
ff_eeprom, -ret);
} else {
len = min(fw->size, (size_t)FF_EEPROM_SIZE);
len = min_t(size_t, fw->size, (size_t)FF_EEPROM_SIZE);
memcpy(ff_eeimg, fw->data, len);
release_firmware(fw);
}
......
kernel/fmc-match.c
View file @ cc039425
......@@ -32,7 +32,7 @@ int fmc_match(struct device *dev, struct device_driver *drv)
dev_warn(fdev->hwdev, "Driver has no ID: matches all\n");
matched = 1;
} else {
for (i = 0; i < fdrv->id_table.fru_id_nr; i++, fid++) {
for (i = 0; i < fdrv->id_table.fru_id_nr; i++, fid++) {
if (strcmp(fid->manufacturer, fdev->id.manufacturer))
continue;
if (strcmp(fid->product_name, fdev->id.product_name))
......@@ -53,7 +53,7 @@ int fmc_fill_id_info(struct fmc_device *fmc)
struct fru_board_info_area *bia;
int ret, allocated = 0;
/* If we kwown the eeprom length, try to read it off the device */
/* If we know the eeprom length, try to read it off the device */
if (fmc->eeprom_len && !fmc->eeprom) {
fmc->eeprom = kzalloc(fmc->eeprom_len, GFP_KERNEL);
if (!fmc->eeprom)
......
kernel/fmc-trivial.c
View file @ cc039425
/*
* Copyright (C) 2012 CERN (www.cern.ch)
* Author: Alessandro Rubini <rubini@gnudd.com>
*
* Released to the public domain, as example to be reused
*/
/* A trivial fmc driver that can load a gateware file and reports interrupts */
#include <linux/module.h>
#include <linux/init.h>
......
kernel/include/linux/fmc.h
View file @ cc039425
......@@ -32,7 +32,7 @@ struct fmc_driver;
/*
* The device identification, as defined by the IPMI FRU (Field Replaceable
* Unit) includes four different stings to describe the device. Here we
* Unit) includes four different strings to describe the device. Here we
* only match the "Board Manufacturer" and the "Board Product Name",
* ignoring the "Board Serial Number" and "Board Part Number". All 4 are
* expected to be strings, so they are treated as zero-terminated C strings.
......@@ -93,7 +93,7 @@ struct fmc_driver {
/*
* Drivers may need to configure gpio pins in the carrier. To read input
* (a very uncommon opeation, and definitely not in the hot paths), just
* (a very uncommon operation, and definitely not in the hot paths), just
* configure one gpio only and get 0 or 1 as retval of the config method
*/
struct fmc_gpio {
......@@ -124,7 +124,7 @@ struct fmc_gpio {
/*
* The operations are offered by each carrier and should make driver
* design completely independent of th carrier. Named GPIO pins may be
* design completely independent of the carrier. Named GPIO pins may be
* the exception.
*/
struct fmc_operations {
......@@ -187,7 +187,10 @@ struct fmc_device {
#define FMC_DEVICE_NO_MEZZANINE 4
#define FMC_DEVICE_MATCH_SDB 8 /* fmc-core must scan sdb in fpga */
/* If the carrier offers no readl/writel, use base address */
/*
* If fpga_base can be used, the carrier offers no readl/writel methods, and
* this expands to a single, fast, I/O access.
*/
static inline uint32_t fmc_readl(struct fmc_device *fmc, int offset)
{
if (unlikely(fmc->op->readl))
......
kernel/include/linux/ipmi-fru.h
View file @ cc039425
......@@ -19,7 +19,7 @@
/*
* These structures match the unaligned crap we have in FRU1011.pdf
* (http://download.intel.com/design/servers/ipmi/FRU1011)
* (http://download.intel.com/design/servers/ipmi/FRU1011.pdf)
*/
/* chapter 8, page 5 */
......@@ -123,13 +123,6 @@ static inline int fru_is_eof(struct fru_type_length *tl)
extern int fru_header_cksum_ok(struct fru_common_header *header);
extern int fru_bia_cksum_ok(struct fru_board_info_area *bia);
/*
* FIXME: is the following needed?
*
* extern int fru_dump_info(struct fru_common_header *header, char *prefix,
* int(*p)(char *fmt, ...));
*/
/* All these 4 return allocated strings by calling fru_alloc() */
extern char *fru_get_board_manufacturer(struct fru_common_header *header);
extern char *fru_get_product_name(struct fru_common_header *header);
......
kernel/include/linux/sdb.h
View file @ cc039425
......@@ -18,7 +18,7 @@
* magic number at the head of the interconnect record
*/
/* Product, 40 bytes at offset 24, 8-byte alignmed
/* Product, 40 bytes at offset 24, 8-byte aligned
*
* device_id is vendor-assigned; version is device-specific,
* date is hex (e.g 0x20120501), name is UTF-8, blank-filled
......@@ -34,7 +34,7 @@ struct sdb_product {
};
/*
* Component, 56 bytes at offset 8, 8-byte aligned
* Component, 56 bytes at offset 8, 8-byte aligned
*
* The address range is first to last, inclusive
* (for example 0x100000 - 0x10ffff)
......@@ -105,7 +105,7 @@ struct sdb_integration {
/* Type 0xff: empty
*
* this allows keeping empty slots during development,
* so they can be filled later with miminal efforts and
* so they can be filled later with minimal effort and
* no misleading description is ever shipped -- hopefully.
* It can also be used to pad a table to a desired length.
*/
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment