From: Bjorn Helgaas <helgaas@kernel.org>
To: Mason <slash.tmp@free.fr>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Greg KH <gregkh@linuxfoundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: Pointers for writing a good PCIe driver
Date: Fri, 17 Feb 2017 11:50:54 -0600 [thread overview]
Message-ID: <20170217175054.GA16671@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <eff9861e-043a-7ecd-5d52-c8e18a52ece8@free.fr>
On Fri, Feb 17, 2017 at 06:00:53PM +0100, Mason wrote:
> On 17/02/2017 15:38, Bjorn Helgaas wrote:
>
> > On Fri, Feb 17, 2017 at 10:20:20AM +0100, Mason wrote:
> >
> >> There might be some kind of misunderstanding.
> >>
> >> I don't plan to write a driver for a device that plugs into a PCIe slot.
> >>
> >> I intend to write a driver for the PCIe controller itself, which is
> >> embedded in the SoC. (In order to support different types of PCIe
> >> devices, with their respective drivers already upstream.)
> >>
> >> I think the controller driver belongs in drivers/pci/host ?
> >
> > Sorry, I indeed misunderstood you.
> >
> > The native PCI host controller drivers indeed live in
> > drivers/pci/host/.
> >
> > I don't know anything about your hardware or environment, but I highly
> > encourage you to use ACPI (drivers/acpi/pci_root.c, with a little bit
> > of arch support) or generic DT (drivers/pci/host/pci-host-generic.c)
> > instead of writing a custom host controller driver.
> >
> > The native drivers in drivers/pci/host are a huge maintenance hassle
> > for no real benefit.
>
> My SoC is built around an ARM Cortex A9.
> I don't think (?) this platform has any support for ACPI.
There's ACPI support on ARM64, but none that I know of for ARM32.
> I'm currently using this DT description:
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/tango4-common.dtsi
>
> The "legacy" driver sits at ~700 lines. It would be awesome to be able
> to discard all of it, and rely on generic upstream code. But I don't
> understand how it is possible for a generic driver to support whatever
> crazy solution some random vendor has come up with?
You're right that the programming model of the host bridge itself is
not specified by PCI specs, so it's impossible to have a generic
driver that can manage it completely by itself.
If you have firmware that initializes the bridge and tells the OS what
the windows are (bus numbers, memory space, I/O space) and where the
PCIe-specified ECAM space is, a generic driver can take it from there.
Bjorn
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: Pointers for writing a good PCIe driver
Date: Fri, 17 Feb 2017 11:50:54 -0600 [thread overview]
Message-ID: <20170217175054.GA16671@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <eff9861e-043a-7ecd-5d52-c8e18a52ece8@free.fr>
On Fri, Feb 17, 2017 at 06:00:53PM +0100, Mason wrote:
> On 17/02/2017 15:38, Bjorn Helgaas wrote:
>
> > On Fri, Feb 17, 2017 at 10:20:20AM +0100, Mason wrote:
> >
> >> There might be some kind of misunderstanding.
> >>
> >> I don't plan to write a driver for a device that plugs into a PCIe slot.
> >>
> >> I intend to write a driver for the PCIe controller itself, which is
> >> embedded in the SoC. (In order to support different types of PCIe
> >> devices, with their respective drivers already upstream.)
> >>
> >> I think the controller driver belongs in drivers/pci/host ?
> >
> > Sorry, I indeed misunderstood you.
> >
> > The native PCI host controller drivers indeed live in
> > drivers/pci/host/.
> >
> > I don't know anything about your hardware or environment, but I highly
> > encourage you to use ACPI (drivers/acpi/pci_root.c, with a little bit
> > of arch support) or generic DT (drivers/pci/host/pci-host-generic.c)
> > instead of writing a custom host controller driver.
> >
> > The native drivers in drivers/pci/host are a huge maintenance hassle
> > for no real benefit.
>
> My SoC is built around an ARM Cortex A9.
> I don't think (?) this platform has any support for ACPI.
There's ACPI support on ARM64, but none that I know of for ARM32.
> I'm currently using this DT description:
> http://lxr.free-electrons.com/source/arch/arm/boot/dts/tango4-common.dtsi
>
> The "legacy" driver sits at ~700 lines. It would be awesome to be able
> to discard all of it, and rely on generic upstream code. But I don't
> understand how it is possible for a generic driver to support whatever
> crazy solution some random vendor has come up with?
You're right that the programming model of the host bridge itself is
not specified by PCI specs, so it's impossible to have a generic
driver that can manage it completely by itself.
If you have firmware that initializes the bridge and tells the OS what
the windows are (bus numbers, memory space, I/O space) and where the
PCIe-specified ECAM space is, a generic driver can take it from there.
Bjorn
next prev parent reply other threads:[~2017-02-17 17:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-06 15:54 Pointers for writing a good PCIe driver Mason
2017-02-07 15:55 ` Mason
2017-02-07 20:06 ` Bjorn Helgaas
2017-02-07 21:47 ` Bjorn Helgaas
2017-02-07 22:56 ` Mason
2017-02-12 16:50 ` Greg KH
2017-02-17 9:20 ` Mason
2017-02-17 14:38 ` Bjorn Helgaas
2017-02-17 17:00 ` Mason
2017-02-17 17:00 ` Mason
2017-02-17 17:50 ` Bjorn Helgaas [this message]
2017-02-17 17:50 ` Bjorn Helgaas
2017-02-20 16:12 ` Mason
2017-02-20 16:12 ` Mason
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=20170217175054.GA16671@bhelgaas-glaptop.roam.corp.google.com \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=slash.tmp@free.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.