| Message ID | 20200505162607.334-1-nsaenzjulienne@suse.de |
|---|---|
| Headers | show |
| Series | usb: xhci: Load Raspberry Pi 4 VL805's firmware | expand |
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. > > --- Just for the record, here's the version of this in the Linux Kernel: https://patchwork.kernel.org/cover/11529585/ Regards, Nicolas
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 Regards, Nicolas
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. Also, it seems there was a lengthy ongoing discussion, is that already sorted out ?
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. Regards, Nicolas
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 ?
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
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.
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
On 6/4/20 1:18 PM, Nicolas Saenz Julienne wrote: > 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 :). I think it should be OK, thanks.