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/drivers/usb/host/pci-quirks.c?h=next-20200529&id=c65822fef4adc0ba40c37a47337376ce75f7a7bc > > > 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? - 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? Regards, Nicolas
signature.asc
Description: This is a digitally signed message part
