Pointers for writing a good PCIe driver
Bjorn Helgaas
helgaas at kernel.org
Fri Feb 17 09:50:54 PST 2017
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
More information about the linux-arm-kernel
mailing list