From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: pci-mvebu driver on km_kirkwood
Date: Fri, 9 Aug 2013 16:01:42 +0200 [thread overview]
Message-ID: <20130809140140.GA14990@ulmo> (raw)
In-Reply-To: <20130731205034.GA17615@obsidianresearch.com>
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.
>
> 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).
>
> 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.
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.
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.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130809/52a28f3e/attachment.sig>
next prev parent reply other threads:[~2013-08-09 14:01 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 [this message]
2013-08-26 9:27 ` Gerlando Falauto
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=20130809140140.GA14990@ulmo \
--to=thierry.reding@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).