From: gerlando.falauto@keymile•com (Gerlando Falauto)
To: linux-arm-kernel@lists•infradead.org
Subject: pci-mvebu driver on km_kirkwood
Date: Mon, 26 Aug 2013 11:27:06 +0200 [thread overview]
Message-ID: <521B1F6A.1090304@keymile.com> (raw)
In-Reply-To: <20130809140140.GA14990@ulmo>
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:
>> On Wed, Jul 31, 2013 at 11:00:45AM +0200, Thomas Petazzoni wrote:
>>
>>>> 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...
>> 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.
>>
>> 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
next prev parent reply other threads:[~2013-08-26 9:27 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 16:15 pci-mvebu driver on km_kirkwood Gerlando Falauto
2013-07-10 16:57 ` Thomas Petazzoni
2013-07-10 17:31 ` Gerlando Falauto
2013-07-10 19:56 ` Gerlando Falauto
2013-07-11 7:03 ` Valentin Longchamp
2013-07-12 8:59 ` Thomas Petazzoni
2013-07-15 15:46 ` Valentin Longchamp
2013-07-15 19:51 ` Thomas Petazzoni
2013-07-11 14:32 ` Thomas Petazzoni
2014-02-18 17:29 ` Gerlando Falauto
2014-02-18 20:27 ` Thomas Petazzoni
2014-02-19 8:38 ` Gerlando Falauto
2014-02-19 9:26 ` Thomas Petazzoni
2014-02-19 9:39 ` Gerlando Falauto
2014-02-19 13:37 ` Thomas Petazzoni
2014-02-19 21:45 ` Bjorn Helgaas
2014-02-20 8:55 ` Thomas Petazzoni
2014-02-20 17:35 ` Jason Gunthorpe
2014-02-20 20:29 ` Thomas Petazzoni
2014-02-21 0:32 ` Jason Gunthorpe
2014-02-21 8:34 ` Thomas Petazzoni
2014-02-21 8:58 ` Gerlando Falauto
2014-02-21 9:12 ` Thomas Petazzoni
2014-02-21 9:16 ` Gerlando Falauto
2014-02-21 9:39 ` Thomas Petazzoni
2014-02-21 12:24 ` Gerlando Falauto
2014-02-21 13:47 ` Thomas Petazzoni
2014-02-21 15:05 ` Arnd Bergmann
2014-02-21 15:11 ` Thomas Petazzoni
2014-02-21 15:20 ` Arnd Bergmann
2014-02-21 15:37 ` Thomas Petazzoni
2014-02-21 16:39 ` Jason Gunthorpe
2014-02-21 17:05 ` Thomas Petazzoni
2014-02-21 17:31 ` Jason Gunthorpe
2014-02-21 18:05 ` Arnd Bergmann
2014-02-21 18:29 ` Gerlando Falauto
2014-02-21 18:18 ` Gerlando Falauto
2014-02-21 18:45 ` Thomas Petazzoni
2014-02-20 19:18 ` Bjorn Helgaas
2014-02-21 0:24 ` Jason Gunthorpe
2014-02-21 19:05 ` Bjorn Helgaas
2014-02-21 19:21 ` Thomas Petazzoni
2014-02-21 19:53 ` Benjamin Herrenschmidt
2014-02-23 3:43 ` Gavin Shan
2013-07-31 8:03 ` Thomas Petazzoni
2013-07-31 8:26 ` Gerlando Falauto
2013-07-31 9:00 ` Thomas Petazzoni
2013-07-31 20:50 ` Jason Gunthorpe
2013-08-09 14:01 ` Thierry Reding
2013-08-26 9:27 ` Gerlando Falauto [this message]
2013-08-26 12:02 ` Thierry Reding
2013-08-26 14:49 ` Gerlando Falauto
2013-08-26 19:16 ` Jason Gunthorpe
2013-11-04 14:49 ` Gerlando Falauto
2013-11-05 8:13 ` Thierry Reding
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=521B1F6A.1090304@keymile.com \
--to=gerlando.falauto@keymile$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox