From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: michal.simek@petalogix.com
Cc: Arnd Bergmann <arnd@arndb.de>,
thunderbird2k@gmx.net, LKML <linux-kernel@vger.kernel.org>,
linuxppc-dev@ozlabs.org,
John Williams <john.williams@petalogix.com>
Subject: Re: xilinx-pci driver and pci in general
Date: Thu, 14 Jan 2010 13:07:16 +1100 [thread overview]
Message-ID: <1263434836.724.317.camel@pasglop> (raw)
In-Reply-To: <4B4DE58D.10008@petalogix.com>
On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
> The main problems are:
> ppc use ppc_md struct which we don't have it on Microblaze.
> xilinx-pci driver uses exclude_device function. This function is used in
> indirect_pci.c too. There could be a way to move that function directly
> to pci_controller structure which could be useful for other controllers
> too. What do you think?
>
> Then there are some other ppc_md. calling like pcibios_after_init which
> if I see correctly not used for ppc too.
We may not be using after_init() anymore in which case you are welcome
to send a patch to remove it :-)
As for the others, well ... maybe you can do wrappers for these that
call into ppc_md. on powerpc and into some kind of arch_pci_ops. that
the platform provides on microblaze ?
I'm not sure moving them into the pci_controller is the best way to go
there.
> The next thing is that some files contains asm/machdep.h which could be
> added to asm/pci-bridge.h and the same is for asm/ppc-pci.h
Yeah, moving includes like that is ok.
> Files contains CONFIG_PPC_OF and we would like to use only CONFIG_OF.
> I remember any discuss around but not sure what was the conclusion on
> powerpc.
I think that should be allright, Grant, any objection there ?
> Part of headers are the same that's why there will be a space to move
> them to asm-generic.
If you can convince other archs that it makes sense to do so ? :-)
> Anyway: I look at your dma-mapping.h and you can use
> asm-generic/dma-mapping-common.h as I am using.
Not just quite yet, there's still some stuff we need to cleanup with
the !coherent cases.
> Then I have some question about EARLY_PCI_OP in ppc_32.c. Is there any
> reason to use early_##rw##_config_##size fucntions instead of proper
> pci_bus_##rw##_config_##size functions?
> There is one comment that these functions are used before PCI scanning
> is done but there are used the same function as are in driver/pci/access.c.
> Is there any "secret" reason to do it in this way?
Well, first of all, those aren't ppc32 only anymore, they are in
pci-common.c now. Then, if you look at them you'll notice that
they are just a wrapper on top of pci_bus_* which uses a fake
pci_bus structure. IE. They are meant to be used in very early
arch fixup code at a time when we may not even have the struct
pci_bus at hand. Their use is pretty rare though, maybe we -could-
get rid of them at some stage by moving some of that fixup code.
> Thanks for this early discuss. I would like to hear your opinion and
> then I will choose solution how to add our pci support to mainline.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: michal.simek@petalogix.com
Cc: Grant Likely <grant.likely@secretlab.ca>,
linuxppc-dev@ozlabs.org, thunderbird2k@gmx.net,
John Williams <john.williams@petalogix.com>,
Arnd Bergmann <arnd@arndb.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: xilinx-pci driver and pci in general
Date: Thu, 14 Jan 2010 13:07:16 +1100 [thread overview]
Message-ID: <1263434836.724.317.camel@pasglop> (raw)
In-Reply-To: <4B4DE58D.10008@petalogix.com>
On Wed, 2010-01-13 at 16:23 +0100, Michal Simek wrote:
> The main problems are:
> ppc use ppc_md struct which we don't have it on Microblaze.
> xilinx-pci driver uses exclude_device function. This function is used in
> indirect_pci.c too. There could be a way to move that function directly
> to pci_controller structure which could be useful for other controllers
> too. What do you think?
>
> Then there are some other ppc_md. calling like pcibios_after_init which
> if I see correctly not used for ppc too.
We may not be using after_init() anymore in which case you are welcome
to send a patch to remove it :-)
As for the others, well ... maybe you can do wrappers for these that
call into ppc_md. on powerpc and into some kind of arch_pci_ops. that
the platform provides on microblaze ?
I'm not sure moving them into the pci_controller is the best way to go
there.
> The next thing is that some files contains asm/machdep.h which could be
> added to asm/pci-bridge.h and the same is for asm/ppc-pci.h
Yeah, moving includes like that is ok.
> Files contains CONFIG_PPC_OF and we would like to use only CONFIG_OF.
> I remember any discuss around but not sure what was the conclusion on
> powerpc.
I think that should be allright, Grant, any objection there ?
> Part of headers are the same that's why there will be a space to move
> them to asm-generic.
If you can convince other archs that it makes sense to do so ? :-)
> Anyway: I look at your dma-mapping.h and you can use
> asm-generic/dma-mapping-common.h as I am using.
Not just quite yet, there's still some stuff we need to cleanup with
the !coherent cases.
> Then I have some question about EARLY_PCI_OP in ppc_32.c. Is there any
> reason to use early_##rw##_config_##size fucntions instead of proper
> pci_bus_##rw##_config_##size functions?
> There is one comment that these functions are used before PCI scanning
> is done but there are used the same function as are in driver/pci/access.c.
> Is there any "secret" reason to do it in this way?
Well, first of all, those aren't ppc32 only anymore, they are in
pci-common.c now. Then, if you look at them you'll notice that
they are just a wrapper on top of pci_bus_* which uses a fake
pci_bus structure. IE. They are meant to be used in very early
arch fixup code at a time when we may not even have the struct
pci_bus at hand. Their use is pretty rare though, maybe we -could-
get rid of them at some stage by moving some of that fixup code.
> Thanks for this early discuss. I would like to hear your opinion and
> then I will choose solution how to add our pci support to mainline.
Cheers,
Ben.
next prev parent reply other threads:[~2010-01-14 2:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-13 15:23 xilinx-pci driver and pci in general Michal Simek
2010-01-14 2:07 ` Benjamin Herrenschmidt [this message]
2010-01-14 2:07 ` Benjamin Herrenschmidt
2010-01-15 9:23 ` Michal Simek
2010-01-15 9:23 ` Michal Simek
2010-01-18 17:39 ` Grant Likely
2010-01-18 17:39 ` Grant Likely
2010-01-18 17:38 ` Grant Likely
2010-01-18 17:38 ` Grant Likely
2010-01-18 17:36 ` Grant Likely
2010-01-18 17:36 ` Grant Likely
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=1263434836.724.317.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=john.williams@petalogix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michal.simek@petalogix.com \
--cc=thunderbird2k@gmx.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.