Hi guys [particularly Jason and Thierry],

sorry for the prolonged silence, here I am back again...

On 08/09/2013 04:01 PM, Thierry Reding wrote:

On Wed, Jul 31, 2013 at 02:50:34PM -0600, Jason Gunthorpe wrote:

quoted

On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:

quoted

quoted

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?

No, that isn't true.

Device tree can include the discovered PCI devices, you have to use
the special reg encoding and all that weirdness, but it does work. The
of_node will be attached to the struct pci device automatically.

So you mean that, assuming I knew the topology, I could populate the 
device tree in advance (e.g. statically), so that it already includes 
*devices* which will be further discovered during probing?
Or else you mean the {firmware,u-boot} can do that prior to starting the OS?
If either of the above is true, could you please suggest some example 
(or some way to get one)?
I assume the "reg" property (and the after-"@" node name) will need to 
encode (at least) the device number, is that right?

I tried reading the "PCI Bus Binding to Open Firmware" but I could not 
make complete sense out of it...

quoted

On server/etc DT platforms the firmware will do PCI discovery and
resource assignment then dump all those results into DT for the OS to
reference.

This is a major reason why we wanted to see the standard PCI DT be
used for Marvell/etc, the existing infrastructure for this is
valuable.

AFAIK, Thierry has tested this on tegra, and I am doing it on Kirkwood
(though not yet with the new driver).

Could you please give a pointer to some example of this? I'm not quite 
sure I understand what you guys are talking about.

quoted

It is useful for exactly the reason stated - you can describe GPIOs,
I2C busses, etc, etc in DT and then upon load of the PCI driver engage
the DT code to populate and connect all that downstream
infrastructure.

I'm not 100% sure I made myself clear though.
What I would like to do is to have *other* parts of the device tree be 
able to reference (i.e., connect to, through phandles) a PCI device 
(because it provides a GPIO, for instance).
Is that also what you mean?

Obviously this doesn't work in general purpose systems because the PCI
hierarchy needs to be hardcoded in the DT. If you start adding and
removing PCI devices that will likely change the hierarchy and break
this matching of PCI device to DT node.

Yes, I guess in that case (if ever) we would need some other way that 
the device number (is that the same as the physical slot?) to specify a 
particular "hotplug" device (i.e. maybe a serial number or so)?
But that's definitely out of scope here.

It's quite unlikely to have a need to hook up GPIOs or IRQs via DT in a
general purpose system, though, so I don't really see that being a big
problem.

Agreed.

Thierry

Thanks again for your patience...

Gerlando