On Fri, Feb 26, 2010 at 4:50 PM, Kumar Gala <ga...@kernel.crashing.org> wrote: > > On Feb 26, 2010, at 5:07 PM, John Linn wrote: > >> Hi all, >> >> We are in the process of putting PCI/PCIe into the microblaze >> architecture. >> >> In order to not duplicate/fork the PCI code in Powerpc, we're proposing >> to move the PCI code from arch/powerpc into drivers/of such that it >> would be common code for Powerpc and MicroBlaze. >> >> This would be the 1st part of a refactoring that would occur with the >> PCI code. >> >> Ben H., would you mind if that happened (move arch/powerpc/kernel/pci* >> to drivers/of/*)? >> >> Thanks, >> John > > John, > > Does MicroBlaze firmware produce full OF style PCI device tree's or do what > we do on embedded systems and just have the root and leave the probing to the > kernel?
Mostly like we do on ppc embedded. Let the kernel do the probing. I'm also going to want to be able to do the same think on ARM, so I also would like to make the code common. > I haven't looked at the OF side of what we do in PPC in a while but I know > we have some major differences between PPC32 & PPC64 because of assumptions > about what the firmware provides (or doesnt). I'm not too worried about this. I did some work on ppc32 to allow both probing and static PCI device definition on the same bus segment (although I didn't get all of it merged). There are difference between ppc32 & ppc64, but it seemed to me that the divergence was more just a matter of convenience rather than any particular technical hurdles preventing a common approach. I think the 32 and 64 bit paths can be mostly merged. g. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
