From: Gary Thomas <gary@mlbassoc.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: PCI changes 2.6.26 => 2.6.28
Date: Thu, 23 Apr 2009 08:24:21 -0600 [thread overview]
Message-ID: <49F07A15.9010006@mlbassoc.com> (raw)
In-Reply-To: <B869D8DC-2A3B-4B53-8BFD-15D403CE20D4@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]
Kumar Gala wrote:
>
> On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote:
>
>> Kumar Gala wrote:
>>>
>>> On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote:
>>>
>>>>
>>>> I found the difference - in 2.6.28 the inbound/outbound windows
>>>> don't seem to be set up at all. In 2.6.26, the function
>>>> 'fsl_add_bridge'
>>>> was common among architectures and ended up calling 'setup_pci_atmu'
>>>> which created those mappings. In 2.6.28, the 83xx PCI setup code
>>>> has been refactored. It uses 'mpc83xx_add_bridge' instead of
>>>> 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-(
>>>>
>>>> I'm sure this is the problem.
>>>
>>> Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code
>>> calling setup_pci_atmu().
>>
>> It did not directly; it called 'fsl_add_bridge' which in turn called
>> 'setup_pci_atmu'
>
> Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx
> only in 83xx.
Sorry, you're correct. I got lost looking through the code :-(
No matter, none of that code seems to be relevant to the change
in behaviour.
>> I modified the 2.6.28 driver to also call this function. Now the
>> inbound/outbound windows are set up, but the bridge still has
>> no allocations, so the problem remains.
>>
>> I need to move on; I may just live with sliding the PCI space
>> up for now (doesn't really hurt anything, just seems like a hack)
>
> It is and you are glossing over a real bug.
I have found the culprit - in arch/powerpc/kernel/pci_32.c
static void
fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
#if 0
if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
class == PCI_CLASS_BRIDGE_OTHER) &&
#else
if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
#endif
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
dev->resource[i].start = 0;
dev->resource[i].end = 0;
dev->resource[i].flags = 0;
}
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_hide_host_resource_fsl);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, fixup_hide_host_resource_fsl);
This function is now (the #if 0 case is in 2.6.28) tossing out
the memory resources used by the PCI bridge itself. This makes
everything fall over, at least on my 834x platform.
This change was applied 2008-10-08, but it seems incorrect on the 834x.
> Are you using u-boot to boot? If so is the board port public?
My systems use RedBoot (I'm the original author of RedBoot, so one would
expect that). At this moment, the code isn't public, sorry.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 4387 bytes --]
From: John Rigby <jrigby@freescale.com>
To: linuxppc-dev@ozlabs.org
Cc: John Rigby <jrigby@freescale.com>
Subject: [PATCH 3/3] powerpc: pci: 5121: Hide pci bridge.
Date: Tue, 7 Oct 2008 13:00:20 -0600
Message-ID: <1223406020-12278-4-git-send-email-jrigby@freescale.com>
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
Signed-off-by: John Rigby <jrigby@freescale.com>
---
arch/powerpc/kernel/pci_32.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 174b77e..a848c63 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
-fixup_hide_host_resource_fsl(struct pci_dev* dev)
+fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
- if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
+ class == PCI_CLASS_BRIDGE_OTHER) &&
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
--
1.5.6.2.255.gbed62
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
next prev parent reply other threads:[~2009-04-23 14:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-21 16:24 PCI changes 2.6.26 => 2.6.28 Gary Thomas
2009-04-21 20:30 ` Gary Thomas
2009-04-21 20:32 ` Gary Thomas
2009-04-21 20:33 ` Kumar Gala
2009-04-21 20:45 ` Gary Thomas
2009-04-21 22:22 ` Gary Thomas
2009-04-21 22:38 ` Kumar Gala
2009-04-21 22:50 ` Kumar Gala
2009-04-21 23:00 ` Gary Thomas
2009-04-21 23:41 ` Kumar Gala
2009-04-21 23:45 ` Gary Thomas
2009-04-22 3:51 ` Kumar Gala
2009-04-23 14:24 ` Gary Thomas [this message]
2009-04-23 18:47 ` Kumar Gala
2009-04-23 22:27 ` Gary Thomas
2009-04-27 13:17 ` Benjamin Herrenschmidt
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=49F07A15.9010006@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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.