Messages in this thread | | | Subject | Re: [PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware | From | Marek Vasut <> | Date | Mon, 1 Jun 2020 13:12:50 +0200 |
| |
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 ?
| |