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

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

[Nicolas Saenz Julienne]

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(+)

-- 
2.26.2

[PATCH v3 1/2] arm: rpi: Add function to trigger VL805's firmware load

[Nicolas Saenz Julienne]

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;
+}
+
-- 
2.26.2

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

[Nicolas Saenz Julienne]

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_ */
-- 
2.26.2

Re: [PATCH v3 1/2] arm: rpi: Add function to trigger VL805's firmware load

[Bin Meng]

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

Re: [PATCH v3 1/2] arm: rpi: Add function to trigger VL805's firmware load

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marek Vasut]

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 ?

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

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marek Vasut]

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 ?

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

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marek Vasut]

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.

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

[Nicolas Saenz Julienne]

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marek Vasut]

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.