Re: [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller driver

On 11/11/2019 12:00 PM, Jeremy Linton wrote:

[snip]

quoted

quoted

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