Back to home page

LXR

 
 

    


0001                                MEN Chameleon Bus
0002                                =================
0003 
0004 Table of Contents
0005 =================
0006 1 Introduction
0007     1.1 Scope of this Document
0008     1.2 Limitations of the current implementation
0009 2 Architecture
0010     2.1 MEN Chameleon Bus
0011     2.2 Carrier Devices
0012     2.3 Parser
0013 3 Resource handling
0014     3.1 Memory Resources
0015     3.2 IRQs
0016 4 Writing an MCB driver
0017     4.1 The driver structure
0018     4.2 Probing and attaching
0019     4.3 Initializing the driver
0020 
0021 
0022 1 Introduction
0023 ===============
0024   This document describes the architecture and implementation of the MEN
0025   Chameleon Bus (called MCB throughout this document).
0026 
0027 1.1 Scope of this Document
0028 ---------------------------
0029   This document is intended to be a short overview of the current
0030   implementation and does by no means describe the complete possibilities of MCB
0031   based devices.
0032 
0033 1.2 Limitations of the current implementation
0034 ----------------------------------------------
0035   The current implementation is limited to PCI and PCIe based carrier devices
0036   that only use a single memory resource and share the PCI legacy IRQ.  Not
0037   implemented are:
0038   - Multi-resource MCB devices like the VME Controller or M-Module carrier.
0039   - MCB devices that need another MCB device, like SRAM for a DMA Controller's
0040     buffer descriptors or a video controller's video memory.
0041   - A per-carrier IRQ domain for carrier devices that have one (or more) IRQs
0042     per MCB device like PCIe based carriers with MSI or MSI-X support.
0043 
0044 2 Architecture
0045 ===============
0046   MCB is divided into 3 functional blocks:
0047   - The MEN Chameleon Bus itself,
0048   - drivers for MCB Carrier Devices and
0049   - the parser for the Chameleon table.
0050 
0051 2.1 MEN Chameleon Bus
0052 ----------------------
0053    The MEN Chameleon Bus is an artificial bus system that attaches to a so
0054    called Chameleon FPGA device found on some hardware produced my MEN Mikro
0055    Elektronik GmbH. These devices are multi-function devices implemented in a
0056    single FPGA and usually attached via some sort of PCI or PCIe link. Each
0057    FPGA contains a header section describing the content of the FPGA. The
0058    header lists the device id, PCI BAR, offset from the beginning of the PCI
0059    BAR, size in the FPGA, interrupt number and some other properties currently
0060    not handled by the MCB implementation.
0061 
0062 2.2 Carrier Devices
0063 --------------------
0064    A carrier device is just an abstraction for the real world physical bus the
0065    Chameleon FPGA is attached to. Some IP Core drivers may need to interact with
0066    properties of the carrier device (like querying the IRQ number of a PCI
0067    device). To provide abstraction from the real hardware bus, an MCB carrier
0068    device provides callback methods to translate the driver's MCB function calls
0069    to hardware related function calls. For example a carrier device may
0070    implement the get_irq() method which can be translated into a hardware bus
0071    query for the IRQ number the device should use.
0072 
0073 2.3 Parser
0074 -----------
0075    The parser reads the first 512 bytes of a Chameleon device and parses the
0076    Chameleon table. Currently the parser only supports the Chameleon v2 variant
0077    of the Chameleon table but can easily be adopted to support an older or
0078    possible future variant. While parsing the table's entries new MCB devices
0079    are allocated and their resources are assigned according to the resource
0080    assignment in the Chameleon table. After resource assignment is finished, the
0081    MCB devices are registered at the MCB and thus at the driver core of the
0082    Linux kernel.
0083 
0084 3 Resource handling
0085 ====================
0086   The current implementation assigns exactly one memory and one IRQ resource
0087   per MCB device. But this is likely going to change in the future.
0088 
0089 3.1 Memory Resources
0090 ---------------------
0091    Each MCB device has exactly one memory resource, which can be requested from
0092    the MCB bus. This memory resource is the physical address of the MCB device
0093    inside the carrier and is intended to be passed to ioremap() and friends. It
0094    is already requested from the kernel by calling request_mem_region().
0095 
0096 3.2 IRQs
0097 ---------
0098    Each MCB device has exactly one IRQ resource, which can be requested from the
0099    MCB bus. If a carrier device driver implements the ->get_irq() callback
0100    method, the IRQ number assigned by the carrier device will be returned,
0101    otherwise the IRQ number inside the Chameleon table will be returned. This
0102    number is suitable to be passed to request_irq().
0103 
0104 4 Writing an MCB driver
0105 =======================
0106 
0107 4.1 The driver structure
0108 -------------------------
0109     Each MCB driver has a structure to identify the device driver as well as
0110     device ids which identify the IP Core inside the FPGA. The driver structure
0111     also contains callback methods which get executed on driver probe and
0112     removal from the system.
0113 
0114 
0115   static const struct mcb_device_id foo_ids[] = {
0116           { .device = 0x123 },
0117           { }
0118   };
0119   MODULE_DEVICE_TABLE(mcb, foo_ids);
0120 
0121   static struct mcb_driver foo_driver = {
0122           driver = {
0123                   .name = "foo-bar",
0124                   .owner = THIS_MODULE,
0125           },
0126           .probe = foo_probe,
0127           .remove = foo_remove,
0128           .id_table = foo_ids,
0129   };
0130 
0131 4.2 Probing and attaching
0132 --------------------------
0133    When a driver is loaded and the MCB devices it services are found, the MCB
0134    core will call the driver's probe callback method. When the driver is removed
0135    from the system, the MCB core will call the driver's remove callback method.
0136 
0137 
0138   static init foo_probe(struct mcb_device *mdev, const struct mcb_device_id *id);
0139   static void foo_remove(struct mcb_device *mdev);
0140 
0141 4.3 Initializing the driver
0142 ----------------------------
0143    When the kernel is booted or your foo driver module is inserted, you have to
0144    perform driver initialization. Usually it is enough to register your driver
0145    module at the MCB core.
0146 
0147 
0148   static int __init foo_init(void)
0149   {
0150           return mcb_register_driver(&foo_driver);
0151   }
0152   module_init(foo_init);
0153 
0154   static void __exit foo_exit(void)
0155   {
0156           mcb_unregister_driver(&foo_driver);
0157   }
0158   module_exit(foo_exit);
0159 
0160    The module_mcb_driver() macro can be used to reduce the above code.
0161 
0162 
0163   module_mcb_driver(foo_driver);