| Message ID | 20200505161318.26200-5-nsaenzjulienne@suse.de |
|---|---|
| State | New |
| Headers | show |
| Series | USB: pci-quirks: Add Raspberry Pi 4 quirk | expand |
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 <nsaenzjulienne@suse.de> > --- > > 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 <robh@kernel.org>
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 <nsaenzjulienne@suse.de> > --- > > 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 <nsaenzjulienne@suse.de> >> --- >> >> 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 <mathias.nyman@linux.intel.com>
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 <nsaenzjulienne@suse.de> > --- 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 <nsaenzjulienne@suse.de> >> --- > > 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.
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 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 <nsaenzjulienne@suse.de> --- 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(-)