Re: [PATCH v5 0/9] Raspberry Pi 4 USB firmware initialization rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxx/T/#t

[1] https://lore.kernel.org/linux-clk/159304773261.62212.983376627029743900@xxxxxxxxxxxxxxxxxxxxxxxxxx/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



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux