[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CDF924F6-56F9-4F3D-9CF9-BF321437C3B5@kernel.crashing.org>
Date: Fri, 26 Feb 2010 17:50:26 -0600
From: Kumar Gala <galak@...nel.crashing.org>
To: John Linn <John.Linn@...inx.com>
Cc: <linux-kernel@...r.kernel.org>, <devicetree-discuss@...abs.org>,
<linuxppc-dev@...abs.org>, <microblaze-uclinux@...e.uq.edu.au>,
michal.simek@...alogix.com,
John Williams <john.williams@...alogix.com>
Subject: Re: Proposal to move PCI out of arch/powerpc and into drivers/of
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? 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).
As well as features on the PPC64 side to not re-probe PCI and build internal kernel data structures purely from the OF tree.
I think moving the code and sharing it between everyone is a good thing, just point out some issues I know we are aware of.
- k--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists