[PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

On Mon, 2020-06-01 at 17:27 +0200, Marek Vasut wrote:
> 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/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?
> 
> 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.

Sorry I wasn't clear, overall my concern here is that xhic-pci maintainers,
both in u-boot y linux (as I'd like to have the same solution on both sides,
since it involves changes in dt), might see it as too platform specific to add
it into an otherwise generic xhci-pci implmentation.

But nevermind, I'll just post the series and see what happens :).

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200604/6a3f9c47/attachment.sig>