All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Andrew Murray <andrew.murray@arm.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: james.quinlan@broadcom.com, mbrugger@suse.com,
	phil@raspberrypi.org, wahrenst@gmx.net,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller driver
Date: Mon, 11 Nov 2019 13:27:43 -0800	[thread overview]
Message-ID: <ea24cc0e-7577-5ec3-f4fe-ad6cf9f03078@gmail.com> (raw)
In-Reply-To: <a5586548-350f-35c2-cee1-eb8c06a7e508@arm.com>



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

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Jeremy Linton <jeremy.linton@arm.com>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Andrew Murray <andrew.murray@arm.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: mbrugger@suse.com, phil@raspberrypi.org,
	linux-kernel@vger.kernel.org, wahrenst@gmx.net,
	james.quinlan@broadcom.com, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller driver
Date: Mon, 11 Nov 2019 13:27:43 -0800	[thread overview]
Message-ID: <ea24cc0e-7577-5ec3-f4fe-ad6cf9f03078@gmail.com> (raw)
In-Reply-To: <a5586548-350f-35c2-cee1-eb8c06a7e508@arm.com>



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

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

  reply	other threads:[~2019-11-11 21:27 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 21:45 [PATCH 0/4] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
2019-11-06 21:45 ` Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 1/4] dt-bindings: pci: add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
2019-11-06 21:45   ` Nicolas Saenz Julienne
2019-11-07 10:32   ` Andrew Murray
2019-11-07 10:32     ` Andrew Murray
2019-11-07 10:53     ` Nicolas Saenz Julienne
2019-11-07 10:53       ` Nicolas Saenz Julienne
2019-11-13  4:15   ` Rob Herring
2019-11-13  4:15     ` Rob Herring
2019-11-14 13:15     ` Nicolas Saenz Julienne
2019-11-14 13:15       ` Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 2/4] ARM: dts: bcm2711: Enable PCIe controller Nicolas Saenz Julienne
2019-11-06 21:45   ` Nicolas Saenz Julienne
2019-11-07 10:37   ` Andrew Murray
2019-11-07 10:37     ` Andrew Murray
2019-11-12  9:18     ` Nicolas Saenz Julienne
2019-11-12  9:18       ` Nicolas Saenz Julienne
2019-11-07 17:44   ` Stefan Wahren
2019-11-07 17:44     ` Stefan Wahren
2019-11-07 18:24     ` Nicolas Saenz Julienne
2019-11-07 18:24       ` Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
2019-11-06 21:45   ` Nicolas Saenz Julienne
2019-11-07 15:00   ` Andrew Murray
2019-11-07 15:00     ` Andrew Murray
2019-11-07 16:12     ` Jim Quinlan
2019-11-07 16:12       ` Jim Quinlan
2019-11-08 10:52       ` Andrew Murray
2019-11-08 10:52         ` Andrew Murray
2019-11-08 16:33         ` Jim Quinlan
2019-11-08 16:33           ` Jim Quinlan
2019-11-07 17:30     ` Nicolas Saenz Julienne
2019-11-07 17:30       ` Nicolas Saenz Julienne
2019-11-08 10:51       ` Andrew Murray
2019-11-08 10:51         ` Andrew Murray
2019-11-07 17:50   ` Stefan Wahren
2019-11-07 17:50     ` Stefan Wahren
2019-11-08 11:13     ` Nicolas Saenz Julienne
2019-11-08 11:13       ` Nicolas Saenz Julienne
2019-11-11  7:10   ` Jeremy Linton
2019-11-11  7:10     ` Jeremy Linton
2019-11-11 15:29     ` Nicolas Saenz Julienne
2019-11-11 15:29       ` Nicolas Saenz Julienne
2019-11-11 16:40       ` Florian Fainelli
2019-11-11 16:40         ` Florian Fainelli
2019-11-11 20:00       ` Jeremy Linton
2019-11-11 20:00         ` Jeremy Linton
2019-11-11 21:27         ` Florian Fainelli [this message]
2019-11-11 21:27           ` Florian Fainelli
2019-11-06 21:45 ` [PATCH 4/4] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
2019-11-06 21:45   ` Nicolas Saenz Julienne
2019-11-07 15:40   ` Marc Zyngier
2019-11-07 15:40     ` Marc Zyngier
2019-11-11 11:21     ` Nicolas Saenz Julienne
2019-11-11 11:21       ` Nicolas Saenz Julienne
2019-11-11 13:29       ` Marc Zyngier
2019-11-11 13:29         ` Marc Zyngier
2019-11-06 21:51 ` [PATCH 0/4] Raspberry Pi 4 PCIe support Florian Fainelli
2019-11-06 21:51   ` Florian Fainelli
2019-11-07  9:58   ` Nicolas Saenz Julienne
2019-11-07  9:58     ` Nicolas Saenz Julienne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea24cc0e-7577-5ec3-f4fe-ad6cf9f03078@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew.murray@arm.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=james.quinlan@broadcom.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mbrugger@suse.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=phil@raspberrypi.org \
    --cc=wahrenst@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.