From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM PCI controller registration and representation using device tree?
Date: Sun, 3 Jun 2012 05:56:49 +0000 [thread overview]
Message-ID: <201206030556.49821.arnd@arndb.de> (raw)
In-Reply-To: <4113992.BTnO0ZYQON@bender>
On Saturday 02 June 2012, Florian Fainelli wrote:
> I was wondering if anyone had started working on representing the various PCI
> controllers found on SoCs to a device tree representation?
>
> It seems like quite some generic code could be borrowed from PowerPC,
> especially the parsing of the PCI ranges, though I don't see ARM directly
> exposing a struct pci_controller to easily allow that.
>
> Any thoughts about this?
I think the PCI host controller code should be a lot more generic than it
currently is. Each architecture has to provide quite a bit of infrastructure
and the differences are to a large part not related to the CPU architecture.
I'd love to get to the point where we can have host controllers defined
in drivers/pci/host/*.c in a way that is completely architecture independent.
Alpha, ia64, microblaze, mips, powerpc, tile and xtensa all have a structure
named "pci_controller" for doing this, but I think they are all different.
ARM has two structures: pci_sys_data (corresponds to pci_controller) and
hw_pci mostly to provide function pointers that are all the same for each
instance. arch/sh has a pci_channel that does the same thing and parisc
has pci_hba_data.
I don't think it's realistic to aim for completely unifying those structures
and implementations, but we can try to define a new architecture independent
abstraction that covers all the common parts and has a pointer the architecture
specific data, which can hold the more obscure things.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Florian Fainelli
<florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Subject: Re: ARM PCI controller registration and representation using device tree?
Date: Sun, 3 Jun 2012 05:56:49 +0000 [thread overview]
Message-ID: <201206030556.49821.arnd@arndb.de> (raw)
In-Reply-To: <4113992.BTnO0ZYQON@bender>
On Saturday 02 June 2012, Florian Fainelli wrote:
> I was wondering if anyone had started working on representing the various PCI
> controllers found on SoCs to a device tree representation?
>
> It seems like quite some generic code could be borrowed from PowerPC,
> especially the parsing of the PCI ranges, though I don't see ARM directly
> exposing a struct pci_controller to easily allow that.
>
> Any thoughts about this?
I think the PCI host controller code should be a lot more generic than it
currently is. Each architecture has to provide quite a bit of infrastructure
and the differences are to a large part not related to the CPU architecture.
I'd love to get to the point where we can have host controllers defined
in drivers/pci/host/*.c in a way that is completely architecture independent.
Alpha, ia64, microblaze, mips, powerpc, tile and xtensa all have a structure
named "pci_controller" for doing this, but I think they are all different.
ARM has two structures: pci_sys_data (corresponds to pci_controller) and
hw_pci mostly to provide function pointers that are all the same for each
instance. arch/sh has a pci_channel that does the same thing and parisc
has pci_hba_data.
I don't think it's realistic to aim for completely unifying those structures
and implementations, but we can try to define a new architecture independent
abstraction that covers all the common parts and has a pointer the architecture
specific data, which can hold the more obscure things.
Arnd
next prev parent reply other threads:[~2012-06-03 5:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-02 14:18 ARM PCI controller registration and representation using device tree? Florian Fainelli
2012-06-02 14:18 ` Florian Fainelli
2012-06-02 14:34 ` Russell King - ARM Linux
2012-06-02 14:34 ` Russell King - ARM Linux
2012-06-03 2:41 ` Arnd Bergmann
2012-06-03 2:41 ` Arnd Bergmann
2012-06-03 7:55 ` Russell King - ARM Linux
2012-06-03 7:55 ` Russell King - ARM Linux
2012-06-03 11:54 ` Arnd Bergmann
2012-06-03 11:54 ` Arnd Bergmann
2012-06-02 20:48 ` Rob Herring
2012-06-02 20:48 ` Rob Herring
2012-06-03 5:56 ` Arnd Bergmann [this message]
2012-06-03 5:56 ` Arnd Bergmann
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=201206030556.49821.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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.