On 6/1/20 4:41 PM, Nicolas Saenz Julienne wrote:
On Mon, 2020-06-01 at 13:12 +0200, Marek Vasut wrote:
On 6/1/20 1:09 PM, Nicolas Saenz Julienne wrote:
On Mon, 2020-06-01 at 12:53 +0200, Marek Vasut wrote:
On 6/1/20 12:47 PM, Nicolas Saenz Julienne wrote:
On Tue, 2020-05-05 at 18:26 +0200, Nicolas Saenz Julienne wrote:
Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be loaded explicitly. Earlier versions didn't need that as they where using an EEPROM for that purpose. This series takes care of setting up the relevant infrastructure and run the firmware loading routine at the right moment.
Note that this builds on top of Sylwester Nawrocki's "USB host support for Raspberry Pi 4 board" series.
Please don't forget about this series. The new 8GB RPi4 contains this HW design change and USB will not work without it. See this discussion on the downstream kernel github, where other OS/bootloaders are hitting the issue:
https://github.com/raspberrypi/firmware/issues/1402
Otherwise, the Linux version of this is already in linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/d...
We're already at 2020.07-rc3 , so unless this is a bugfix (does not look that way), this will have to wait for next release cycle.
Of course. As long as it eventually gets in I'm happy (not implying this specific series is flawless, but the overall mechanism). I'm just worried this gets lost.
Also, it seems there was a lengthy ongoing discussion, is that already sorted out ?
Well, there was some discussion on how to incorporate the platform specific callback into XCHI's code. Which this revision of the series addresses. But, IIRC, that's pretty much it as far as discussion is concerned.
Oh, right, since the firmware loading hook looks like a reset hook, why isn't that implemented via reset controller API instead ?
That could be pretty clean, I hadn't though about it that way. Some questions:
- Being a PCIe device the XHCI controller doesn't show up in the device-tree. I guess it could be added as a child node of pcie-brcmstb, but is that even acceptable?
Yes, there are other such DTs .
- Same goes for xhci-pci being a consumer of the reset controller. Given the reset scheme is board specific (the chip can be found all over the place, but the firmware loading scheme is 100% RPi specific), to what extent we can introduce that as a binding?
I'm not sure what you're asking me here, you'll just have some reset controller in a DT and a phandle from the xhci-controller to this reset controller.