ARM: mvebu: Enable XHCI on the Armada 385 AP
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest posting 3/30 of 3 patches 0 repliesNew
- v2 posting 2/30 of 3 patches 0 repliesSuperseded
- v2 posting 1/30 of 3 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v1 | 2 patches | 0 replies | Superseded |
Patches in v2 posting 3/3 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/3] ARM: mvebu: Enable XHCI on the Armada 385 AP
Quoted 33 lines · Maxime Ripard
Hi Andrew,
Quoted 30 lines · Andrew Lunn
Quoted 19 lines · Maxime Ripard
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
Quoted 3 lines
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Hi Maxime
I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.
Quoted 6 lines
Quoted 1 line
What route do you think the other patches will take?
There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree.
Hi Maxime
Humm, maybe i'm wrong, but i think
arch/arm/boot/dts/armada-385-db-ap.dts
only exists in the mvebu tree?
At least, i don't see it here:
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next
Andrew