What does "dtoverlay=dwc2" REALLY do?

Question

Please don't point me to what it is used for, there are plenty of articles telling me how to make my Pi Zero an ethernet gadget.

Putting "dtoverlay=dwc2" into /boot/config.txt appears to fix a known issue with a CH340 Usb to Serial device (arduino clone) and yet when the wifi is disconnected it seems to eat up the processor!!! This doesn't make sense to me.

My setup is: RPi Zero connected to USB hub using an OTG cable then on to an Arduino Nano Clone (CH340) to make the Arduino the slave. Also in the hub is a Wifi thingy. The Pi is also connected to buttons, leds and an lcd display over I2C. EDIT: The hub is only powered from the pi and draws 100ma (peak 140ma) for itself, the wifi and the arduino.

Scenario 1: 'dwc2' in config.txt, arduino connected, wifi working. => Great! All works as expected.

Scenario 2: same as scenario 1 but wifi access point is off. => No remote access obviously. Wierd behaviour which makes me think that 99.9% of the processor is eaten up somewhere. The LCD updates a letter at a time and python asheduler tells me its missing its cron times by anywhere up to a minute. Usual service is resumed when the wifi is reconnected.

Scenario 3: 'dwc2' NOT in config.txt => All works except Arduino clone which gives the usual "usb_serial_generic_read_bulk_callback - urb stopped: -32" in dmesg. This behaviour is somehow FIXED in scenario 1. (and 2)

Any ideas?

If I could keep dwc2 but stop it freaking out without wifi connected then I wouldn't need to fix the issue with the clone.

Edit: ideally I'd like to be told exactly why dwc2 appears to fix a driver issue yet hammers the processor (unconfirmed) when there is no network connection. I suspect that dwc2 is trying to use the CH340 to route network traffic when the wifi is down, but as I have no information as to the workings of dwc2, this is merely a guess. Information as to what it does functionally may help to diagnose this eg the stty parameters that it appears to change are: "min = 0 -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke" with dwc2, "min = 1 icrnl ixon opost onlcr isig icanon iexten echo echoe echok echoctl echoke" without, though this alone does not make the dmesg errors go away. The command "lsusb -d1a86:7523 -v" gives exactly the same result in all scenario, so for example the USB speed is unchanged. It is rumoured that forcing the device to run at USB1.1 makes it work, but this isn't happening here.

To give context, if I asked 'how does the pi boot', I would be given a detailed list of events from first reading the SD card, through init and rc.local, run level 0 to agetty providing a login prompt. I am looking for a similar description.

Answer 1

The answer to your question title has been hard to word better than gregeric explained:

dwc_otg is the driver that has been heavily patched to squeeze most performance & function in host mode on the Pi: the fiq stuff etc. So heavily patched that, despite the name, it only does host mode & not OTG.

dwc2 is an upstream driver which can do the OTG host/gadget flip dictated by OTG_SENSE. In host mode performance will pale cf dwc_otg, hence it's only recommended for gadget mode.

Thus, you should expect very different performance (and bugs) with the two drivers.

DWC stands for (Synopsys) DesignWare Core, for which there are multiple versions of the hardware IP and software (e.g. dwc3).

While you could delve into the dwc driver kernel code to truly rootcause the behavior with your Arduino Clone, it sounds like you're okay falling back to Scenario 1? Assuming the WiFi is always available.

Edit, re:

To give context, if I asked 'how does the pi boot', I would be given a detailed list of events from first reading the SD card, through init and rc.local, run level 0 to agetty providing a login prompt. I am looking for a similar description.

It would be hard to do justice here for 650 pages of the USB 2.0 spec. Broadly speaking, both drivers implement everything up to the protocol layer (enumeration, control/bulk/isochronous/interrupt transfers) for USB 1.1 and USB 2.0.

The source code for dwc_otg with FIQ enhancements is more than 45000 lines. Apparently the source code for dwc2 is only about 22000 lines, despite also providing working support for gadgets (OTG).

USB device driver code such as serial/generic.c (where usb_serial_generic_read_bulk_callback() is implemented) is abstracted at a higher level, and not tied to Synopsys DWC or any particular USB IP.

Answer 2

It is extremely likely that you are asking the wrong question. If dwc2 appears to fix some issue for you, try methodically changing to alternative hardware. jdonald has already pointed out the scale of the problem of managing to effectively answer the question. Unless you really understand USB at its very lowest level or have many, many hours to spend on this, you need to look elsewhere. I have already spent far too long on this.

I (the original poster) solved my underlying problem by swapping out hardware until I found a solution. FWIW a USB hub with ID 214b:7000 did not work with a HL-340 serial adapter until dwc2 somehow fixed it, hence the question. I'm using a different hub now and I'll probably never know why dwc2 fixed the incompatibility. Thanks jdonald for your answer. I wish I had listened!