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