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

From: Marek Vasut
Date: Mon Jun 01 2020 - 11:27:22 EST

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:
>>>>> Otherwise, the Linux version of this is already in linux-next:
>>>> 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