On 08/15/2012 02:09 PM, Thierry Reding wrote: > On Wed, Aug 15, 2012 at 01:04:20PM -0600, Stephen Warren wrote: >> On 08/14/2012 05:51 PM, Stephen Warren wrote: >>> On 08/14/2012 04:58 PM, Stephen Warren wrote: >> ... >>>> Can't we make the call to pci_bus_add_devices() optional in >>>> pci_scan_root_bus() somehow; one of: >>> >>> Sigh, that turns out not to work correctly; it solves at least >>> this part of the problem when booting using device tree, but >>> when booting using a board file, it causes the IRQ number >>> passed to the PCIe device to be bogus:-( >>> >>> I give up for now. >> >> I think the appropriate workaround for Tegra in 3.6 is to simply >> make any drivers for PCIe-based devices be modules instead of >> built-in, as Thierry hinted at much earlier in the thread. I've >> validated that the Ethernet works just fine on TrimSlice with >> that change, booting v3.6-rc1 using either board files or device >> tree. > > That's certainly the easiest and least error-prone solution. > >> For 3.7, we should continue the discussion about a real fix; I'll >> look into the change Bjorn requested and see if it works, >> although given that hacking pci_scan_root_bus as described >> immediately previously in this thread caused a regression when >> booting using a board file, and the fact that board files are no >> longer supported on Tegra, I'm not too confident in the >> outcome... > > I don't understand this last part. If the problem is there when > booting from board files and the board files are removed, doesn't > that remove the problem as well? =)
It does for ARM SoCs/CPUs exclusively using device tree, but not all ARM systems are converting to device tree, so the fact that Tegra has makes it harder for me not to break anything else. _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
