On Wed, Feb 22, 2012 at 10:03 PM, Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> wrote: > * Bjorn Helgaas wrote: >> On Wed, Feb 22, 2012 at 12:24 AM, Thierry Reding >> <thierry.reding@xxxxxxxxxxxxxxxxx> 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. Host bridges may be hardware-specific, but the PCI core really only needs an abstract description. It needs the bus number aperture, the I/O port apertures, the MMIO apertures, and associated offsets between CPU and PCI bus addresses. I don't know anything about device tree, but I'd be surprised and disappointed if it encodes this basic information in platform-specific ways. I agree that if the code isn't shared at all, there's no point in putting it in a generic place like drivers/pci/. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
