pci-mvebu driver on km_kirkwood

[thomas.petazzoni@free-electrons.com (Thomas Petazzoni)]

Dear Gerlando Falauto,

[ Device Tree mailing list readers: there is a question for you below. ]

On Wed, 31 Jul 2013 10:26:44 +0200, Gerlando Falauto wrote:

> >> I am trying to use the pci-mvebu driver on one of our km_kirkwood
> >> boards. The board is based on Marvell's 98dx4122, which should
> >> essentially be 6281 compatible.
> >
> > In the end, did you manage to get the pci-mvebu driver to work on your
> > platform?
> 
> Yes, I did -- though I didn't go much beyond simple device probing (i.e. 
> no real, intense usage of devices).

Ok, good.

> AND I'm not using the DT-based mbus 
> driver (i.e. addresses are still hardcoded within the source code).

Ok, that will be the next step, but I don't expect you to face many
issues. The DT-based mbus doesn't change much the internal logic, it's
really just the DT representation that's different. On the other hand,
the new PCIe driver was completely changing the internal logic, by
adding the emulated PCI-to-PCI bridge.

> Actually, the main reason for trying to use this driver was because I 
> wanted to model a PCIe *device* within the device tree, so to expose its 
> GPIOs and IRQs to be referenced (through phandles) from other device 
> tree nodes. The way I understand it, turns out this is not the way to 
> go, as PCI/PCIe are essentially enumerated busses, so you're not 
> supposed to -and it's not a trivial task to- put any information about 
> real devices within the device tree.
> Do you have any suggestion about that?

Indeed, PCI/PCIe devices are enumerated dynamically, so they are not
listed in the Device Tree, so there's no way to "attach" more
information to them.

Device Tree people, any suggestion about the above question?

> On the other hand, for our use case I'm afraid there might be some 
> hardcoded values within drivers or userspace code, where a certain PCIe 
> device is expected to be connected within a given bus number with a 
> given device number (bleah!).
> If I understand correctly, your driver creates a virtual PCI-to-PCI 
> bridge, so our devices would be connected to BUS #1 as opposed to #0 -- 
> which might break existing (cr*ee*ppy) code.
> But that's not your fault of course.

Yeah, I believe normally userspace code shouldn't rely on a particular
PCI bus topology.

> If you're interested, I can keep you posted as soon as we proceed 
> further with this (most likely in September or so).

Sure.

> Next step would be to test Ezequiel's MBus DT binding [PATCH v8], but 
> I'm afraid that'll have to wait too, until end of August or so, as I am 
> about to leave for vacation.

Ok, thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com