From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Stephen Warren <swarren@nvidia.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"Olof Johansson (olof@lixom.net)" <olof@lixom.net>,
linux-pci@vger.kernel.org
Subject: Re: PCIe device tree support
Date: Thu, 23 Feb 2012 08:16:58 -0800 [thread overview]
Message-ID: <20120223081658.42af61a3@jbarnes-desktop> (raw)
In-Reply-To: <20120223060355.GA21091@avionic-0098.mockup.avionic-design.de>
[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]
On Thu, 23 Feb 2012 07:03:55 +0100
Thierry Reding <thierry.reding@avionic-design.de> wrote:
> * Bjorn Helgaas wrote:
> > On Wed, Feb 22, 2012 at 12:24 AM, Thierry Reding
> > <thierry.reding@avionic-design.de> wrote:
> > > [Adding Jesse Barnes and the linux-pci mailing list to CC.]
> > >
> > > * Stephen Warren wrote:
> > >> Thierry Reding wrote at Monday, February 20, 2012 12:18 PM:
> > >> > I would like to add device tree support for the Tegra2 PCIe controller. From
> > >> > what I understand this will require the PCIe code to be rewritten as a proper
> > >> > platform driver in order to be able to instantiate it via the device tree. Is
> > >> > that correct?
> > >>
> > >> That's probably the cleanest way, yes.
> > >>
> > >> Is there a drivers/ directory for PCI/PCIe host controllers? Moving the
> > >> code there might be nice if so, although IIRC when I asked Olof about
> > >> that a number of months back, he said quite a few host controllers were
> > >> in arch/...
> > >
> > > Most PCI/PCIe host controller drivers seem to currently be in arch/. Is there
> > > a specific reason for this? Would it be acceptable to put any new drivers
> > > below drivers/pci/?
> >
> > PCI host bridges aren't architected, so discovering them and their
> > properties has historically been mostly architecture-specific. ACPI
> > is one exception (with a driver in drivers/acpi/pci_root.c) and it
> > sounds like device tree might be a similar exception. If you can make
> > a non-arch-specific driver and put it somewhere other than arch/, I'm
> > all in favor of that, especially if you can make it usable by other
> > arches that use device tree. Where to put it? I dunno. drivers/pci/
> > sounds like a reasonable possibility.
>
> I don't think it would be possible to write a driver that works for all
> device tree based boards or architectures. As you said the implementation is
> very hardware specific and probably couldn't even be generalized among two
> chipsets of the same architecture.
>
> However there has recently been a lot of work to move out arch-specific
> drivers for PWM, GPIO and others out of arch/ and into respective directories
> below drivers/. The reason I asked was because I think the same could be done
> for PCI/PCIe.
I think that makes sense for stuff that may be shared between arches,
but host bridges are generally part of the core architecture of the
system, so factoring them out would just be code shuffling without any
real gain.
But for shared code, drivers/pci is definitely the right place.
Thanks,
Jesse
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-02-23 16:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120220191804.GA14499@avionic-0098.adnet.avionic-design.de>
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF17BD8BC302@HQMAIL01.nvidia.com>
2012-02-22 8:24 ` PCIe device tree support Thierry Reding
2012-02-22 16:01 ` Bjorn Helgaas
2012-02-23 6:03 ` Thierry Reding
2012-02-23 16:16 ` Jesse Barnes [this message]
2012-02-23 16:17 ` Olof Johansson
2012-02-23 17:49 ` Bjorn Helgaas
2012-02-24 6:59 ` Thierry Reding
2012-02-24 17:16 ` Pratyush Anand
2012-02-24 17:25 ` Bjorn Helgaas
2012-02-24 17:27 ` Jesse Barnes
2012-02-28 18:17 ` Bjorn Helgaas
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=20120223081658.42af61a3@jbarnes-desktop \
--to=jbarnes@virtuousgeek.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=olof@lixom.net \
--cc=swarren@nvidia.com \
--cc=thierry.reding@avionic-design.de \
/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).