On Thu, 2007-08-09 at 17:56 +0200, Segher Boessenkool wrote:
> > It means the bus on which legacy I/O ports can be found. It's a fairly
> > broken concept; each host bridge should really be treated as a
> > completely separate entity, and if something like a VGA card has legacy
> > I/O ports that
Alexandros Kostopoulos writes:
> In mpc8272ads.dts, the ranges property for pci is:
>
> ranges = <4200 0 8000 8000 0 2000
> 0200 0 a000 a000 0 2000
> 0100 0 f600 0 0200>;
>
> The third obviously corresponds to IO space. So,
> It means the bus on which legacy I/O ports can be found. It's a fairly
> broken concept; each host bridge should really be treated as a
> completely separate entity, and if something like a VGA card has legacy
> I/O ports that need to be used, they should be looked for on the same
> PCI bus as t
Alexandros Kostopoulos wrote:
> Hi Scott,
>
> please allow me to insist a little bit more on this.
No problem. :-)
> 1. As far as the device tree is concerned, it is defined that the first 3
> numbers in every line of the ranges property (for our case, with #address-
> cells=3) is the PCI addr
On Wed, 2007-08-08 at 17:21 +0300, Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges, when
> parsing the ranges for MEM and I/O space, the res->start for mem is
> correctly set to ranges[na+2], which is the cpu address in the ranges
> propert
> No, because as I said, res->start is relative to the start of IO-space.
> The in/out functions add isa_io_base to the address.
>
Hi Scott,
please allow me to insist a little bit more on this.
1. As far as the device tree is concerned, it is defined that the first 3
numbers in every line
Alexandros Kostopoulos wrote:
> I was referring to the allocation of primary bus' IO space based on the
> device tree. I understand that IO-space resources are relative to the start
> of the primary bus' IO space. But I think the primary bus IO space allocation
> itself is broken. Let me explain
Scott Wood <[EMAIL PROTECTED]> said:
> Alexandros Kostopoulos wrote:
> > I've noticed the following: In function pci_process_bridge_OF_ranges,
> > when parsing the ranges for MEM and I/O space, the res->start for mem
> > is correctly set to ranges[na+2], which is the cpu address in the
> > ra
Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges,
> when parsing the ranges for MEM and I/O space, the res->start for mem
> is correctly set to ranges[na+2], which is the cpu address in the
> ranges property. However, in I/O related code, re
Alexandros Kostopoulos wrote:
>> Well, the error message is:
>> PCI::00:16.0: Resource 0: -0fff (f=200)
>> PCI: Cannot allocate resource region 0 of device :00:16.0
>> PCI: parent is c03c4058: 8000-bfff (f=200)
[snip]
> Oops, I think I fo
Hi all,
I've noticed the following: In function pci_process_bridge_OF_ranges, when
parsing the ranges for MEM and I/O space, the res->start for mem is
correctly set to ranges[na+2], which is the cpu address in the ranges
property. However, in I/O related code, res->start is set to ranges[2],
On Wed, 08 Aug 2007 14:42:34 +0300, Alexandros Kostopoulos
<[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <[EMAIL PROTECTED]>
> wrote:
>
>> Alexandros Kostopoulos wrote:
>>> Except from some macros arch/powerpc/include/asm/io.h /
>>> mpc8260_pci9.h, I can seem t
On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <[EMAIL PROTECTED]>
wrote:
> Alexandros Kostopoulos wrote:
>> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h,
>> I can seem to find anywhere the code regarding PCI Erratum 9. The
>> defined macros(in io.h) for read/writ
Alexandros Kostopoulos wrote:
> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h,
> I can seem to find anywhere the code regarding PCI Erratum 9. The
> defined macros(in io.h) for read/write are sufficient as a workaround
> for PCI9? Who does DMA and register initializat
Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h, I
can seem to find anywhere the code regarding PCI Erratum 9. The defined
macros(in io.h) for read/write are sufficient as a workaround for PCI9?
Who does DMA and register initialization for this (it used to be done in
On Aug 3, 2007, at 3:10 PM, Scott Wood wrote:
> On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos
> wrote:
>> Hi all,
>> in the old arch/ppc tree, there was a function called
>> pq2ads_setup_pci()
>> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering,
>> where
>
On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote:
> Hi all,
> in the old arch/ppc tree, there was a function called pq2ads_setup_pci()
> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
> are these registers configured now in arch/powerpc? I can't se
Hi all,
in the old arch/ppc tree, there was a function called pq2ads_setup_pci()
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
are these registers configured now in arch/powerpc? I can't seem to find
these code now.
Also, I can see that now bus 0, dev 0 (which I thi
18 matches
Mail list logo
