All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandros Kostopoulos" <akostop@inaccessnetworks.com>
To: "Scott Wood" <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: pci in arch/powerpc vs arch/ppc
Date: Wed, 08 Aug 2007 14:42:34 +0300	[thread overview]
Message-ID: <op.twqn4vtsnhx3hy@phoenix> (raw)
In-Reply-To: <46B88DAC.70005@freescale.com>

On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <scottwood@freescale.com>=
  =

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/write are sufficient as a workaroun=
d  =

>> for PCI9?  Who does DMA and register initialization for this (it used=
  =

>> to be done in  arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Mayb=
e  =

>> u-boot or the  bootwrapper?
>
> I don't think the workaround exists yet in arch/powerpc, despite the  =

> config option.
>

Is there a plan to be implemented on arch/powerpc, or devices with the  =

erratum will have to keep on using the legacy arch/ppc code?

>> Another question regarding resource allocation: when   =

>> alloc_resource(pci_32.c), called from pcibios_allocate_resources(),  =

>> during  pcibios init, attempts to allocate resources using  =

>> request_resource(), the  request fails. This seems to happen because =
 =

>> the previously scanned PCI  devices request resources in the form, e.=
g.  =

>> 00000- 0000f (i.e. starting  from zero), and this should be mapped  =

>> somewhere else in cpu mem space. My  question (in order to find my bu=
g)  =

>> is, who performs this mapping, from PCI  space to CPU space, the kern=
el  =

>> (and if yes, where?) or the host bridge (in  which case, I've probabl=
y  =

>> failed to configure it properly).
>
> If the error message is the one I'm thinking of (it always helps to po=
st  =

> the actual messages), that's normal for when the PCI bus hasn't been  =

> probed by the firmware.  Linux first tries to use the BARs as they're =
 =

> already set, which will obviously fail because they haven't been set, =
 =

> and then it will properly allocated them.  It's harmless verbosity,  =

> though it'd be nice to have a flag to tell the PCI layer to not bother=
  =

> trying to preserve any existing BARs.
>

Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D200=
)
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI:  parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)

The thing is, POBARs are already setup by uboot. However the resource  =

allocation for the PCI devices (not the host bridge) fails in  =

request_resource (which seems to use the region requested by the device =
as  =

is and not some mapped region in the cpu address space), and I can not  =

find where in the code happens the mapping from PCI to local bus mem  =

region. I mean, each PCI device requests some region, e.g. from 0000-00f=
f  =

and this is mapped to some region in the PCI outbound window, right. For=
  =

some reason this fails in my case, and I cannot find where in the code  =

this mapping should happen.

Thank you for your help

Alex

> -Scott

  reply	other threads:[~2007-08-08 11:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-03 14:58 pci in arch/powerpc vs arch/ppc Alexandros Kostopoulos
2007-08-03 20:10 ` Scott Wood
2007-08-04 16:39   ` Kumar Gala
2007-08-07  9:06     ` Alexandros Kostopoulos
2007-08-07 15:20       ` Scott Wood
2007-08-08 11:42         ` Alexandros Kostopoulos [this message]
2007-08-08 13:03           ` Alexandros Kostopoulos
2007-08-08 16:24             ` Scott Wood
2007-08-08 14:21           ` Alexandros Kostopoulos
2007-08-08 19:11             ` Scott Wood
2007-08-08 19:46               ` Alexandros Kostopoulos
2007-08-08 19:56                 ` Scott Wood
2007-08-08 22:20                   ` Alexandros Kostopoulos
2007-08-09 15:04                     ` Scott Wood
2007-08-09 15:56                       ` Segher Boessenkool
2007-08-11 23:28                         ` Benjamin Herrenschmidt
2007-08-10  4:32                 ` Paul Mackerras
2007-08-08 22:55             ` Benjamin Herrenschmidt
2007-08-08 16:29           ` MPC8260 PCI9 erratum Scott Wood

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=op.twqn4vtsnhx3hy@phoenix \
    --to=akostop@inaccessnetworks.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    /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.