On 11/11/2019 12:00 PM, Jeremy Linton wrote: [snip] >>> Presumablly users will want to use PCIe at some point in the future for >>> booting/etc. That means the firmware will perform sufficient setup that >>> you shouldn't need much of the code in this function if the address >>> windows, serdes, etc are functional when linux boots. Similarly for >>> suspend/resume. >> >> I see what you mean, although it's not the case for now as RPi's firmware >> doesn't initialize anything. Though I can imagine some people might >> want this >> if the RPi4 compute module ever comes out. >> >> If it's OK with you I think we can let it be for now. > > Well this is actually why I commented on the whole set. A large part of > this driver appears to be working around the shortcommings in the > current firmware when it comes to programming the bridge. Once the > firmware integrates that functionality (there appear to be rpi ports > underway in uboot/edk2/atf) large parts of this driver will become > unessisary. Not to mention the other OS's that have historically wanted > to support the rpi will have an easier time of it as well. You are making this assumption based on the current submission which specifically targets 2711 for now, the latter which could, in premise gain support for an uboot/edk2/atf doing a fair amount of configuration on behalf of Linux. This same driver is used on MIPS platforms (no firmware), on ARMv7a 32-bit platforms with no ATF, and on ARM 64-bit platforms with an ATF that we purposely have made unaware of PCIe. Those platforms also support suspend to DRAM and S2. In Suspend to DRAM, all register contents are lost since PCIe is not on the always-on island, which is why a fair amount of (re)configuration also occurs there. There is not to my knowledge any firmware, or software prior to Linux configuring the PCIe bridge (2711 or otherwise) because it historically has not been required/deemed necessary/desirable and for the vast majority of platforms where this driver is used, I expect that situation to remain for the years to come. For Broadcom STB platforms where this has been used for the most part, none of our customers have used PCIe to connect a southbridge to gain SATA/USB/Ethernet peripherals, since we have all of those on-chip already, therefore even the boot loader(s) used on these platforms do not support boot from PCIe. The vast majority (98%) of use cases are WLAN, and occasionally NVMe. Since there are a few @arm.com participants in this thread, if standardization of the PCIe host bridge is so important, maybe entertaining the idea of delivering a PCIe MAC (and leaving the PHY as something to be done by the integrator) as another IP in your portfolio would given some give some incentive to avoiding doing that piece of HW (and FW, and SW) and save the pain of compliance, memory semantics, bridging and all of those things easy to get wrong. -- Florian
