Date:   Mon, 11 Nov 2019 13:27:43 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jeremy Linton <jeremy.linton@....com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Andrew Murray <andrew.murray@....com>,
        linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
        bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     james.quinlan@...adcom.com, mbrugger@...e.com,
        phil@...pberrypi.org, wahrenst@....net,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller
 driver



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

Powered by blists - more mailing lists