[PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware
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.
---
Note: this was tested on both rpi_arm64_defconfig on both rpi3 & rpi4.
Changes since v2: - Correct comment on patch #1 - Address Matthias' comments
Changes since v1: - Rename function - Use callback in xhci-pci.c
Nicolas Saenz Julienne (2): arm: rpi: Add function to trigger VL805's firmware load usb: xhci: Load Raspberry Pi 4 VL805's firmware
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++++++ arch/arm/mach-bcm283x/include/mach/msg.h | 7 ++++ arch/arm/mach-bcm283x/msg.c | 45 +++++++++++++++++++++++ board/raspberrypi/rpi/rpi.c | 6 +++ drivers/usb/host/xhci-pci.c | 6 +++ include/usb/xhci.h | 3 ++ 6 files changed, 80 insertions(+)
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideCore (the SoC's co-processor). Introduce the function that informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de
--- Changes since v2: - Correct wrong function name in comment - Add better comment on rpi_firmware_init_vl805()
Changes since v1: - Rename function so it's not mistaken with regular firmware loading
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++++++ arch/arm/mach-bcm283x/include/mach/msg.h | 7 ++++ arch/arm/mach-bcm283x/msg.c | 45 +++++++++++++++++++++++ 3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h b/arch/arm/mach-bcm283x/include/mach/mbox.h index 60e226ce1d..2ae2d3d97c 100644 --- a/arch/arm/mach-bcm283x/include/mach/mbox.h +++ b/arch/arm/mach-bcm283x/include/mach/mbox.h @@ -491,6 +491,19 @@ struct bcm2835_mbox_tag_set_palette { } body; };
+#define BCM2835_MBOX_TAG_NOTIFY_XHCI_RESET 0x00030058 + +struct bcm2835_mbox_tag_pci_dev_addr { + struct bcm2835_mbox_tag_hdr tag_hdr; + union { + struct { + u32 dev_addr; + } req; + struct { + } resp; + } body; +}; + /* * Pass a raw u32 message to the VC, and receive a raw u32 back. * diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h b/arch/arm/mach-bcm283x/include/mach/msg.h index 4afb08631b..f5213dd0e0 100644 --- a/arch/arm/mach-bcm283x/include/mach/msg.h +++ b/arch/arm/mach-bcm283x/include/mach/msg.h @@ -48,4 +48,11 @@ int bcm2835_set_video_params(int *widthp, int *heightp, int depth_bpp, int pixel_order, int alpha_mode, ulong *fb_basep, ulong *fb_sizep, int *pitchp);
+/** + * bcm2711_notify_vl805_reset() - get vl805's firmware loaded + * + * @return 0 if OK, -EIO on error + */ +int bcm2711_notify_vl805_reset(void); + #endif diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c index 94b75283f8..f8ef531652 100644 --- a/arch/arm/mach-bcm283x/msg.c +++ b/arch/arm/mach-bcm283x/msg.c @@ -40,6 +40,12 @@ struct msg_setup { u32 end_tag; };
+struct msg_notify_vl805_reset { + struct bcm2835_mbox_hdr hdr; + struct bcm2835_mbox_tag_pci_dev_addr dev_addr; + u32 end_tag; +}; + int bcm2835_power_on_module(u32 module) { ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1); @@ -151,3 +157,42 @@ int bcm2835_set_video_params(int *widthp, int *heightp, int depth_bpp,
return 0; } + +/* + * The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip that + * implements xHCI. After a PCI reset, VL805's firmware may either be loaded + * directly from an EEPROM or, if not present, by the SoC's co-processor, + * VideoCore. RPi4's VideoCore OS contains both the non public firmware load + * logic and the VL805 firmware blob. This function triggers the aforementioned + * process. + */ +int bcm2711_notify_vl805_reset(void) +{ + ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset, + msg_notify_vl805_reset, 1); + int ret; + + BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset); + BCM2835_MBOX_INIT_TAG(&msg_notify_vl805_reset->dev_addr, + NOTIFY_XHCI_RESET); + + /* + * The pci device address is expected like this: + * + * PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12 + * + * But since RPi4's PCIe setup is hardwired, we know the address in + * advance. + */ + msg_notify_vl805_reset->dev_addr.body.req.dev_addr = 0x100000; + + ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, + &msg_notify_vl805_reset->hdr); + if (ret) { + printf("bcm2711: Faild to load vl805's firmware, %d\n", ret); + return -EIO; + } + + return 0; +} +
Hi Nicolas,
On Wed, May 6, 2020 at 12:26 AM Nicolas Saenz Julienne nsaenzjulienne@suse.de wrote:
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideCore (the SoC's co-processor). Introduce the function that informs VideCore that VL805 may need its firmware loaded.
I still did not get it. Without the firmware being loaded, does xHCI on RPi 4 still work? What exact functionality does the firmware provide?
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de
Changes since v2:
- Correct wrong function name in comment
- Add better comment on rpi_firmware_init_vl805()
Changes since v1:
- Rename function so it's not mistaken with regular firmware loading
arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++++++ arch/arm/mach-bcm283x/include/mach/msg.h | 7 ++++ arch/arm/mach-bcm283x/msg.c | 45 +++++++++++++++++++++++ 3 files changed, 65 insertions(+)
Regards, Bin
Hi Bin,
On Wed, 2020-05-06 at 13:33 +0800, Bin Meng wrote:
Hi Nicolas,
On Wed, May 6, 2020 at 12:26 AM Nicolas Saenz Julienne nsaenzjulienne@suse.de wrote:
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideCore (the SoC's co-processor). Introduce the function that informs VideCore that VL805 may need its firmware loaded.
I still did not get it. Without the firmware being loaded, does xHCI on RPi 4 still work?
On newer revisions of RPi4, no, it will not work.
What exact functionality does the firmware provide?
It provides xHCI functionality.
The old RPi4 design loaded this vl805 firmware trough a dedicated EEPROM memory. But they removed it, probably in order to save costs. They then created this new interface to trigger a firmware load from RPi4's co-processor.
Regards, Nicolas
When needed, RPi4's co-processor (called VideoCore) has to be instructed to load VL805's firmware (the chip providing xHCI support). VideCore's firmware expects the board's PCIe bus to be already configured in order for it to load the xHCI chip firmware. So we have to make sure this happens in between the PCIe configuration and xHCI startup.
Introduce a callback in xhci_pci_probe() to run this platform specific routine.
Signed-off-by: Nicolas Saenz Julienne nsaenzjulienne@suse.de
---
Changes since v2: - Get rid of #ifdef CONFIG_BCM2711 - Get rid of redundant error message
Changes since v1: - Create callback
board/raspberrypi/rpi/rpi.c | 6 ++++++ drivers/usb/host/xhci-pci.c | 6 ++++++ include/usb/xhci.h | 3 +++ 3 files changed, 15 insertions(+)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c index e367ba3092..dcaf45fbf2 100644 --- a/board/raspberrypi/rpi/rpi.c +++ b/board/raspberrypi/rpi/rpi.c @@ -14,6 +14,7 @@ #include <lcd.h> #include <memalign.h> #include <mmc.h> +#include <usb/xhci.h> #include <asm/gpio.h> #include <asm/arch/mbox.h> #include <asm/arch/msg.h> @@ -494,3 +495,8 @@ int ft_board_setup(void *blob, bd_t *bd)
return 0; } + +void xhci_pci_fixup(struct udevice *dev) +{ + bcm2711_notify_vl805_reset(); +} diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index c1f60da541..1285dde1ef 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -11,6 +11,10 @@ #include <usb.h> #include <usb/xhci.h>
+__weak void xhci_pci_fixup(struct udevice *dev) +{ +} + static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr, struct xhci_hcor **ret_hcor) { @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev) struct xhci_hccr *hccr; struct xhci_hcor *hcor;
+ xhci_pci_fixup(dev); + xhci_pci_init(dev, &hccr, &hcor);
return xhci_register(dev, hccr, hcor); diff --git a/include/usb/xhci.h b/include/usb/xhci.h index c16106a2fc..57feed7603 100644 --- a/include/usb/xhci.h +++ b/include/usb/xhci.h @@ -16,6 +16,7 @@ #ifndef HOST_XHCI_H_ #define HOST_XHCI_H_
+#include <usb.h> #include <asm/types.h> #include <asm/cache.h> #include <asm/io.h> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
+extern void xhci_pci_fixup(struct udevice *dev); + #endif /* HOST_XHCI_H_ */
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/d...
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/d...
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/d...
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/d...
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/d...
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/d...
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/d...
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/d...
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.
participants (3)
-
Bin Meng -
Marek Vasut -
Nicolas Saenz Julienne