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
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
On Fri, 26 Feb 2010 16:07:59 -0700
John Linn <[email protected]> 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/*)?
Dave and Ben have been talking about this for awhile; seems like a good
excuse to do it. IIRC they had even thought about just dumping the
code directly into drivers/pci so that API updates won't get missed...
--
Jesse Barnes, Intel Open Source Technology Center
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-
On Fri, Feb 26, 2010 at 4:50 PM, Kumar Gala <[email protected]> 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.
On Fri, 2010-02-26 at 16:07 -0700, 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/*)?
I don't think we should move the whole thing. I know Grant plans to move
parts of it though. There's quite a few things in there that are still
quite powerpc specific (and even different between ppc32 and ppc64).
I wouldn't mind in the long run if we could make some of powerpc's PCI
implementation bits more generic, such as struct pci_controller, and the
MMIO/PIO remapping mechanisms, since many archs do more or less the same
thing and all in subtely different ways. But that would have to go to
drivers/pci.
Then there's the whole deal with matching OF nodes with PCI devices. A
lot of that is still different even between ppc32 and ppc64. I don't
think any of that is ready to be moved to drivers/of, it's not generic
enough by far.
Cheers,
Ben.
On Fri, 2010-02-26 at 15:44 -0800, Jesse Barnes wrote:
>
> Dave and Ben have been talking about this for awhile; seems like a
> good
> excuse to do it. IIRC they had even thought about just dumping the
> code directly into drivers/pci so that API updates won't get
> missed...
Depends which part. Not -all- of our PCI code as John seems to want.
The bits that generate PCI devices from the device-tree, for sure,
though again, even there, there are quite a few dependencies on
constructs and data structures that are powerpc specific, or even ppc64
specific in some cases, and that would have to be cleaned up and/or
abstracted first.
Cheers,
Ben.