On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
loaded directly from an EEPROM or, if not present, by the SoC's
VideoCore. Inform VideoCore that VL805 was just reset.
Also, as this creates a dependency between USB_PCI and VideoCore's
firmware interface, and since USB_PCI can't be set as a module neither
this can. Reflect that on the firmware interface Kconfg.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
---
Changes since v5:
- Fix Kconfig issue with allmodconfig
Changes since v4:
- Do not split up error message
Changes since v3:
- Add more complete error message
Changes since v1:
- Make RASPBERRYPI_FIRMWARE dependent on this quirk to make sure it
gets compiled when needed.
drivers/firmware/Kconfig | 3 ++-
drivers/usb/host/pci-quirks.c | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 8007d4aa76dc..b42140cff8ac 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -178,8 +178,9 @@ config ISCSI_IBFT
Otherwise, say N.
config RASPBERRYPI_FIRMWARE
- tristate "Raspberry Pi Firmware Driver"
+ bool "Raspberry Pi Firmware Driver"
depends on BCM2835_MBOX
+ default USB_PCI
help
This option enables support for communicating with the firmware on the
Raspberry Pi.
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 92150ecdb036..0b949acfa258 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,6 +16,9 @@
#include <linux/export.h>
#include <linux/acpi.h>
#include <linux/dmi.h>
+
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
#include "pci-quirks.h"
#include "xhci-ext-caps.h"
@@ -1243,11 +1246,24 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
static void quirk_usb_early_handoff(struct pci_dev *pdev)
{
+ int ret;
+
/* Skip Netlogic mips SoC's internal PCI USB controller.
* This device does not need/support EHCI/OHCI handoff
*/
if (pdev->vendor == 0x184e) /* vendor Netlogic */
return;
+
+ if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
+ ret = rpi_firmware_init_vl805(pdev);
+ if (ret) {
+ /* Firmware might be outdated, or something failed */
+ dev_warn(&pdev->dev,
+ "Failed to load VL805's firmware: %d. Will continue to attempt to work, but bad things might happen. You should fix this...\n",
+ ret);
+ }
+ }
+
if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
--
2.26.2
On Tue, 5 May 2020 18:13:17 +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> VideoCore. Inform VideoCore that VL805 was just reset.
>
> Also, as this creates a dependency between USB_PCI and VideoCore's
> firmware interface, and since USB_PCI can't be set as a module neither
> this can. Reflect that on the firmware interface Kconfg.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
>
> Changes since v5:
> - Fix Kconfig issue with allmodconfig
>
> Changes since v4:
> - Do not split up error message
>
> Changes since v3:
> - Add more complete error message
>
> Changes since v1:
> - Make RASPBERRYPI_FIRMWARE dependent on this quirk to make sure it
> gets compiled when needed.
>
> drivers/firmware/Kconfig | 3 ++-
> drivers/usb/host/pci-quirks.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <[email protected]>
On Tue, May 05, 2020 at 06:13:17PM +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> VideoCore. Inform VideoCore that VL805 was just reset.
>
> Also, as this creates a dependency between USB_PCI and VideoCore's
> firmware interface, and since USB_PCI can't be set as a module neither
> this can. Reflect that on the firmware interface Kconfg.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
>
> Changes since v5:
> - Fix Kconfig issue with allmodconfig
>
> Changes since v4:
> - Do not split up error message
>
> Changes since v3:
> - Add more complete error message
>
> Changes since v1:
> - Make RASPBERRYPI_FIRMWARE dependent on this quirk to make sure it
> gets compiled when needed.
>
> drivers/firmware/Kconfig | 3 ++-
> drivers/usb/host/pci-quirks.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+), 1 deletion(-)
Hi Mathias,
I would need your ACK to merge this series, thanks.
Lorenzo
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 8007d4aa76dc..b42140cff8ac 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -178,8 +178,9 @@ config ISCSI_IBFT
> Otherwise, say N.
>
> config RASPBERRYPI_FIRMWARE
> - tristate "Raspberry Pi Firmware Driver"
> + bool "Raspberry Pi Firmware Driver"
> depends on BCM2835_MBOX
> + default USB_PCI
> help
> This option enables support for communicating with the firmware on the
> Raspberry Pi.
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 92150ecdb036..0b949acfa258 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -16,6 +16,9 @@
> #include <linux/export.h>
> #include <linux/acpi.h>
> #include <linux/dmi.h>
> +
> +#include <soc/bcm2835/raspberrypi-firmware.h>
> +
> #include "pci-quirks.h"
> #include "xhci-ext-caps.h"
>
> @@ -1243,11 +1246,24 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>
> static void quirk_usb_early_handoff(struct pci_dev *pdev)
> {
> + int ret;
> +
> /* Skip Netlogic mips SoC's internal PCI USB controller.
> * This device does not need/support EHCI/OHCI handoff
> */
> if (pdev->vendor == 0x184e) /* vendor Netlogic */
> return;
> +
> + if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
> + ret = rpi_firmware_init_vl805(pdev);
> + if (ret) {
> + /* Firmware might be outdated, or something failed */
> + dev_warn(&pdev->dev,
> + "Failed to load VL805's firmware: %d. Will continue to attempt to work, but bad things might happen. You should fix this...\n",
> + ret);
> + }
> + }
> +
> if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
> pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
> pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
> --
> 2.26.2
>
On 11.5.2020 17.25, Lorenzo Pieralisi wrote:
> On Tue, May 05, 2020 at 06:13:17PM +0200, Nicolas Saenz Julienne wrote:
>> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
>> loaded directly from an EEPROM or, if not present, by the SoC's
>> VideoCore. Inform VideoCore that VL805 was just reset.
>>
>> Also, as this creates a dependency between USB_PCI and VideoCore's
>> firmware interface, and since USB_PCI can't be set as a module neither
>> this can. Reflect that on the firmware interface Kconfg.
>>
>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>> ---
>>
>> Changes since v5:
>> - Fix Kconfig issue with allmodconfig
>>
>> Changes since v4:
>> - Do not split up error message
>>
>> Changes since v3:
>> - Add more complete error message
>>
>> Changes since v1:
>> - Make RASPBERRYPI_FIRMWARE dependent on this quirk to make sure it
>> gets compiled when needed.
>>
>> drivers/firmware/Kconfig | 3 ++-
>> drivers/usb/host/pci-quirks.c | 16 ++++++++++++++++
>> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> Hi Mathias,
>
> I would need your ACK to merge this series, thanks.
>
> Lorenzo
Ah, yes, of course
Acked-by: Mathias Nyman <[email protected]>
On Tue, 2020-05-05 at 18:13 +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> VideoCore. Inform VideoCore that VL805 was just reset.
>
> Also, as this creates a dependency between USB_PCI and VideoCore's
> firmware interface, and since USB_PCI can't be set as a module neither
> this can. Reflect that on the firmware interface Kconfg.
>
> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
> ---
It was pointed out to me on the u-boot mailing lists that all this could be
implemented trough a reset controller. In other words have xhci get the reset
controller trough device-tree, assert it, ultamately causing the firmware
routine to be run.
As much as it pains me to go over stuff that's already 'fixed', it seems to me
it's a better solution. On one hand we get over the device-tree dependency mess
(see patch #3), and on the other we transform a pci-quirk into something less
hacky.
That said, before getting my hands dirty, I was wondering if there is any
obvious reasons why I shouldn't do this, note that:
- We're talking here of a PCIe XCHI device, maybe there's an issue integrating
it with DT, given the fact that, as of today, it's not really represented
there.
- There is no reset controller support in xhci-pci, maybe there are good
reasons why. For instance, it's not something that's reflected in any way in
the spec.
Regards,
Nicolas
>
> Changes since v5:
> - Fix Kconfig issue with allmodconfig
>
> Changes since v4:
> - Do not split up error message
>
> Changes since v3:
> - Add more complete error message
>
> Changes since v1:
> - Make RASPBERRYPI_FIRMWARE dependent on this quirk to make sure it
> gets compiled when needed.
>
> drivers/firmware/Kconfig | 3 ++-
> drivers/usb/host/pci-quirks.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 8007d4aa76dc..b42140cff8ac 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -178,8 +178,9 @@ config ISCSI_IBFT
> Otherwise, say N.
>
> config RASPBERRYPI_FIRMWARE
> - tristate "Raspberry Pi Firmware Driver"
> + bool "Raspberry Pi Firmware Driver"
> depends on BCM2835_MBOX
> + default USB_PCI
> help
> This option enables support for communicating with the firmware on the
> Raspberry Pi.
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index 92150ecdb036..0b949acfa258 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -16,6 +16,9 @@
> #include <linux/export.h>
> #include <linux/acpi.h>
> #include <linux/dmi.h>
> +
> +#include <soc/bcm2835/raspberrypi-firmware.h>
> +
> #include "pci-quirks.h"
> #include "xhci-ext-caps.h"
>
> @@ -1243,11 +1246,24 @@ static void quirk_usb_handoff_xhci(struct pci_dev
> *pdev)
>
> static void quirk_usb_early_handoff(struct pci_dev *pdev)
> {
> + int ret;
> +
> /* Skip Netlogic mips SoC's internal PCI USB controller.
> * This device does not need/support EHCI/OHCI handoff
> */
> if (pdev->vendor == 0x184e) /* vendor Netlogic */
> return;
> +
> + if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
> + ret = rpi_firmware_init_vl805(pdev);
> + if (ret) {
> + /* Firmware might be outdated, or something failed */
> + dev_warn(&pdev->dev,
> + "Failed to load VL805's firmware: %d. Will
> continue to attempt to work, but bad things might happen. You should fix
> this...\n",
> + ret);
> + }
> + }
> +
> if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
> pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
> pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
On 6/2/2020 3:05 AM, Nicolas Saenz Julienne wrote:
> On Tue, 2020-05-05 at 18:13 +0200, Nicolas Saenz Julienne wrote:
>> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
>> loaded directly from an EEPROM or, if not present, by the SoC's
>> VideoCore. Inform VideoCore that VL805 was just reset.
>>
>> Also, as this creates a dependency between USB_PCI and VideoCore's
>> firmware interface, and since USB_PCI can't be set as a module neither
>> this can. Reflect that on the firmware interface Kconfg.
>>
>> Signed-off-by: Nicolas Saenz Julienne <[email protected]>
>> ---
>
> It was pointed out to me on the u-boot mailing lists that all this could be
> implemented trough a reset controller. In other words have xhci get the reset
> controller trough device-tree, assert it, ultamately causing the firmware
> routine to be run.
That is actually a clever way to solve that problem.
>
> As much as it pains me to go over stuff that's already 'fixed', it seems to me
> it's a better solution. On one hand we get over the device-tree dependency mess
> (see patch #3), and on the other we transform a pci-quirk into something less
> hacky.
>
> That said, before getting my hands dirty, I was wondering if there is any
> obvious reasons why I shouldn't do this, note that:
>
> - We're talking here of a PCIe XCHI device, maybe there's an issue integrating
> it with DT, given the fact that, as of today, it's not really represented
> there.
You can always provide a PCIe device representation within the Device
Tree, this is not very common, but it is sometimes useful for e.g.:
assigning MAC addresses, see this example for instance:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi#n647
(does not assign a MAC address, but it could). This should allow your
XHCI pci_device::of_node pointer to point to node declared in the Device
Tree. There you could add a 'resets' property accordingly.
>
> - There is no reset controller support in xhci-pci, maybe there are good
> reasons why. For instance, it's not something that's reflected in any way in
> the spec.
It seems to me this is not usually necessary for PC systems, so it was
not really needed until now. Maybe you can write a small wrapper around
xhci-pci.c, similar to what xhci-plat.c does which is responsible for
grabbing and releasing the reset.
--
Florian