721 lines · plain
1=========================2Writing a MUSB Glue Layer3=========================4 5:Author: Apelete Seketeli6 7Introduction8============9 10The Linux MUSB subsystem is part of the larger Linux USB subsystem. It11provides support for embedded USB Device Controllers (UDC) that do not12use Universal Host Controller Interface (UHCI) or Open Host Controller13Interface (OHCI).14 15Instead, these embedded UDC rely on the USB On-the-Go (OTG)16specification which they implement at least partially. The silicon17reference design used in most cases is the Multipoint USB Highspeed18Dual-Role Controller (MUSB HDRC) found in the Mentor Graphics Inventra™19design.20 21As a self-taught exercise I have written an MUSB glue layer for the22Ingenic JZ4740 SoC, modelled after the many MUSB glue layers in the23kernel source tree. This layer can be found at24``drivers/usb/musb/jz4740.c``. In this documentation I will walk through the25basics of the ``jz4740.c`` glue layer, explaining the different pieces and26what needs to be done in order to write your own device glue layer.27 28.. _musb-basics:29 30Linux MUSB Basics31=================32 33To get started on the topic, please read USB On-the-Go Basics (see34Resources) which provides an introduction of USB OTG operation at the35hardware level. A couple of wiki pages by Texas Instruments and Analog36Devices also provide an overview of the Linux kernel MUSB configuration,37albeit focused on some specific devices provided by these companies.38Finally, getting acquainted with the USB specification at USB home page39may come in handy, with practical instance provided through the Writing40USB Device Drivers documentation (again, see Resources).41 42Linux USB stack is a layered architecture in which the MUSB controller43hardware sits at the lowest. The MUSB controller driver abstract the44MUSB controller hardware to the Linux USB stack::45 46 ------------------------47 | | <------- drivers/usb/gadget48 | Linux USB Core Stack | <------- drivers/usb/host49 | | <------- drivers/usb/core50 ------------------------51 ⬍52 --------------------------53 | | <------ drivers/usb/musb/musb_gadget.c54 | MUSB Controller driver | <------ drivers/usb/musb/musb_host.c55 | | <------ drivers/usb/musb/musb_core.c56 --------------------------57 ⬍58 ---------------------------------59 | MUSB Platform Specific Driver |60 | | <-- drivers/usb/musb/jz4740.c61 | aka "Glue Layer" |62 ---------------------------------63 ⬍64 ---------------------------------65 | MUSB Controller Hardware |66 ---------------------------------67 68As outlined above, the glue layer is actually the platform specific code69sitting in between the controller driver and the controller hardware.70 71Just like a Linux USB driver needs to register itself with the Linux USB72subsystem, the MUSB glue layer needs first to register itself with the73MUSB controller driver. This will allow the controller driver to know74about which device the glue layer supports and which functions to call75when a supported device is detected or released; remember we are talking76about an embedded controller chip here, so no insertion or removal at77run-time.78 79All of this information is passed to the MUSB controller driver through80a :c:type:`platform_driver` structure defined in the glue layer as::81 82 static struct platform_driver jz4740_driver = {83 .probe = jz4740_probe,84 .remove = jz4740_remove,85 .driver = {86 .name = "musb-jz4740",87 },88 };89 90The probe and remove function pointers are called when a matching device91is detected and, respectively, released. The name string describes the92device supported by this glue layer. In the current case it matches a93platform_device structure declared in ``arch/mips/jz4740/platform.c``. Note94that we are not using device tree bindings here.95 96In order to register itself to the controller driver, the glue layer97goes through a few steps, basically allocating the controller hardware98resources and initialising a couple of circuits. To do so, it needs to99keep track of the information used throughout these steps. This is done100by defining a private ``jz4740_glue`` structure::101 102 struct jz4740_glue {103 struct device *dev;104 struct platform_device *musb;105 struct clk *clk;106 };107 108 109The dev and musb members are both device structure variables. The first110one holds generic information about the device, since it's the basic111device structure, and the latter holds information more closely related112to the subsystem the device is registered to. The clk variable keeps113information related to the device clock operation.114 115Let's go through the steps of the probe function that leads the glue116layer to register itself to the controller driver.117 118.. note::119 120 For the sake of readability each function will be split in logical121 parts, each part being shown as if it was independent from the others.122 123.. code-block:: c124 :emphasize-lines: 8,12,18125 126 static int jz4740_probe(struct platform_device *pdev)127 {128 struct platform_device *musb;129 struct jz4740_glue *glue;130 struct clk *clk;131 int ret;132 133 glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);134 if (!glue)135 return -ENOMEM;136 137 musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);138 if (!musb) {139 dev_err(&pdev->dev, "failed to allocate musb device\n");140 return -ENOMEM;141 }142 143 clk = devm_clk_get(&pdev->dev, "udc");144 if (IS_ERR(clk)) {145 dev_err(&pdev->dev, "failed to get clock\n");146 ret = PTR_ERR(clk);147 goto err_platform_device_put;148 }149 150 ret = clk_prepare_enable(clk);151 if (ret) {152 dev_err(&pdev->dev, "failed to enable clock\n");153 goto err_platform_device_put;154 }155 156 musb->dev.parent = &pdev->dev;157 158 glue->dev = &pdev->dev;159 glue->musb = musb;160 glue->clk = clk;161 162 return 0;163 164 err_platform_device_put:165 platform_device_put(musb);166 return ret;167 }168 169The first few lines of the probe function allocate and assign the glue,170musb and clk variables. The ``GFP_KERNEL`` flag (line 8) allows the171allocation process to sleep and wait for memory, thus being usable in a172locking situation. The ``PLATFORM_DEVID_AUTO`` flag (line 12) allows173automatic allocation and management of device IDs in order to avoid174device namespace collisions with explicit IDs. With :c:func:`devm_clk_get`175(line 18) the glue layer allocates the clock -- the ``devm_`` prefix176indicates that :c:func:`clk_get` is managed: it automatically frees the177allocated clock resource data when the device is released -- and enable178it.179 180 181 182Then comes the registration steps:183 184.. code-block:: c185 :emphasize-lines: 3,5,7,9,16186 187 static int jz4740_probe(struct platform_device *pdev)188 {189 struct musb_hdrc_platform_data *pdata = &jz4740_musb_platform_data;190 191 pdata->platform_ops = &jz4740_musb_ops;192 193 platform_set_drvdata(pdev, glue);194 195 ret = platform_device_add_resources(musb, pdev->resource,196 pdev->num_resources);197 if (ret) {198 dev_err(&pdev->dev, "failed to add resources\n");199 goto err_clk_disable;200 }201 202 ret = platform_device_add_data(musb, pdata, sizeof(*pdata));203 if (ret) {204 dev_err(&pdev->dev, "failed to add platform_data\n");205 goto err_clk_disable;206 }207 208 return 0;209 210 err_clk_disable:211 clk_disable_unprepare(clk);212 err_platform_device_put:213 platform_device_put(musb);214 return ret;215 }216 217The first step is to pass the device data privately held by the glue218layer on to the controller driver through :c:func:`platform_set_drvdata`219(line 7). Next is passing on the device resources information, also privately220held at that point, through :c:func:`platform_device_add_resources` (line 9).221 222Finally comes passing on the platform specific data to the controller223driver (line 16). Platform data will be discussed in224:ref:`musb-dev-platform-data`, but here we are looking at the225``platform_ops`` function pointer (line 5) in ``musb_hdrc_platform_data``226structure (line 3). This function pointer allows the MUSB controller227driver to know which function to call for device operation::228 229 static const struct musb_platform_ops jz4740_musb_ops = {230 .init = jz4740_musb_init,231 .exit = jz4740_musb_exit,232 };233 234Here we have the minimal case where only init and exit functions are235called by the controller driver when needed. Fact is the JZ4740 MUSB236controller is a basic controller, lacking some features found in other237controllers, otherwise we may also have pointers to a few other238functions like a power management function or a function to switch239between OTG and non-OTG modes, for instance.240 241At that point of the registration process, the controller driver242actually calls the init function:243 244 .. code-block:: c245 :emphasize-lines: 12,14246 247 static int jz4740_musb_init(struct musb *musb)248 {249 musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);250 if (!musb->xceiv) {251 pr_err("HS UDC: no transceiver configured\n");252 return -ENODEV;253 }254 255 /* Silicon does not implement ConfigData register.256 * Set dyn_fifo to avoid reading EP config from hardware.257 */258 musb->dyn_fifo = true;259 260 musb->isr = jz4740_musb_interrupt;261 262 return 0;263 }264 265The goal of ``jz4740_musb_init()`` is to get hold of the transceiver266driver data of the MUSB controller hardware and pass it on to the MUSB267controller driver, as usual. The transceiver is the circuitry inside the268controller hardware responsible for sending/receiving the USB data.269Since it is an implementation of the physical layer of the OSI model,270the transceiver is also referred to as PHY.271 272Getting hold of the ``MUSB PHY`` driver data is done with ``usb_get_phy()``273which returns a pointer to the structure containing the driver instance274data. The next couple of instructions (line 12 and 14) are used as a275quirk and to setup IRQ handling respectively. Quirks and IRQ handling276will be discussed later in :ref:`musb-dev-quirks` and277:ref:`musb-handling-irqs`\ ::278 279 static int jz4740_musb_exit(struct musb *musb)280 {281 usb_put_phy(musb->xceiv);282 283 return 0;284 }285 286Acting as the counterpart of init, the exit function releases the MUSB287PHY driver when the controller hardware itself is about to be released.288 289Again, note that init and exit are fairly simple in this case due to the290basic set of features of the JZ4740 controller hardware. When writing an291musb glue layer for a more complex controller hardware, you might need292to take care of more processing in those two functions.293 294Returning from the init function, the MUSB controller driver jumps back295into the probe function::296 297 static int jz4740_probe(struct platform_device *pdev)298 {299 ret = platform_device_add(musb);300 if (ret) {301 dev_err(&pdev->dev, "failed to register musb device\n");302 goto err_clk_disable;303 }304 305 return 0;306 307 err_clk_disable:308 clk_disable_unprepare(clk);309 err_platform_device_put:310 platform_device_put(musb);311 return ret;312 }313 314This is the last part of the device registration process where the glue315layer adds the controller hardware device to Linux kernel device316hierarchy: at this stage, all known information about the device is317passed on to the Linux USB core stack:318 319 .. code-block:: c320 :emphasize-lines: 5,6321 322 static int jz4740_remove(struct platform_device *pdev)323 {324 struct jz4740_glue *glue = platform_get_drvdata(pdev);325 326 platform_device_unregister(glue->musb);327 clk_disable_unprepare(glue->clk);328 329 return 0;330 }331 332Acting as the counterpart of probe, the remove function unregister the333MUSB controller hardware (line 5) and disable the clock (line 6),334allowing it to be gated.335 336.. _musb-handling-irqs:337 338Handling IRQs339=============340 341Additionally to the MUSB controller hardware basic setup and342registration, the glue layer is also responsible for handling the IRQs:343 344 .. code-block:: c345 :emphasize-lines: 7,9-11,14,24346 347 static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)348 {349 unsigned long flags;350 irqreturn_t retval = IRQ_NONE;351 struct musb *musb = __hci;352 353 spin_lock_irqsave(&musb->lock, flags);354 355 musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);356 musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);357 musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);358 359 /*360 * The controller is gadget only, the state of the host mode IRQ bits is361 * undefined. Mask them to make sure that the musb driver core will362 * never see them set363 */364 musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |365 MUSB_INTR_RESET | MUSB_INTR_SOF;366 367 if (musb->int_usb || musb->int_tx || musb->int_rx)368 retval = musb_interrupt(musb);369 370 spin_unlock_irqrestore(&musb->lock, flags);371 372 return retval;373 }374 375Here the glue layer mostly has to read the relevant hardware registers376and pass their values on to the controller driver which will handle the377actual event that triggered the IRQ.378 379The interrupt handler critical section is protected by the380:c:func:`spin_lock_irqsave` and counterpart :c:func:`spin_unlock_irqrestore`381functions (line 7 and 24 respectively), which prevent the interrupt382handler code to be run by two different threads at the same time.383 384Then the relevant interrupt registers are read (line 9 to 11):385 386- ``MUSB_INTRUSB``: indicates which USB interrupts are currently active,387 388- ``MUSB_INTRTX``: indicates which of the interrupts for TX endpoints are389 currently active,390 391- ``MUSB_INTRRX``: indicates which of the interrupts for TX endpoints are392 currently active.393 394Note that :c:func:`musb_readb` is used to read 8-bit registers at most, while395:c:func:`musb_readw` allows us to read at most 16-bit registers. There are396other functions that can be used depending on the size of your device397registers. See ``musb_io.h`` for more information.398 399Instruction on line 18 is another quirk specific to the JZ4740 USB400device controller, which will be discussed later in :ref:`musb-dev-quirks`.401 402The glue layer still needs to register the IRQ handler though. Remember403the instruction on line 14 of the init function::404 405 static int jz4740_musb_init(struct musb *musb)406 {407 musb->isr = jz4740_musb_interrupt;408 409 return 0;410 }411 412This instruction sets a pointer to the glue layer IRQ handler function,413in order for the controller hardware to call the handler back when an414IRQ comes from the controller hardware. The interrupt handler is now415implemented and registered.416 417.. _musb-dev-platform-data:418 419Device Platform Data420====================421 422In order to write an MUSB glue layer, you need to have some data423describing the hardware capabilities of your controller hardware, which424is called the platform data.425 426Platform data is specific to your hardware, though it may cover a broad427range of devices, and is generally found somewhere in the ``arch/``428directory, depending on your device architecture.429 430For instance, platform data for the JZ4740 SoC is found in431``arch/mips/jz4740/platform.c``. In the ``platform.c`` file each device of the432JZ4740 SoC is described through a set of structures.433 434Here is the part of ``arch/mips/jz4740/platform.c`` that covers the USB435Device Controller (UDC):436 437 .. code-block:: c438 :emphasize-lines: 2,7,14-17,21,22,25,26,28,29439 440 /* USB Device Controller */441 struct platform_device jz4740_udc_xceiv_device = {442 .name = "usb_phy_gen_xceiv",443 .id = 0,444 };445 446 static struct resource jz4740_udc_resources[] = {447 [0] = {448 .start = JZ4740_UDC_BASE_ADDR,449 .end = JZ4740_UDC_BASE_ADDR + 0x10000 - 1,450 .flags = IORESOURCE_MEM,451 },452 [1] = {453 .start = JZ4740_IRQ_UDC,454 .end = JZ4740_IRQ_UDC,455 .flags = IORESOURCE_IRQ,456 .name = "mc",457 },458 };459 460 struct platform_device jz4740_udc_device = {461 .name = "musb-jz4740",462 .id = -1,463 .dev = {464 .dma_mask = &jz4740_udc_device.dev.coherent_dma_mask,465 .coherent_dma_mask = DMA_BIT_MASK(32),466 },467 .num_resources = ARRAY_SIZE(jz4740_udc_resources),468 .resource = jz4740_udc_resources,469 };470 471The ``jz4740_udc_xceiv_device`` platform device structure (line 2)472describes the UDC transceiver with a name and id number.473 474At the time of this writing, note that ``usb_phy_gen_xceiv`` is the475specific name to be used for all transceivers that are either built-in476with reference USB IP or autonomous and doesn't require any PHY477programming. You will need to set ``CONFIG_NOP_USB_XCEIV=y`` in the478kernel configuration to make use of the corresponding transceiver479driver. The id field could be set to -1 (equivalent to480``PLATFORM_DEVID_NONE``), -2 (equivalent to ``PLATFORM_DEVID_AUTO``) or481start with 0 for the first device of this kind if we want a specific id482number.483 484The ``jz4740_udc_resources`` resource structure (line 7) defines the UDC485registers base addresses.486 487The first array (line 9 to 11) defines the UDC registers base memory488addresses: start points to the first register memory address, end points489to the last register memory address and the flags member defines the490type of resource we are dealing with. So ``IORESOURCE_MEM`` is used to491define the registers memory addresses. The second array (line 14 to 17)492defines the UDC IRQ registers addresses. Since there is only one IRQ493register available for the JZ4740 UDC, start and end point at the same494address. The ``IORESOURCE_IRQ`` flag tells that we are dealing with IRQ495resources, and the name ``mc`` is in fact hard-coded in the MUSB core in496order for the controller driver to retrieve this IRQ resource by497querying it by its name.498 499Finally, the ``jz4740_udc_device`` platform device structure (line 21)500describes the UDC itself.501 502The ``musb-jz4740`` name (line 22) defines the MUSB driver that is used503for this device; remember this is in fact the name that we used in the504``jz4740_driver`` platform driver structure in :ref:`musb-basics`.505The id field (line 23) is set to -1 (equivalent to ``PLATFORM_DEVID_NONE``)506since we do not need an id for the device: the MUSB controller driver was507already set to allocate an automatic id in :ref:`musb-basics`. In the dev field508we care for DMA related information here. The ``dma_mask`` field (line 25)509defines the width of the DMA mask that is going to be used, and510``coherent_dma_mask`` (line 26) has the same purpose but for the511``alloc_coherent`` DMA mappings: in both cases we are using a 32 bits mask.512Then the resource field (line 29) is simply a pointer to the resource513structure defined before, while the ``num_resources`` field (line 28) keeps514track of the number of arrays defined in the resource structure (in this515case there were two resource arrays defined before).516 517With this quick overview of the UDC platform data at the ``arch/`` level now518done, let's get back to the MUSB glue layer specific platform data in519``drivers/usb/musb/jz4740.c``:520 521 .. code-block:: c522 :emphasize-lines: 3,5,7-9,11523 524 static struct musb_hdrc_config jz4740_musb_config = {525 /* Silicon does not implement USB OTG. */526 .multipoint = 0,527 /* Max EPs scanned, driver will decide which EP can be used. */528 .num_eps = 4,529 /* RAMbits needed to configure EPs from table */530 .ram_bits = 9,531 .fifo_cfg = jz4740_musb_fifo_cfg,532 .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg),533 };534 535 static struct musb_hdrc_platform_data jz4740_musb_platform_data = {536 .mode = MUSB_PERIPHERAL,537 .config = &jz4740_musb_config,538 };539 540First the glue layer configures some aspects of the controller driver541operation related to the controller hardware specifics. This is done542through the ``jz4740_musb_config`` :c:type:`musb_hdrc_config` structure.543 544Defining the OTG capability of the controller hardware, the multipoint545member (line 3) is set to 0 (equivalent to false) since the JZ4740 UDC546is not OTG compatible. Then ``num_eps`` (line 5) defines the number of USB547endpoints of the controller hardware, including endpoint 0: here we have5483 endpoints + endpoint 0. Next is ``ram_bits`` (line 7) which is the width549of the RAM address bus for the MUSB controller hardware. This550information is needed when the controller driver cannot automatically551configure endpoints by reading the relevant controller hardware552registers. This issue will be discussed when we get to device quirks in553:ref:`musb-dev-quirks`. Last two fields (line 8 and 9) are also554about device quirks: ``fifo_cfg`` points to the USB endpoints configuration555table and ``fifo_cfg_size`` keeps track of the size of the number of556entries in that configuration table. More on that later in557:ref:`musb-dev-quirks`.558 559Then this configuration is embedded inside ``jz4740_musb_platform_data``560:c:type:`musb_hdrc_platform_data` structure (line 11): config is a pointer to561the configuration structure itself, and mode tells the controller driver562if the controller hardware may be used as ``MUSB_HOST`` only,563``MUSB_PERIPHERAL`` only or ``MUSB_OTG`` which is a dual mode.564 565Remember that ``jz4740_musb_platform_data`` is then used to convey566platform data information as we have seen in the probe function in567:ref:`musb-basics`.568 569.. _musb-dev-quirks:570 571Device Quirks572=============573 574Completing the platform data specific to your device, you may also need575to write some code in the glue layer to work around some device specific576limitations. These quirks may be due to some hardware bugs, or simply be577the result of an incomplete implementation of the USB On-the-Go578specification.579 580The JZ4740 UDC exhibits such quirks, some of which we will discuss here581for the sake of insight even though these might not be found in the582controller hardware you are working on.583 584Let's get back to the init function first:585 586 .. code-block:: c587 :emphasize-lines: 12588 589 static int jz4740_musb_init(struct musb *musb)590 {591 musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);592 if (!musb->xceiv) {593 pr_err("HS UDC: no transceiver configured\n");594 return -ENODEV;595 }596 597 /* Silicon does not implement ConfigData register.598 * Set dyn_fifo to avoid reading EP config from hardware.599 */600 musb->dyn_fifo = true;601 602 musb->isr = jz4740_musb_interrupt;603 604 return 0;605 }606 607Instruction on line 12 helps the MUSB controller driver to work around608the fact that the controller hardware is missing registers that are used609for USB endpoints configuration.610 611Without these registers, the controller driver is unable to read the612endpoints configuration from the hardware, so we use line 12 instruction613to bypass reading the configuration from silicon, and rely on a614hard-coded table that describes the endpoints configuration instead::615 616 static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {617 { .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },618 { .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },619 { .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, },620 };621 622Looking at the configuration table above, we see that each endpoints is623described by three fields: ``hw_ep_num`` is the endpoint number, style is624its direction (either ``FIFO_TX`` for the controller driver to send packets625in the controller hardware, or ``FIFO_RX`` to receive packets from626hardware), and maxpacket defines the maximum size of each data packet627that can be transmitted over that endpoint. Reading from the table, the628controller driver knows that endpoint 1 can be used to send and receive629USB data packets of 512 bytes at once (this is in fact a bulk in/out630endpoint), and endpoint 2 can be used to send data packets of 64 bytes631at once (this is in fact an interrupt endpoint).632 633Note that there is no information about endpoint 0 here: that one is634implemented by default in every silicon design, with a predefined635configuration according to the USB specification. For more examples of636endpoint configuration tables, see ``musb_core.c``.637 638Let's now get back to the interrupt handler function:639 640 .. code-block:: c641 :emphasize-lines: 18-19642 643 static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)644 {645 unsigned long flags;646 irqreturn_t retval = IRQ_NONE;647 struct musb *musb = __hci;648 649 spin_lock_irqsave(&musb->lock, flags);650 651 musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);652 musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);653 musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);654 655 /*656 * The controller is gadget only, the state of the host mode IRQ bits is657 * undefined. Mask them to make sure that the musb driver core will658 * never see them set659 */660 musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |661 MUSB_INTR_RESET | MUSB_INTR_SOF;662 663 if (musb->int_usb || musb->int_tx || musb->int_rx)664 retval = musb_interrupt(musb);665 666 spin_unlock_irqrestore(&musb->lock, flags);667 668 return retval;669 }670 671Instruction on line 18 above is a way for the controller driver to work672around the fact that some interrupt bits used for USB host mode673operation are missing in the ``MUSB_INTRUSB`` register, thus left in an674undefined hardware state, since this MUSB controller hardware is used in675peripheral mode only. As a consequence, the glue layer masks these676missing bits out to avoid parasite interrupts by doing a logical AND677operation between the value read from ``MUSB_INTRUSB`` and the bits that678are actually implemented in the register.679 680These are only a couple of the quirks found in the JZ4740 USB device681controller. Some others were directly addressed in the MUSB core since682the fixes were generic enough to provide a better handling of the issues683for others controller hardware eventually.684 685Conclusion686==========687 688Writing a Linux MUSB glue layer should be a more accessible task, as689this documentation tries to show the ins and outs of this exercise.690 691The JZ4740 USB device controller being fairly simple, I hope its glue692layer serves as a good example for the curious mind. Used with the693current MUSB glue layers, this documentation should provide enough694guidance to get started; should anything gets out of hand, the linux-usb695mailing list archive is another helpful resource to browse through.696 697Acknowledgements698================699 700Many thanks to Lars-Peter Clausen and Maarten ter Huurne for answering701my questions while I was writing the JZ4740 glue layer and for helping702me out getting the code in good shape.703 704I would also like to thank the Qi-Hardware community at large for its705cheerful guidance and support.706 707Resources708=========709 710USB Home Page: https://www.usb.org711 712linux-usb Mailing List Archives: https://marc.info/?l=linux-usb713 714USB On-the-Go Basics:715https://www.maximintegrated.com/app-notes/index.mvp/id/1822716 717:ref:`Writing USB Device Drivers <writing-usb-driver>`718 719Texas Instruments USB Configuration Wiki Page:720https://web.archive.org/web/20201215135015/http://processors.wiki.ti.com/index.php/Usbgeneralpage721