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
19 matches
Mail list logo
