On Wed, 2009-05-20 at 15:41 -0700, David Miller wrote:
> This is exactly what sparc64 does as well, I took the powerpc code. :)
>
> It also avoids a bunch of bugs that get unearthed as a result of
> scanning the entire hierarchy with PCI config access "pokes". Some
> PCI controllers hang when cer
From: Benjamin Herrenschmidt
Date: Thu, 21 May 2009 07:59:42 +1000
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for
On Wed, May 20, 2009 at 3:59 PM, Benjamin Herrenschmidt
wrote:
> On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
>> On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
>> >> What do you mean by fully resolve ? IE. The issue above is specific to
>> >> IO space, which you can resolve both a
On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
> On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
> >> What do you mean by fully resolve ? IE. The issue above is specific to
> >> IO space, which you can resolve both as MMIO, or as "IO" which in linux
> >> means going through the specia
> I mean that all OF devices have fully resolved MMIO resources. So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers. See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provid
On Wed, May 20, 2009 at 1:24 PM, David Miller wrote:
>> What do you mean by fully resolve ? IE. The issue above is specific to
>> IO space, which you can resolve both as MMIO, or as "IO" which in linux
>> means going through the special mapping for IO which allows the use of
>> the inX/outX instru
From: Benjamin Herrenschmidt
Date: Wed, 20 May 2009 16:51:07 +1000
> On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
>> From: Benjamin Herrenschmidt
>> Date: Wed, 20 May 2009 13:01:30 +1000
>>
>> > For example, some of the OF parsing bits may fail to convert memory
>> > addresses to IO a
On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Wed, 20 May 2009 13:01:30 +1000
>
> > For example, some of the OF parsing bits may fail to convert memory
> > addresses to IO addresses if the PCI host bridges have not been
> > discovered yet, potential
From: Benjamin Herrenschmidt
Date: Wed, 20 May 2009 13:01:30 +1000
> For example, some of the OF parsing bits may fail to convert memory
> addresses to IO addresses if the PCI host bridges have not been
> discovered yet, potentially causing issues with matching of resources
> between the early se
On Tue, 2009-05-19 at 12:05 -0700, David Miller wrote:
>
> This is also what sparc64 does :-)
>
> All of the individual sparc64 PCI controller types have a OF driver
> and then there is a common layer of OF PCI helper code to do most
> of the work.
I agree it's a good idea in the long run, but o
On Tue, 2009-05-19 at 21:17 -0600, Grant Likely wrote:
> On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> >
> >> I agree that something is called for... The first might be slightly
> >> simpler, since it would pr
On Tue, May 19, 2009 at 9:02 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
>
>> I agree that something is called for... The first might be slightly
>> simpler, since it would probably transparently deal with the presence
>> of more than one PLB
On Tue, 2009-05-19 at 09:25 -0700, Stephen Neuendorffer wrote:
> I agree that something is called for... The first might be slightly
> simpler, since it would probably transparently deal with the presence
> of more than one PLB->PCI bridge?
The current code doesn't already ?
Cheers,
Ben.
On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The b
On Tue, May 19, 2009 at 1:05 PM, David Miller wrote:
> From: Arnd Bergmann
> Date: Tue, 19 May 2009 18:12:02 +0200
>
>> On Tuesday 19 May 2009, Grant Likely wrote:
>>> 1) Probe the host controller in an of_platform driver. This has the
>>> advantage of simplicity. The probe routine will get aut
From: Arnd Bergmann
Date: Tue, 19 May 2009 18:12:02 +0200
> On Tuesday 19 May 2009, Grant Likely wrote:
>> 1) Probe the host controller in an of_platform driver. This has the
>> advantage of simplicity. The probe routine will get automatically
>> called when the PCI host controller device tree
On Tue, May 19, 2009 at 10:25 AM, Stephen Neuendorffer
wrote:
>
>> 1) Probe the host controller in an of_platform driver. This has the
>> advantage of simplicity. The probe routine will get automatically
>> called when the PCI host controller device tree node is registered
>> with the of_platfor
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model
On Tuesday 19 May 2009, Grant Likely wrote:
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthoo
Hey all,
I've been having some thoughts on PCI host controller probing and how
best to handle it. Currently AFAICT, the SoC platform code explicitly
calls the PCI setup code. In all of the existing SoCs this works fine
because there is SoC specific platform code which knows what PCI
busses to ex
20 matches
Mail list logo
