linux/Documentation/men-chameleon-bus.txt
<<
>>
Prefs
   1=================
   2MEN Chameleon Bus
   3=================
   4
   5.. Table of Contents
   6   =================
   7   1 Introduction
   8       1.1 Scope of this Document
   9       1.2 Limitations of the current implementation
  10   2 Architecture
  11       2.1 MEN Chameleon Bus
  12       2.2 Carrier Devices
  13       2.3 Parser
  14   3 Resource handling
  15       3.1 Memory Resources
  16       3.2 IRQs
  17   4 Writing an MCB driver
  18       4.1 The driver structure
  19       4.2 Probing and attaching
  20       4.3 Initializing the driver
  21
  22
  23Introduction
  24============
  25
  26This document describes the architecture and implementation of the MEN
  27Chameleon Bus (called MCB throughout this document).
  28
  29Scope of this Document
  30----------------------
  31
  32This document is intended to be a short overview of the current
  33implementation and does by no means describe the complete possibilities of MCB
  34based devices.
  35
  36Limitations of the current implementation
  37-----------------------------------------
  38
  39The current implementation is limited to PCI and PCIe based carrier devices
  40that only use a single memory resource and share the PCI legacy IRQ.  Not
  41implemented are:
  42
  43- Multi-resource MCB devices like the VME Controller or M-Module carrier.
  44- MCB devices that need another MCB device, like SRAM for a DMA Controller's
  45  buffer descriptors or a video controller's video memory.
  46- A per-carrier IRQ domain for carrier devices that have one (or more) IRQs
  47  per MCB device like PCIe based carriers with MSI or MSI-X support.
  48
  49Architecture
  50============
  51
  52MCB is divided into 3 functional blocks:
  53
  54- The MEN Chameleon Bus itself,
  55- drivers for MCB Carrier Devices and
  56- the parser for the Chameleon table.
  57
  58MEN Chameleon Bus
  59-----------------
  60
  61The MEN Chameleon Bus is an artificial bus system that attaches to a so
  62called Chameleon FPGA device found on some hardware produced my MEN Mikro
  63Elektronik GmbH. These devices are multi-function devices implemented in a
  64single FPGA and usually attached via some sort of PCI or PCIe link. Each
  65FPGA contains a header section describing the content of the FPGA. The
  66header lists the device id, PCI BAR, offset from the beginning of the PCI
  67BAR, size in the FPGA, interrupt number and some other properties currently
  68not handled by the MCB implementation.
  69
  70Carrier Devices
  71---------------
  72
  73A carrier device is just an abstraction for the real world physical bus the
  74Chameleon FPGA is attached to. Some IP Core drivers may need to interact with
  75properties of the carrier device (like querying the IRQ number of a PCI
  76device). To provide abstraction from the real hardware bus, an MCB carrier
  77device provides callback methods to translate the driver's MCB function calls
  78to hardware related function calls. For example a carrier device may
  79implement the get_irq() method which can be translated into a hardware bus
  80query for the IRQ number the device should use.
  81
  82Parser
  83------
  84
  85The parser reads the first 512 bytes of a Chameleon device and parses the
  86Chameleon table. Currently the parser only supports the Chameleon v2 variant
  87of the Chameleon table but can easily be adopted to support an older or
  88possible future variant. While parsing the table's entries new MCB devices
  89are allocated and their resources are assigned according to the resource
  90assignment in the Chameleon table. After resource assignment is finished, the
  91MCB devices are registered at the MCB and thus at the driver core of the
  92Linux kernel.
  93
  94Resource handling
  95=================
  96
  97The current implementation assigns exactly one memory and one IRQ resource
  98per MCB device. But this is likely going to change in the future.
  99
 100Memory Resources
 101----------------
 102
 103Each MCB device has exactly one memory resource, which can be requested from
 104the MCB bus. This memory resource is the physical address of the MCB device
 105inside the carrier and is intended to be passed to ioremap() and friends. It
 106is already requested from the kernel by calling request_mem_region().
 107
 108IRQs
 109----
 110
 111Each MCB device has exactly one IRQ resource, which can be requested from the
 112MCB bus. If a carrier device driver implements the ->get_irq() callback
 113method, the IRQ number assigned by the carrier device will be returned,
 114otherwise the IRQ number inside the Chameleon table will be returned. This
 115number is suitable to be passed to request_irq().
 116
 117Writing an MCB driver
 118=====================
 119
 120The driver structure
 121--------------------
 122
 123Each MCB driver has a structure to identify the device driver as well as
 124device ids which identify the IP Core inside the FPGA. The driver structure
 125also contains callback methods which get executed on driver probe and
 126removal from the system::
 127
 128        static const struct mcb_device_id foo_ids[] = {
 129                { .device = 0x123 },
 130                { }
 131        };
 132        MODULE_DEVICE_TABLE(mcb, foo_ids);
 133
 134        static struct mcb_driver foo_driver = {
 135        driver = {
 136                .name = "foo-bar",
 137                .owner = THIS_MODULE,
 138        },
 139                .probe = foo_probe,
 140                .remove = foo_remove,
 141                .id_table = foo_ids,
 142        };
 143
 144Probing and attaching
 145---------------------
 146
 147When a driver is loaded and the MCB devices it services are found, the MCB
 148core will call the driver's probe callback method. When the driver is removed
 149from the system, the MCB core will call the driver's remove callback method::
 150
 151        static init foo_probe(struct mcb_device *mdev, const struct mcb_device_id *id);
 152        static void foo_remove(struct mcb_device *mdev);
 153
 154Initializing the driver
 155-----------------------
 156
 157When the kernel is booted or your foo driver module is inserted, you have to
 158perform driver initialization. Usually it is enough to register your driver
 159module at the MCB core::
 160
 161        static int __init foo_init(void)
 162        {
 163                return mcb_register_driver(&foo_driver);
 164        }
 165        module_init(foo_init);
 166
 167        static void __exit foo_exit(void)
 168        {
 169                mcb_unregister_driver(&foo_driver);
 170        }
 171        module_exit(foo_exit);
 172
 173The module_mcb_driver() macro can be used to reduce the above code::
 174
 175        module_mcb_driver(foo_driver);
 176