From: Grant Likely <grant.likely@secretlab.ca>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: devicetree-discuss@ozlabs.org, michal.simek@petalogix.com,
microblaze-uclinux@itee.uq.edu.au, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, John Linn <John.Linn@xilinx.com>,
John Williams <john.williams@petalogix.com>
Subject: Re: Proposal to move PCI out of arch/powerpc and into drivers/of
Date: Fri, 26 Feb 2010 17:17:47 -0700 [thread overview]
Message-ID: <fa686aa41002261617m44af3379nd49e651c1edcf8de@mail.gmail.com> (raw)
In-Reply-To: <CDF924F6-56F9-4F3D-9CF9-BF321437C3B5@kernel.crashing.org>
On Fri, Feb 26, 2010 at 4:50 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> 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 wh=
at we do on embedded systems and just have the root and leave the probing t=
o 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.
> =A0I 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 assump=
tions 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.
next prev parent reply other threads:[~2010-02-27 0:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 23:07 Proposal to move PCI out of arch/powerpc and into drivers/of John Linn
2010-02-26 23:44 ` Jesse Barnes
2010-02-28 0:33 ` Benjamin Herrenschmidt
2010-02-26 23:50 ` Kumar Gala
2010-02-27 0:17 ` Grant Likely [this message]
2010-02-28 0:32 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa686aa41002261617m44af3379nd49e651c1edcf8de@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=John.Linn@xilinx.com \
--cc=devicetree-discuss@ozlabs.org \
--cc=galak@kernel.crashing.org \
--cc=john.williams@petalogix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michal.simek@petalogix.com \
--cc=microblaze-uclinux@itee.uq.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).