Documentation/driver-api/men-chameleon-bus.rst

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