[PATCH v5 2/2] PCI: microchip: rework reg region handing to support using either instance 1 or 2

[Conor Dooley]

On Tue, Nov 05, 2024 at 11:18:28AM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 04, 2024 at 11:18:43AM +0000, Conor Dooley wrote:
> > On Fri, Nov 01, 2024 at 02:51:29PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Aug 14, 2024 at 09:08:42AM +0100, Conor Dooley wrote:
> > > > From: Conor Dooley <conor.dooley at microchip.com>
> > > > 
> > > > The PCI host controller on PolarFire SoC has multiple "instances", each
> > > > with their own bridge and ctrl address spaces. The original binding has
> > > > an "apb" register region, and it is expected to be set to the base
> > > > address of the host controllers register space. Defines in the driver
> > > > were used to compute the addresses of the bridge and ctrl address ranges
> > > > corresponding to instance1. Some customers want to use instance0 however
> > > > and that requires changing the defines in the driver, which is clearly
> > > > not a portable solution.
> > > 
> > > The subject mentions "instance 1 or 2".
> > > 
> > > This paragraph implies adding support for "instance0" ("customers want
> > > to use instance0").
> > > 
> > > The DT patch suggests that we're adding support for "instance2"
> > > ("customers want to use instance2").
> > > 
> > > Both patches suggest that the existing support is for "instance 1".
> > > 
> > > Maybe what's being added is "instance 2", and this commit log should
> > > s/instance0/instance 2/ ?  And probably s/instance1/instance 1/ so the
> > > style is consistent?
> > 
> > Hmm no, it would be s/instance1/instance 2/ & s/instance0/instance 1/.
> > The indices are 1-based, not 0-based.
> > 
> > > Is this a "pick one or the other but not both" situation, or does this
> > > device support two independent PCIe controllers?
> > > 
> > > I first thought this driver supported a single PCIe controller, and
> > > you were adding support for a second independent controller.
> > 
> > I don't know if they are fully independent (Daire would have to confirm)
> > but as far as the driver in linux is concerned they are. As far as I
> > know, you could operate both instances at the same time, but I've not
> > heard of any customer that is actually doing that nor tested it myself.
> > Operating both instances would require another node in the devicetree,
> > which should work fine given the private data structs are allocated at
> > runtime. I think the config space is shared.
> > 
> > > But the fact that you say "the [singular] host controller on
> > > PolarFire", and you're not changing mc_host_probe() to call
> > > pci_host_common_probe() more than once makes me think there is only a
> > > single PCIe controller, and for some reason you can choose to operate
> > > it using either register set 1 or register set 2.
> > 
> > The wording I've used mostly stems from conversations with Daire. We've
> > kinda been saying that there's a single controller with two root port
> > instances. 
> 
> If these are two separate Root Ports, can we call them "Root Ports"
> instead of "instances"?  Common terminology makes for common
> understanding.

Sure.

> > Each root port instance is connected to different IOs,
> > they're more than just different registers for accessing the same thing.
> 
> Sounds like some customers use Root Port 1 and others use Root Port 2,
> maybe based on things like which pins are more convenient to route.

Aye, the user that motivated the patchset uses a very small package and
was not able to use root port 1 for that reason.

> I would very much like to reword these commit logs using as much
> standard PCIe terminology as possible.  Most of these native PCIe
> controller drivers have Root Complex and Root Port concepts all mixed
> together, and anything we can do to standardize them will be a
> benefit.

I can do that tomorrow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20241106/3de6ffba/attachment.sig>