Loading...
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 4.4 Using DMA
22
23
24Introduction
25============
26
27This document describes the architecture and implementation of the MEN
28Chameleon Bus (called MCB throughout this document).
29
30Scope of this Document
31----------------------
32
33This document is intended to be a short overview of the current
34implementation and does by no means describe the complete possibilities of MCB
35based devices.
36
37Limitations of the current implementation
38-----------------------------------------
39
40The current implementation is limited to PCI and PCIe based carrier devices
41that only use a single memory resource and share the PCI legacy IRQ. Not
42implemented 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
50Architecture
51============
52
53MCB 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
59MEN Chameleon Bus
60-----------------
61
62The MEN Chameleon Bus is an artificial bus system that attaches to a so
63called Chameleon FPGA device found on some hardware produced my MEN Mikro
64Elektronik GmbH. These devices are multi-function devices implemented in a
65single FPGA and usually attached via some sort of PCI or PCIe link. Each
66FPGA contains a header section describing the content of the FPGA. The
67header lists the device id, PCI BAR, offset from the beginning of the PCI
68BAR, size in the FPGA, interrupt number and some other properties currently
69not handled by the MCB implementation.
70
71Carrier Devices
72---------------
73
74A carrier device is just an abstraction for the real world physical bus the
75Chameleon FPGA is attached to. Some IP Core drivers may need to interact with
76properties of the carrier device (like querying the IRQ number of a PCI
77device). To provide abstraction from the real hardware bus, an MCB carrier
78device provides callback methods to translate the driver's MCB function calls
79to hardware related function calls. For example a carrier device may
80implement the get_irq() method which can be translated into a hardware bus
81query for the IRQ number the device should use.
82
83Parser
84------
85
86The parser reads the first 512 bytes of a Chameleon device and parses the
87Chameleon table. Currently the parser only supports the Chameleon v2 variant
88of the Chameleon table but can easily be adopted to support an older or
89possible future variant. While parsing the table's entries new MCB devices
90are allocated and their resources are assigned according to the resource
91assignment in the Chameleon table. After resource assignment is finished, the
92MCB devices are registered at the MCB and thus at the driver core of the
93Linux kernel.
94
95Resource handling
96=================
97
98The current implementation assigns exactly one memory and one IRQ resource
99per MCB device. But this is likely going to change in the future.
100
101Memory Resources
102----------------
103
104Each MCB device has exactly one memory resource, which can be requested from
105the MCB bus. This memory resource is the physical address of the MCB device
106inside the carrier and is intended to be passed to ioremap() and friends. It
107is already requested from the kernel by calling request_mem_region().
108
109IRQs
110----
111
112Each MCB device has exactly one IRQ resource, which can be requested from the
113MCB bus. If a carrier device driver implements the ->get_irq() callback
114method, the IRQ number assigned by the carrier device will be returned,
115otherwise the IRQ number inside the Chameleon table will be returned. This
116number is suitable to be passed to request_irq().
117
118Writing an MCB driver
119=====================
120
121The driver structure
122--------------------
123
124Each MCB driver has a structure to identify the device driver as well as
125device ids which identify the IP Core inside the FPGA. The driver structure
126also contains callback methods which get executed on driver probe and
127removal 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
145Probing and attaching
146---------------------
147
148When a driver is loaded and the MCB devices it services are found, the MCB
149core will call the driver's probe callback method. When the driver is removed
150from 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
155Initializing the driver
156-----------------------
157
158When the kernel is booted or your foo driver module is inserted, you have to
159perform driver initialization. Usually it is enough to register your driver
160module 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
174The module_mcb_driver() macro can be used to reduce the above code::
175
176 module_mcb_driver(foo_driver);
177
178Using DMA
179---------
180
181To make use of the kernel's DMA-API's function, you will need to use the
182carrier device's 'struct device'. Fortunately 'struct mcb_device' embeds a
183pointer (->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 */
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);