310 lines
10 KiB
Plaintext
310 lines
10 KiB
Plaintext
|
|
Writing SBUS Drivers
|
|
|
|
David S. Miller (davem@redhat.com)
|
|
|
|
The SBUS driver interfaces of the Linux kernel have been
|
|
revamped completely for 2.4.x for several reasons. Foremost were
|
|
performance and complexity concerns. This document details these
|
|
new interfaces and how they are used to write an SBUS device driver.
|
|
|
|
SBUS drivers need to include <asm/sbus.h> to get access
|
|
to functions and structures described here.
|
|
|
|
Probing and Detection
|
|
|
|
Each SBUS device inside the machine is described by a
|
|
structure called "struct sbus_dev". Likewise, each SBUS bus
|
|
found in the system is described by a "struct sbus_bus". For
|
|
each SBUS bus, the devices underneath are hung in a tree-like
|
|
fashion off of the bus structure.
|
|
|
|
The SBUS device structure contains enough information
|
|
for you to implement your device probing algorithm and obtain
|
|
the bits necessary to run your device. The most commonly
|
|
used members of this structure, and their typical usage,
|
|
will be detailed below.
|
|
|
|
Here is a piece of skeleton code for performing a device
|
|
probe in an SBUS driver under Linux:
|
|
|
|
static int __devinit mydevice_probe_one(struct sbus_dev *sdev)
|
|
{
|
|
struct mysdevice *mp = kzalloc(sizeof(*mp), GFP_KERNEL);
|
|
|
|
if (!mp)
|
|
return -ENODEV;
|
|
|
|
...
|
|
dev_set_drvdata(&sdev->ofdev.dev, mp);
|
|
return 0;
|
|
...
|
|
}
|
|
|
|
static int __devinit mydevice_probe(struct of_device *dev,
|
|
const struct of_device_id *match)
|
|
{
|
|
struct sbus_dev *sdev = to_sbus_device(&dev->dev);
|
|
|
|
return mydevice_probe_one(sdev);
|
|
}
|
|
|
|
static int __devexit mydevice_remove(struct of_device *dev)
|
|
{
|
|
struct sbus_dev *sdev = to_sbus_device(&dev->dev);
|
|
struct mydevice *mp = dev_get_drvdata(&dev->dev);
|
|
|
|
return mydevice_remove_one(sdev, mp);
|
|
}
|
|
|
|
static struct of_device_id mydevice_match[] = {
|
|
{
|
|
.name = "mydevice",
|
|
},
|
|
{},
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, mydevice_match);
|
|
|
|
static struct of_platform_driver mydevice_driver = {
|
|
.match_table = mydevice_match,
|
|
.probe = mydevice_probe,
|
|
.remove = __devexit_p(mydevice_remove),
|
|
.driver = {
|
|
.name = "mydevice",
|
|
},
|
|
};
|
|
|
|
static int __init mydevice_init(void)
|
|
{
|
|
return of_register_driver(&mydevice_driver, &sbus_bus_type);
|
|
}
|
|
|
|
static void __exit mydevice_exit(void)
|
|
{
|
|
of_unregister_driver(&mydevice_driver);
|
|
}
|
|
|
|
module_init(mydevice_init);
|
|
module_exit(mydevice_exit);
|
|
|
|
The mydevice_match table is a series of entries which
|
|
describes what SBUS devices your driver is meant for. In the
|
|
simplest case you specify a string for the 'name' field. Every
|
|
SBUS device with a 'name' property matching your string will
|
|
be passed one-by-one to your .probe method.
|
|
|
|
You should store away your device private state structure
|
|
pointer in the drvdata area so that you can retrieve it later on
|
|
in your .remove method.
|
|
|
|
Any memory allocated, registers mapped, IRQs registered,
|
|
etc. must be undone by your .remove method so that all resources
|
|
of your device are released by the time it returns.
|
|
|
|
You should _NOT_ use the for_each_sbus(), for_each_sbusdev(),
|
|
and for_all_sbusdev() interfaces. They are deprecated, will be
|
|
removed, and no new driver should reference them ever.
|
|
|
|
Mapping and Accessing I/O Registers
|
|
|
|
Each SBUS device structure contains an array of descriptors
|
|
which describe each register set. We abuse struct resource for that.
|
|
They each correspond to the "reg" properties provided by the OBP firmware.
|
|
|
|
Before you can access your device's registers you must map
|
|
them. And later if you wish to shutdown your driver (for module
|
|
unload or similar) you must unmap them. You must treat them as
|
|
a resource, which you allocate (map) before using and free up
|
|
(unmap) when you are done with it.
|
|
|
|
The mapping information is stored in an opaque value
|
|
typed as an "unsigned long". This is the type of the return value
|
|
of the mapping interface, and the arguments to the unmapping
|
|
interface. Let's say you want to map the first set of registers.
|
|
Perhaps part of your driver software state structure looks like:
|
|
|
|
struct mydevice {
|
|
unsigned long control_regs;
|
|
...
|
|
struct sbus_dev *sdev;
|
|
...
|
|
};
|
|
|
|
At initialization time you then use the sbus_ioremap
|
|
interface to map in your registers, like so:
|
|
|
|
static void init_one_mydevice(struct sbus_dev *sdev)
|
|
{
|
|
struct mydevice *mp;
|
|
...
|
|
|
|
mp->control_regs = sbus_ioremap(&sdev->resource[0], 0,
|
|
CONTROL_REGS_SIZE, "mydevice regs");
|
|
if (!mp->control_regs) {
|
|
/* Failure, cleanup and return. */
|
|
}
|
|
}
|
|
|
|
Second argument to sbus_ioremap is an offset for
|
|
cranky devices with broken OBP PROM. The sbus_ioremap uses only
|
|
a start address and flags from the resource structure.
|
|
Therefore it is possible to use the same resource to map
|
|
several sets of registers or even to fabricate a resource
|
|
structure if driver gets physical address from some private place.
|
|
This practice is discouraged though. Use whatever OBP PROM
|
|
provided to you.
|
|
|
|
And here is how you might unmap these registers later at
|
|
driver shutdown or module unload time, using the sbus_iounmap
|
|
interface:
|
|
|
|
static void mydevice_unmap_regs(struct mydevice *mp)
|
|
{
|
|
sbus_iounmap(mp->control_regs, CONTROL_REGS_SIZE);
|
|
}
|
|
|
|
Finally, to actually access your registers there are 6
|
|
interface routines at your disposal. Accesses are byte (8 bit),
|
|
word (16 bit), or longword (32 bit) sized. Here they are:
|
|
|
|
u8 sbus_readb(unsigned long reg) /* read byte */
|
|
u16 sbus_readw(unsigned long reg) /* read word */
|
|
u32 sbus_readl(unsigned long reg) /* read longword */
|
|
void sbus_writeb(u8 value, unsigned long reg) /* write byte */
|
|
void sbus_writew(u16 value, unsigned long reg) /* write word */
|
|
void sbus_writel(u32 value, unsigned long reg) /* write longword */
|
|
|
|
So, let's say your device has a control register of some sort
|
|
at offset zero. The following might implement resetting your device:
|
|
|
|
#define CONTROL 0x00UL
|
|
|
|
#define CONTROL_RESET 0x00000001 /* Reset hardware */
|
|
|
|
static void mydevice_reset(struct mydevice *mp)
|
|
{
|
|
sbus_writel(CONTROL_RESET, mp->regs + CONTROL);
|
|
}
|
|
|
|
Or perhaps there is a data port register at an offset of
|
|
16 bytes which allows you to read bytes from a fifo in the device:
|
|
|
|
#define DATA 0x10UL
|
|
|
|
static u8 mydevice_get_byte(struct mydevice *mp)
|
|
{
|
|
return sbus_readb(mp->regs + DATA);
|
|
}
|
|
|
|
It's pretty straightforward, and clueful readers may have
|
|
noticed that these interfaces mimick the PCI interfaces of the
|
|
Linux kernel. This was not by accident.
|
|
|
|
WARNING:
|
|
|
|
DO NOT try to treat these opaque register mapping
|
|
values as a memory mapped pointer to some structure
|
|
which you can dereference.
|
|
|
|
It may be memory mapped, it may not be. In fact it
|
|
could be a physical address, or it could be the time
|
|
of day xor'd with 0xdeadbeef. :-)
|
|
|
|
Whatever it is, it's an implementation detail. The
|
|
interface was done this way to shield the driver
|
|
author from such complexities.
|
|
|
|
Doing DVMA
|
|
|
|
SBUS devices can perform DMA transactions in a way similar
|
|
to PCI but dissimilar to ISA, e.g. DMA masters supply address.
|
|
In contrast to PCI, however, that address (a bus address) is
|
|
translated by IOMMU before a memory access is performed and therefore
|
|
it is virtual. Sun calls this procedure DVMA.
|
|
|
|
Linux supports two styles of using SBUS DVMA: "consistent memory"
|
|
and "streaming DVMA". CPU view of consistent memory chunk is, well,
|
|
consistent with a view of a device. Think of it as an uncached memory.
|
|
Typically this way of doing DVMA is not very fast and drivers use it
|
|
mostly for control blocks or queues. On some CPUs we cannot flush or
|
|
invalidate individual pages or cache lines and doing explicit flushing
|
|
over ever little byte in every control block would be wasteful.
|
|
|
|
Streaming DVMA is a preferred way to transfer large amounts of data.
|
|
This process works in the following way:
|
|
1. a CPU stops accessing a certain part of memory,
|
|
flushes its caches covering that memory;
|
|
2. a device does DVMA accesses, then posts an interrupt;
|
|
3. CPU invalidates its caches and starts to access the memory.
|
|
|
|
A single streaming DVMA operation can touch several discontiguous
|
|
regions of a virtual bus address space. This is called a scatter-gather
|
|
DVMA.
|
|
|
|
[TBD: Why do not we neither Solaris attempt to map disjoint pages
|
|
into a single virtual chunk with the help of IOMMU, so that non SG
|
|
DVMA masters would do SG? It'd be very helpful for RAID.]
|
|
|
|
In order to perform a consistent DVMA a driver does something
|
|
like the following:
|
|
|
|
char *mem; /* Address in the CPU space */
|
|
u32 busa; /* Address in the SBus space */
|
|
|
|
mem = (char *) sbus_alloc_consistent(sdev, MYMEMSIZE, &busa);
|
|
|
|
Then mem is used when CPU accesses this memory and u32
|
|
is fed to the device so that it can do DVMA. This is typically
|
|
done with an sbus_writel() into some device register.
|
|
|
|
Do not forget to free the DVMA resources once you are done:
|
|
|
|
sbus_free_consistent(sdev, MYMEMSIZE, mem, busa);
|
|
|
|
Streaming DVMA is more interesting. First you allocate some
|
|
memory suitable for it or pin down some user pages. Then it all works
|
|
like this:
|
|
|
|
char *mem = argumen1;
|
|
unsigned int size = argument2;
|
|
u32 busa; /* Address in the SBus space */
|
|
|
|
*mem = 1; /* CPU can access */
|
|
busa = sbus_map_single(sdev, mem, size);
|
|
if (busa == 0) .......
|
|
|
|
/* Tell the device to use busa here */
|
|
/* CPU cannot access the memory without sbus_dma_sync_single() */
|
|
|
|
sbus_unmap_single(sdev, busa, size);
|
|
if (*mem == 0) .... /* CPU can access again */
|
|
|
|
It is possible to retain mappings and ask the device to
|
|
access data again and again without calling sbus_unmap_single.
|
|
However, CPU caches must be invalidated with sbus_dma_sync_single
|
|
before such access.
|
|
|
|
[TBD but what about writeback caches here... do we have any?]
|
|
|
|
There is an equivalent set of functions doing the same thing
|
|
only with several memory segments at once for devices capable of
|
|
scatter-gather transfers. Use the Source, Luke.
|
|
|
|
Examples
|
|
|
|
drivers/net/sunhme.c
|
|
This is a complicated driver which illustrates many concepts
|
|
discussed above and plus it handles both PCI and SBUS boards.
|
|
|
|
drivers/scsi/esp.c
|
|
Check it out for scatter-gather DVMA.
|
|
|
|
drivers/sbus/char/bpp.c
|
|
A non-DVMA device.
|
|
|
|
drivers/net/sunlance.c
|
|
Lance driver abuses consistent mappings for data transfer.
|
|
It is a nifty trick which we do not particularly recommend...
|
|
Just check it out and know that it's legal.
|