| Message ID | 20200629161845.6021-1-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Raspberry Pi 4 USB firmware initialization rework | expand |
Hi everyone. On Mon, 2020-06-29 at 18:18 +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 > co-processor, VideoCore. This series reworks how we handle this. > > The previous solution makes use of PCI quirks and exporting platform > specific functions. Albeit functional it feels pretty shoehorned. This > proposes an alternative way of handling the triggering of the xHCI chip > initialization trough means of a reset controller. > > The benefits are pretty evident: less platform churn in core xHCI code, > and no explicit device dependency management in pcie-brcmstb. > > Note that patch #1 depends on another series[1], that was just applied > into the clk maintainer's tree. > > The series is based on v5.8-rc3 > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html > v2: https://lkml.org/lkml/2020/6/9/875 > v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t > > [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t > > --- We were waiting on a dependency to be merged upstream to get this. They are now in, so could we move things forward? I can take the device tree patches, I guess philipp can take the reset controller code. But I'm not so sure who should be taking the PCI/USB counterparts. Regards, Nicolas > > Changes since v4: > - Adress Andy's comments > > Changes since v3: > - Rework dt patch to include root bridge as a separate node > - Update xhci-pci patch now that the xhci dev has a dt node (it was > getting it in the past from its bus) > > Changes since v2: > - Add reset to resume routine in xhci-pci > - Correct of refcount in pci-quirks > - Correct typos > - Use include file to define firmware reset IDs > > Changes since v1: > - Rework reset controller so it's less USB centric > - Use correct reset controller API in xhci-pci > - Correct typos > > Nicolas Saenz Julienne (9): > dt-bindings: reset: Add a binding for the RPi Firmware reset > controller > reset: Add Raspberry Pi 4 firmware reset controller > ARM: dts: bcm2711: Add firmware usb reset node > ARM: dts: bcm2711: Add reset controller to xHCI node > usb: xhci-pci: Add support for reset controllers > Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk" > usb: host: pci-quirks: Bypass xHCI quirks for Raspberry Pi 4 > Revert "firmware: raspberrypi: Introduce vl805 init routine" > Revert "PCI: brcmstb: Wait for Raspberry Pi's firmware when present" > > .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++ > arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++++ > drivers/firmware/Kconfig | 3 +- > drivers/firmware/raspberrypi.c | 61 --------- > drivers/pci/controller/pcie-brcmstb.c | 17 --- > drivers/reset/Kconfig | 11 ++ > drivers/reset/Makefile | 1 + > drivers/reset/reset-raspberrypi.c | 122 ++++++++++++++++++ > drivers/usb/host/pci-quirks.c | 22 ++-- > drivers/usb/host/xhci-pci.c | 10 ++ > drivers/usb/host/xhci.h | 2 + > .../reset/raspberrypi,firmware-reset.h | 13 ++ > include/soc/bcm2835/raspberrypi-firmware.h | 7 - > 13 files changed, 215 insertions(+), 97 deletions(-) > create mode 100644 drivers/reset/reset-raspberrypi.c > create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h >
On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote: > Hi everyone. > > On Mon, 2020-06-29 at 18:18 +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 >> co-processor, VideoCore. This series reworks how we handle this. >> >> The previous solution makes use of PCI quirks and exporting platform >> specific functions. Albeit functional it feels pretty shoehorned. This >> proposes an alternative way of handling the triggering of the xHCI chip >> initialization trough means of a reset controller. >> >> The benefits are pretty evident: less platform churn in core xHCI code, >> and no explicit device dependency management in pcie-brcmstb. >> >> Note that patch #1 depends on another series[1], that was just applied >> into the clk maintainer's tree. >> >> The series is based on v5.8-rc3 >> >> v3: https://www.spinics.net/lists/arm-kernel/msg813612.html >> v2: https://lkml.org/lkml/2020/6/9/875 >> v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t >> >> [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t >> >> --- > > We were waiting on a dependency to be merged upstream to get this. They are now > in, so could we move things forward? > > I can take the device tree patches, I guess philipp can take the reset > controller code. But I'm not so sure who should be taking the PCI/USB > counterparts. Should we route everything through the USB tree since that is where the changes that do require synchronization with other subsystems and DTS is needed the most?
On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote: > > > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote: > > Hi everyone. > > > > On Mon, 2020-06-29 at 18:18 +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 > > > co-processor, VideoCore. This series reworks how we handle this. > > > > > > The previous solution makes use of PCI quirks and exporting platform > > > specific functions. Albeit functional it feels pretty shoehorned. This > > > proposes an alternative way of handling the triggering of the xHCI chip > > > initialization trough means of a reset controller. > > > > > > The benefits are pretty evident: less platform churn in core xHCI code, > > > and no explicit device dependency management in pcie-brcmstb. > > > > > > Note that patch #1 depends on another series[1], that was just applied > > > into the clk maintainer's tree. > > > > > > The series is based on v5.8-rc3 > > > > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html > > > v2: https://lkml.org/lkml/2020/6/9/875 > > > v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t > > > > > > [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t > > > > > > --- > > > > We were waiting on a dependency to be merged upstream to get this. They are now > > in, so could we move things forward? > > > > I can take the device tree patches, I guess philipp can take the reset > > controller code. But I'm not so sure who should be taking the PCI/USB > > counterparts. > > Should we route everything through the USB tree since that is where the > changes that do require synchronization with other subsystems and DTS is > needed the most? > -- > Florian That's fine with me, if everyone else is ok with it :)
On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote: > On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote: > > > > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote: > > > Hi everyone. > > > > > > On Mon, 2020-06-29 at 18:18 +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 > > > > co-processor, VideoCore. This series reworks how we handle this. > > > > > > > > The previous solution makes use of PCI quirks and exporting platform > > > > specific functions. Albeit functional it feels pretty shoehorned. This > > > > proposes an alternative way of handling the triggering of the xHCI chip > > > > initialization trough means of a reset controller. > > > > > > > > The benefits are pretty evident: less platform churn in core xHCI code, > > > > and no explicit device dependency management in pcie-brcmstb. > > > > > > > > Note that patch #1 depends on another series[1], that was just applied > > > > into the clk maintainer's tree. > > > > > > > > The series is based on v5.8-rc3 > > > > > > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html > > > > v2: https://lkml.org/lkml/2020/6/9/875 > > > > v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t > > > > > > > > [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t > > > > > > > > --- > > > > > > We were waiting on a dependency to be merged upstream to get this. They are now > > > in, so could we move things forward? > > > > > > I can take the device tree patches, I guess philipp can take the reset > > > controller code. But I'm not so sure who should be taking the PCI/USB > > > counterparts. > > > > Should we route everything through the USB tree since that is where the > > changes that do require synchronization with other subsystems and DTS is > > needed the most? > > -- > > Florian > > That's fine with me, if everyone else is ok with it :) Sounds good to me.
On Fri, Aug 14, 2020 at 12:04:05PM +0200, Nicolas Saenz Julienne wrote: > On Fri, 2020-08-14 at 08:11 +0200, Greg KH wrote: > > On Thu, Aug 13, 2020 at 12:17:49PM -0700, Florian Fainelli wrote: > > > > > > On 8/13/2020 3:01 AM, Nicolas Saenz Julienne wrote: > > > > Hi everyone. > > > > > > > > On Mon, 2020-06-29 at 18:18 +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 > > > > > co-processor, VideoCore. This series reworks how we handle this. > > > > > > > > > > The previous solution makes use of PCI quirks and exporting platform > > > > > specific functions. Albeit functional it feels pretty shoehorned. This > > > > > proposes an alternative way of handling the triggering of the xHCI chip > > > > > initialization trough means of a reset controller. > > > > > > > > > > The benefits are pretty evident: less platform churn in core xHCI code, > > > > > and no explicit device dependency management in pcie-brcmstb. > > > > > > > > > > Note that patch #1 depends on another series[1], that was just applied > > > > > into the clk maintainer's tree. > > > > > > > > > > The series is based on v5.8-rc3 > > > > > > > > > > v3: https://www.spinics.net/lists/arm-kernel/msg813612.html > > > > > v2: https://lkml.org/lkml/2020/6/9/875 > > > > > v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t > > > > > > > > > > [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t > > > > > > > > > > --- > > > > > > > > We were waiting on a dependency to be merged upstream to get this. They are now > > > > in, so could we move things forward? > > > > > > > > I can take the device tree patches, I guess philipp can take the reset > > > > controller code. But I'm not so sure who should be taking the PCI/USB > > > > counterparts. > > > > > > Should we route everything through the USB tree since that is where the > > > changes that do require synchronization with other subsystems and DTS is > > > needed the most? > > > -- > > > Florian > > > > That's fine with me, if everyone else is ok with it :) > > Sounds good to me. All now queued up, thanks for sticking with this! greg k-h
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 co-processor, VideoCore. This series reworks how we handle this. The previous solution makes use of PCI quirks and exporting platform specific functions. Albeit functional it feels pretty shoehorned. This proposes an alternative way of handling the triggering of the xHCI chip initialization trough means of a reset controller. The benefits are pretty evident: less platform churn in core xHCI code, and no explicit device dependency management in pcie-brcmstb. Note that patch #1 depends on another series[1], that was just applied into the clk maintainer's tree. The series is based on v5.8-rc3 v3: https://www.spinics.net/lists/arm-kernel/msg813612.html v2: https://lkml.org/lkml/2020/6/9/875 v1: https://lore.kernel.org/linux-usb/20200608192701.18355-1-nsaenzjulienne@suse.de/T/#t [1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@swboyd.mtv.corp.google.com/T/#t --- Changes since v4: - Adress Andy's comments Changes since v3: - Rework dt patch to include root bridge as a separate node - Update xhci-pci patch now that the xhci dev has a dt node (it was getting it in the past from its bus) Changes since v2: - Add reset to resume routine in xhci-pci - Correct of refcount in pci-quirks - Correct typos - Use include file to define firmware reset IDs Changes since v1: - Rework reset controller so it's less USB centric - Use correct reset controller API in xhci-pci - Correct typos Nicolas Saenz Julienne (9): dt-bindings: reset: Add a binding for the RPi Firmware reset controller reset: Add Raspberry Pi 4 firmware reset controller ARM: dts: bcm2711: Add firmware usb reset node ARM: dts: bcm2711: Add reset controller to xHCI node usb: xhci-pci: Add support for reset controllers Revert "USB: pci-quirks: Add Raspberry Pi 4 quirk" usb: host: pci-quirks: Bypass xHCI quirks for Raspberry Pi 4 Revert "firmware: raspberrypi: Introduce vl805 init routine" Revert "PCI: brcmstb: Wait for Raspberry Pi's firmware when present" .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 21 +++ arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++++ drivers/firmware/Kconfig | 3 +- drivers/firmware/raspberrypi.c | 61 --------- drivers/pci/controller/pcie-brcmstb.c | 17 --- drivers/reset/Kconfig | 11 ++ drivers/reset/Makefile | 1 + drivers/reset/reset-raspberrypi.c | 122 ++++++++++++++++++ drivers/usb/host/pci-quirks.c | 22 ++-- drivers/usb/host/xhci-pci.c | 10 ++ drivers/usb/host/xhci.h | 2 + .../reset/raspberrypi,firmware-reset.h | 13 ++ include/soc/bcm2835/raspberrypi-firmware.h | 7 - 13 files changed, 215 insertions(+), 97 deletions(-) create mode 100644 drivers/reset/reset-raspberrypi.c create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h