by kilian » Thu Aug 17, 2017 12:18 pm
I think I figured it out.
$this->bbcode_second_pass_quote('bulletmark', 'T')he problem is fixed with yesterday's update of linux-am33x to 4.12.7-2. My BB now reboots fine. Fix seems to be to compile the tps65217_charger module in to the kernel as per
https://archlinuxarm.org/packages/armv7 ... 037182101b.
While that suppresses the problem for now, I would not really call it a fix. The issue is now shifted to the USB driver. Are you using the peripheral USB port (usb0, the one that can be used to power the board)? Is it still working?
The problem seems to be that the TPS65217's USB IRQ is being claimed by two different drivers,
tps65217-charger and
vbus (for the USB infrastructure).
https://github.com/torvalds/linux/commit/d680414d0f421563a9746c29d82e6794a604cf0c introduced an attempt to use the interrupt that the TPS generates when it senses a change in the USB power in order for the USB driver to be notified when a USB cable is plugged in.
As the USB drivers were built-in and the TPS driver used to be a module, its IRQ register request came after the one of
vbus and failed. While it should have handled this error gracefully, it obviously didn't and got stuck.
Now that the
tps65217-charger driver is compiled in as well, coincidentally it is being executed before the USB driver initialization, so the IRQ registration succeeds while the USB driver fails.
You should be seeing something like this in your kernel debug messages:
$this->bbcode_second_pass_code('', '
[ 3.336879] genirq: Flags mismatch irq 188. 00002000 (vbus) vs. 00000000 (tps65217-charger)
[ 3.345587] musb-dsps: probe of 47401400.usb failed with error -16
')
As a result, the driver for the usb0 port controller
musb-hdrc.0 is unusable.
My solution for now is to patch the device-tree in order to undo the aforementioned commit d680414.
This makes sure the usb0 stays usable and also should enable the use of older kernel packages (prior to 4.12.7-2).
I tested it on 4.12.5-1, which works fine.
So, if you can live without usb0 you shouldn't have to do anything, but if you are experiencing problems with usb0 or want to use older kernel packages, patching the device-tree could be considered as a solution.
Nonetheless, this is still just a workaround until kernel developers have figured out how to share the interrupt between both drivers.