Re: [PATCH v8 0/4] USB: pci-quirks: Add Raspberry Pi 4 quirk

[Nicolas Saenz Julienne <nsaenzjulienne@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3755 bytes --]

On Wed, 2020-05-13 at 12:17 +0100, Lorenzo Pieralisi wrote:
> On Tue, May 05, 2020 at 06:13:13PM +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 adds support for the later.
> > 
> > Note that there are a set of constraints we have to consider:
> >  - We need to make sure the VideoCore firmware interface is up and
> >    running before running the VL805 firmware load call.
> > 
> >  - There is no way to discern RPi4's VL805 chip from other platforms',
> >    so we need the firmware load to happen *before* running
> >    quirk_usb_handoff_xhci(). Failure to do so results in an unwarranted
> >    5 second wait while the fixup code polls xHC's non-existing state.
> > 
> > By Florian's suggestion I've been spending some time exploring the device
> > link[1] API in order to see if that could save us from explicitly creating
> > probe dependencies between pcie-brcmstb and firmware/raspberrypi (patch #3).
> > Technically these dependencies could be inferred from DT. It turns out
> > Saravana
> > Kannan has been looking at this already. A new boot mechanism, activated
> > with
> > fw_devlink=on takes care of the device probe ordering on devices with
> > consumer/supplier relationships. For now this relationship is created based
> > on
> > the usage of generic DT properties, but has no support for vendor-specifc DT
> > properties, which we'd be forced to use in order to create a relationship
> > between our two devices since our setup is highly non generic. There will
> > probably be at some point support for such properties, and we will then be
> > able
> > to revisit some of this code.
> > 
> > All this is based on the work by Tim Gover in RPi's downstream
> > kernel[2].
> > 
> > [1] https://www.kernel.org/doc/html/v4.13/driver-api/device_link.html
> > [2] 
> > 
https://github.com/raspberrypi/linux/commit/9935b4c7e360b4494b4cb6e3ce797238a1ab78bd
> > 
> > ---
> > 
> > Changes since v7:
> >  - Address Stefan's comments
> > 
> > Changes since v6:
> >  - Make rpi_firmware_init_vl805() more robust
> >  - Rewrite comments and patch descriptions to be more accessible to non RPi
> >    fluent people
> >  - Removed Florian's Reviewed-by in patch #2 as function changed
> >    substantially
> >  - Tested with/witout u-boot
> > 
> > Changes since v5:
> >  - Fix issues reported by Kbuild test robot
> > 
> > Changes since v4:
> >  - Addressed Sergei's comments
> >  - Fix potential warning in patch #2
> > 
> > Changes since v3:
> >  - Addressed Greg's comments
> > 
> > There was no v2, my bad.
> > 
> > Changes since v1:
> >  - Addressed Floarians comments
> > 
> > Nicolas Saenz Julienne (4):
> >   soc: bcm2835: Add notify xHCI reset property
> >   firmware: raspberrypi: Introduce vl805 init routine
> >   PCI: brcmstb: Wait for Raspberry Pi's firmware when present
> >   USB: pci-quirks: Add Raspberry Pi 4 quirk
> > 
> >  drivers/firmware/Kconfig                   |  3 +-
> >  drivers/firmware/raspberrypi.c             | 61 ++++++++++++++++++++++
> >  drivers/pci/controller/pcie-brcmstb.c      | 17 ++++++
> >  drivers/usb/host/pci-quirks.c              | 16 ++++++
> >  include/soc/bcm2835/raspberrypi-firmware.h |  9 +++-
> >  5 files changed, 104 insertions(+), 2 deletions(-)
> 
> Hi Nicolas,
> 
> should I queue this series via the PCI tree ? Just let me know, most of
> the changes are not in the PCI tree, asking in order to
> minimize/simplify conflicts handling if possible.

Yes, I agree, it's better if you take the whole thing.

Thanks,
Nicolas


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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel