* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: David Daney @ 2011-01-27 20:32 UTC (permalink / raw)
To: Scott Wood
Cc: Jeremy Fitzhardinge, Coly Li, linux-kernel, Yong Zhang, Wang Cong,
linuxppc-dev
In-Reply-To: <20110127140420.2c727f36@udp111988uds.am.freescale.net>
On 01/27/2011 12:04 PM, Scott Wood wrote:
> On Thu, 27 Jan 2011 09:57:39 -0800
> David Daney<ddaney@caviumnetworks.com> wrote:
>
>> On 01/27/2011 04:12 AM, Coly Li wrote:
>>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>>> index 065c590..10889a6 100644
>>> --- a/arch/powerpc/include/asm/bug.h
>>> +++ b/arch/powerpc/include/asm/bug.h
>>> @@ -2,6 +2,7 @@
>>> #define _ASM_POWERPC_BUG_H
>>> #ifdef __KERNEL__
>>>
>>> +#include<linux/compiler.h>
>>> #include<asm/asm-compat.h>
>>>
>>> /*
>>> @@ -71,7 +72,7 @@
>>> unreachable(); \
>>> } while (0)
>>>
>>> -#define BUG_ON(x) do { \
>>> +#define __BUG_ON(x) do { \
>>> if (__builtin_constant_p(x)) { \
>>> if (x) \
>>> BUG(); \
>>> @@ -85,6 +86,8 @@
>>> } \
>>> } while (0)
>>>
>>> +#define BUG_ON(x) __BUG_ON(unlikely(x))
>>> +
>>
>> This is the same type of frobbing you were trying to do to MIPS.
>>
>> I will let the powerpc maintainers weigh in on it, but my opinion is
>> that, as with MIPS, BUG_ON() is expanded to a single machine
>> instruction, and this unlikely() business will not change the generated
>> code in any useful way. It is thus gratuitous code churn and
>> complexification.
>
> What about just doing this:
>
> #define BUG() __builtin_trap()
>
> #define BUG_ON(x) do { \
> if (x) \
> BUG(); \
> } while (0)
>
> GCC should produce better code than forcing it into twnei. A simple
> BUG_ON(x != y) currently generates something like this (GCC 4.3):
>
> xor r0,r11,r0
> addic r10,r0,-1
> subfe r9,r10,r0
> twnei r9,0
>
> Or this (GCC 4.5):
>
> xor r0,r11,r0
> cntlzw r0,r0
> srwi r0,r0,5
> xori r0,r0,1
> twnei r0,0
>
> Instead of:
>
> twne r0,r11
>
> And if GCC doesn't treat code paths that lead to __builtin_trap() as
> unlikely (which could make a difference with complex expressions,
> even with a conditional trap instruction), that's something that could
> and should be fixed in GCC.
>
> The downside is that GCC says, "The mechanism used may vary from
> release to release so you should not rely on any particular
> implementation." However, some architectures (sparc, m68k, ia64)
> already use __builtin_trap() for this, it seems unlikely that future GCC
> versions would switch away from using the trap instruction[1], and there
> doesn't seem to be a better-defined way to make GCC generate trap
> instructions intelligently.
>
This is good in theory, however powerpc has this _EMIT_BUG_ENTRY
business that wouldn't work with __builtin_trap().
David Daney
> -Scott
>
> [1] A more likely possibility is that an older compiler just generates a
> call to abort() or similar, and later versions implemented trap -- need
> to check what the oldest supported GCC does.
>
^ permalink raw reply
* [PATCH] powerpc: fix memory limits when starting at a non-zero address
From: Scott Wood @ 2011-01-27 20:30 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
memblock_enforce_memory_limit() takes the desired maximum quantity of memory
to end up with, not an address above which memory will not be used.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/mm/init_32.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 7185f0d..05b7139 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -97,7 +97,7 @@ static void __init move_device_tree(void)
start = __pa(initial_boot_params);
size = be32_to_cpu(initial_boot_params->totalsize);
- if ((memory_limit && (start + size) > memory_limit) ||
+ if ((memory_limit && (start + size) > PHYSICAL_START + memory_limit) ||
overlaps_crashkernel(start, size)) {
p = __va(memblock_alloc(size, PAGE_SIZE));
memcpy(p, initial_boot_params, size);
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 742da43..d65b591 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -148,7 +148,7 @@ void __init MMU_init(void)
lowmem_end_addr = memstart_addr + total_lowmem;
#ifndef CONFIG_HIGHMEM
total_memory = total_lowmem;
- memblock_enforce_memory_limit(lowmem_end_addr);
+ memblock_enforce_memory_limit(total_lowmem);
memblock_analyze();
#endif /* CONFIG_HIGHMEM */
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: David Miller @ 2011-01-27 22:23 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev, mlcreech, oakad
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
Please CC: netdev on future submissions of this patch, otherwise I
won't see it in my queue.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
From: Meador Inge @ 2011-01-27 23:50 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Blanchard, Hollis, Wood Scott-B07421,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150307A5C8@039-SN1MPN1-004.039d.mgd.msft.net>
On 01/20/2011 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Meador Inge [mailto:meador_inge@mentor.com]
>> Sent: Wednesday, January 19, 2011 6:08 PM
>> To: Yoder Stuart-B08248
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; devicetree-
>> discuss@lists.ozlabs.org; Blanchard, Hollis
>> Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
>>
>> On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote:
>>>
>>>> +** Optional properties:
>>>> +
>>>> + - no-reset : The presence of this property indicates that the MPIC
>>>> + should not be reset during runtime initialization.
>>>> + - protected-sources : Specifies a list of interrupt sources that
>>>> + are not
>>>> + available for use and whose corresponding
>>>> + vectors
>>>> + should not be initialized. A typical use
>>>> + case for
>>>> + this property is in AMP systems where multiple
>>>> + independent operating systems need to share
>>>> + the MPIC
>>>> + without clobbering each other.
>>>
>>> Is "protected-sources" really needed for AMP systems to tell the OSes
>>> not to clobber each other? Won't each OS be given a device tree with
>>> only its interrupt sources? ...so you know what you are allowed to
>>> touch.
>>
>> This was discussed a little bit already [1, 2]. The MPIC driver currently
>> initializes the VECPRI register for all interrupt sources, which can lead
>> to the aforementioned clobbering.
>
> For sources that are protected and not to be touched, it seems
> that the other need is for the OS to know (be guaranteed?) that
> those sources have been put in state where the source is masked
> or directed to other cores. You can't have interrupts occurring
> on sources that you are not allowed to initialize.
>
> So the "no-reset" property could potentially cover this as well-- if it was
> defined to mean "don't reset the mpic" and boot firmware has put all sources
> in a sane initial state. And we wouldn't need the "protected-sources"
> property any longer.
>
This seems reasonable to me. If "no-reset" is there, then we will not
reset the MPIC and *only* sources explicitly listed in "interrupts"
properties are up for any sort of initialization (e.g. the VECPRI init).
If "no-reset" is not there, then anything is free game.
In terms of implementation, I think we can (1) pull the protected
sources code, (2) keep the VECPRI initialization in 'mpic_init' from
happening when "no-reset" is present, and (3) "lazily" perform the
VECPRI initialization in 'mpic_host_map' (this way only sources
mentioned in the device tree are initialized).
I will send out a patch with these updates tomorrow. I also CC'd Ben,
who wrote the original protected sources work, to make sure something
about the original use case is not being missed.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Alex Dubov @ 2011-01-28 2:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, davem, mlcreech
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
> > -=A0=A0=A0 =A0=A0=A0=0A> gfar_tx_checksum(skb, fcb);=0A> > +=A0=A0=A0 =
=A0=A0=A0 switch=0A> (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))=0A> >=
+=A0=A0=A0 =A0=A0=A0=0A> =A0=A0=A0 ? 1 : 0) {=0A> =0A> The switch construc=
tion is quite bizarre. ;-) Why not=0A> =0A=0AMy testing shows that even on =
broken chips unaligned packets are quite rare=0A(only some SYN packets seem=
to be affected). So I tried to leave the=0Achecksum offload path as the mo=
st preferred one.=0A=0A=0A=0A
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 08/02/2011)
From: Michael Barry @ 2011-01-28 4:00 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 08/02/2011.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 77, Issue 92" sent on 27/1/11 20:32:14.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* [PATCH v2] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Alex Dubov @ 2011-01-28 4:37 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, linuxppc-dev, davem, mlcreech
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,=0A=
older revisions of gianfar controllers will be unable to calculate a TCP/UD=
P=0Apacket checksum for some alignments of the appropriate FCB. This patch =
checks=0Afor FCB alignment on such controllers and falls back to software c=
hecksumming=0Aif the alignment is known to be bad.=0A=0ASigned-off-by: Alex=
Dubov <oakad@yahoo.com>=0A---=0AChanges for v2:=0A - Make indentation sl=
ightly more consistent.=0A - Replace bizarre switch-based condition with =
plain boring one.=0A=0A drivers/net/gianfar.c | 16 ++++++++++++++--=0A dr=
ivers/net/gianfar.h | 1 +=0A 2 files changed, 15 insertions(+), 2 deleti=
ons(-)=0A=0Adiff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c=0Ain=
dex 5ed8f9f..3da19a5 100644=0A--- a/drivers/net/gianfar.c=0A+++ b/drivers/n=
et/gianfar.c=0A@@ -950,6 +950,11 @@ static void gfar_detect_errata(struct g=
far_private *priv)=0A =09=09=09(pvr =3D=3D 0x80861010 && (mod & 0xfff9) =3D=
=3D 0x80c0))=0A =09=09priv->errata |=3D GFAR_ERRATA_A002;=0A =0A+=09/* MPC8=
313 Rev < 2.0, MPC8548 rev 2.0 */=0A+=09if ((pvr =3D=3D 0x80850010 && mod =
=3D=3D 0x80b0 && rev < 0x0020) ||=0A+=09=09=09(pvr =3D=3D 0x80210020 && mod=
=3D=3D 0x8030 && rev =3D=3D 0x0020))=0A+=09=09priv->errata |=3D GFAR_ERRAT=
A_12;=0A+=0A =09if (priv->errata)=0A =09=09dev_info(dev, "enabled errata wo=
rkarounds, flags: 0x%x\n",=0A =09=09=09 priv->errata);=0A@@ -2156,8 +2161,1=
5 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev=
)=0A =09/* Set up checksumming */=0A =09if (CHECKSUM_PARTIAL =3D=3D skb->ip=
_summed) {=0A =09=09fcb =3D gfar_add_fcb(skb);=0A-=09=09lstatus |=3D BD_LFL=
AG(TXBD_TOE);=0A-=09=09gfar_tx_checksum(skb, fcb);=0A+=09=09/* as specified=
by errata */=0A+=09=09if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)=
=0A+=09=09=09 && ((unsigned long)fcb % 0x20) > 0x18)) {=0A+=09=09=09__s=
kb_pull(skb, GMAC_FCB_LEN);=0A+=09=09=09skb_checksum_help(skb);=0A+=09=09} =
else {=0A+=09=09=09lstatus |=3D BD_LFLAG(TXBD_TOE);=0A+=09=09=09gfar_tx_che=
cksum(skb, fcb);=0A+=09=09}=0A =09}=0A =0A =09if (vlan_tx_tag_present(skb))=
{=0Adiff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h=0Aindex 54d=
e413..ec5d595 100644=0A--- a/drivers/net/gianfar.h=0A+++ b/drivers/net/gian=
far.h=0A@@ -1039,6 +1039,7 @@ enum gfar_errata {=0A =09GFAR_ERRATA_74=09=09=
=3D 0x01,=0A =09GFAR_ERRATA_76=09=09=3D 0x02,=0A =09GFAR_ERRATA_A002=09=3D =
0x04,=0A+=09GFAR_ERRATA_12=09=09=3D 0x08, /* a.k.a errata eTSEC49 */=0A };=
=0A =0A /* Struct stolen almost completely (and shamelessly) from the FCC e=
net source=0A-- =0A1.7.3.2=0A=0A=0A=0A=0A
^ permalink raw reply
* RE: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: David Laight @ 2011-01-28 9:05 UTC (permalink / raw)
To: David Daney, Coly Li
Cc: Wang Cong, Jeremy Fitzhardinge, linuxppc-dev, linux-kernel,
Yong Zhang
In-Reply-To: <4D41B213.4070606@caviumnetworks.com>
=20
> > +#define __BUG_ON(x) do { \
> > if (__builtin_constant_p(x)) { \
> > if (x) \
> > BUG(); \
> > @@ -85,6 +86,8 @@
> > } \
> > } while (0)
> >
> > +#define BUG_ON(x) __BUG_ON(unlikely(x))
> > +
>From my experiments, adding an 'unlikely' at that point isn't
enough for non-trivial conditions - so its presence will
give a false sense the the optimisation is present!
In particular 'if (unlikely(x && y))' needs to be
'if (unlikely(x) && unlikely(y))' in order to avoid
mispredicted branches when 'x' is false.
Also, as (I think) in some of the generated code quoted,
use of __builtin_expect() with a boolean expression can
force some versions of gcc to generate the integer
value of the expression - rather than just selecting the
branch instructions that statically predict the
normal code path.
Sometimes I've also also had to add an asm() statement
that generates no code in order to actually force a
forwards branch (so it has something to place at the
target).
(I've been counting clocks ....)
David
^ permalink raw reply
* RE: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: David Laight @ 2011-01-28 9:10 UTC (permalink / raw)
Cc: netdev, linuxppc-dev
In-Reply-To: <640295.36173.qm@web37608.mail.mud.yahoo.com>
=20
> + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
> + && ((unsigned long)fcb % 0x20) > 0x18)) {
You need to check the generated code, but I think you need:
if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
&& unlikely(((unsigned long)fcb % 0x20) > 0x18))
ie unlikely() around both the primitive comparisons.
David
^ permalink raw reply
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: Andreas Schwab @ 2011-01-28 10:14 UTC (permalink / raw)
To: David Laight
Cc: Jeremy Fitzhardinge, Coly Li, David Daney, linux-kernel,
Yong Zhang, Wang Cong, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC2D__37237.0892241181$1296205746$gmane$org@saturn3.aculab.com>
"David Laight" <David.Laight@ACULAB.COM> writes:
> Also, as (I think) in some of the generated code quoted,
> use of __builtin_expect() with a boolean expression can
> force some versions of gcc to generate the integer
> value of the expression
That's more likely a side effect of the definition of likely/unlikely:
they expand to !!(x).
Andreas.
--
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: Coly Li @ 2011-01-28 11:02 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeremy Fitzhardinge, Coly Li, David Daney, linux-kernel,
Yong Zhang, David Laight, Wang Cong, linuxppc-dev
In-Reply-To: <m31v3xxrlz.fsf@redhat.com>
On 2011年01月28日 18:14, Andreas Schwab Wrote:
> "David Laight"<David.Laight@ACULAB.COM> writes:
>
>> Also, as (I think) in some of the generated code quoted,
>> use of __builtin_expect() with a boolean expression can
>> force some versions of gcc to generate the integer
>> value of the expression
>
> That's more likely a side effect of the definition of likely/unlikely:
> they expand to !!(x).
>
It seems whether or not using unlikely() inside arch implemented BUG_ON() is arch dependent. Maybe a reasonable method
to use BUG_ON() is,
1) do not explicitly use unlikely() when using macro BUG_ON().
2) whether or not using unlikely() inside BUG_ON(), it depends on the implementation of BUG_ON(), including arch
implementation.
So from current feed back, doing "unlikely() optimization" here doesn't make anything better.
Thanks for all of your feed back :-)
--
Coly Li
^ permalink raw reply
* Need help for USB OTG feature for Canyonlands PPC460EX Board
From: sunny bhayani @ 2011-01-28 13:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
Hi All,
I am trying to enable the USB DWC OTG feature for Canyonlands PPC460EX
Board, and am using the 2.6.30 kernel from denx.
Now the issue is I am selecting the "USB Gadget" feature from the kernel
menuconfig, but the kernel log only shows,
dwc_otg: version 2.60a 22-NOV-2006
The probe() function in "drivers/usb/gadged/dwc_otg/dwc_otg_driver.c" is not
getting called. So I am not getting the following kernel boot messages:
dwc_otg: Shared Tx FIFO mode
dwc_otg: Using Slave mode
dwc_otg dwc_otg.0: DWC OTG Controller
dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 2
dwc_otg dwc_otg.0: irq 28, io mem 0x00000000
dwc_otg: dwc_otg_core_host_init: Unable to clear halt on channel 1
dwc_otg: Init: Port Power? op_state=4
Can you please let me know, what might be the problem.
Regards,
Sunny Bhayani
+91-88921-80558
[-- Attachment #2: Type: text/html, Size: 1584 bytes --]
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: Scott Wood @ 2011-01-28 16:56 UTC (permalink / raw)
To: David Laight; +Cc: netdev, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC2E@saturn3.aculab.com>
On Fri, 28 Jan 2011 09:10:46 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
>
> > + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
> > + && ((unsigned long)fcb % 0x20) > 0x18)) {
>
> You need to check the generated code, but I think you need:
>
> if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
> && unlikely(((unsigned long)fcb % 0x20) > 0x18))
>
> ie unlikely() around both the primitive comparisons.
Is the first condition actually unlikely? If you've got affected
hardware, you'll hit it every time.
If packets with the problematic alignment are rare, seems like it'd be
better to check that first.
-Scott
^ permalink raw reply
* PCIe end-point on FPGA doesn't show up on PCI bus when configured
From: Matias Garcia @ 2011-01-28 18:37 UTC (permalink / raw)
To: linuxppc-dev
I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-core
processor, and have the following conundrum: I configure the FPGA which
brings up a PCIe interface to the processor. I scan both PCI buses on
the system (I believe the second bus is behind the Freescale integrated
bridge on the first), and it doesn't show up. I initiate a reset on the
processor, and both U-boot and Linux now see the FPGA PCI device at
0000:01:00.00. I've noticed some of the memory mappings in the PCI
bridge windows are different between the two boot sequences. I've tried
all manner of pci calls (including the pcibios_fixup routines) on the
bridge device (including removing and re-scanning it), and on bus 1,
which is otherwise empty, to no avail. Following are some debug listings
from dmesg; any help/ideas in tracking down the problem (hardware or
software) is greatly appreciated.
#Boot without FPGA configured:
<snip>
Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number: 0->255
PCI host bridge /pcie@8ff70a000 ranges:
MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
/pcie@8ff70a000: PCICSRBAR @ 0xfff00000
/pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
Adjusting the memory map could reduce unnecessary bounce buffering.
/pcie@8ff70a000: DMA window size is 0x80000000
MPC85xx RDB board from Freescale Semiconductor
<...>
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref]
(disabled)
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
#Reset with FPGA configured:
<snip>
Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number: 0->255
PCI host bridge /pcie@8ff70a000 ranges:
MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
/pcie@8ff70a000: PCICSRBAR @ 0xfff00000
/pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
Adjusting the memory map could reduce unnecessary bounce buffering.
/pcie@8ff70a000: DMA window size is 0x80000000
MPC85xx RDB board from Freescale Semiconductor
<...>
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:01:00.0: [1172:0004] type 0 class 0x001000
pci 0000:01:00.0: reg 10: [mem 0x80000000-0x80ffffff]
pci 0000:01:00.0: reg 14: [mem 0x81000000-0x81ffffff]
pci 0000:01:00.0: reg 18: [mem 0x82000000-0x82ffffff]
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x80000000-0x82ffffff]
pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref]
(disabled)
irq: irq 0 on host /soc@8ff700000/pic@40000 mapped to virtual irq 16
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
Cheers,
Matias
--
*Matias Garcia*
/Embedded Software Developer/
Ross Video | Live Production Technology
www.rossvideo.com <http://www.rossvideo.com>
+1 (613) 228 1198 x4264
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: David Miller @ 2011-01-28 19:59 UTC (permalink / raw)
To: scottwood; +Cc: netdev, David.Laight, linuxppc-dev
In-Reply-To: <20110128105610.4a518456@udp111988uds.am.freescale.net>
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 28 Jan 2011 10:56:10 -0600
> On Fri, 28 Jan 2011 09:10:46 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
>
>>
>> > + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
>> > + && ((unsigned long)fcb % 0x20) > 0x18)) {
>>
>> You need to check the generated code, but I think you need:
>>
>> if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
>> && unlikely(((unsigned long)fcb % 0x20) > 0x18))
>>
>> ie unlikely() around both the primitive comparisons.
>
> Is the first condition actually unlikely? If you've got affected
> hardware, you'll hit it every time.
>
> If packets with the problematic alignment are rare, seems like it'd be
> better to check that first.
In cases like this gfar_has_errata() case, better to leave it's
likelyhood unmarked.
And yes, since it's cheaper, checking the alignment should be done
first.
^ permalink raw reply
* Re: PCIe end-point on FPGA doesn't show up on PCI bus when configured
From: Elie De Brauwer @ 2011-01-28 20:06 UTC (permalink / raw)
To: Matias Garcia; +Cc: linuxppc-dev
In-Reply-To: <4D430CD4.6060201@rossvideo.com>
On 01/28/11 19:37, Matias Garcia wrote:
> I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-core
> processor, and have the following conundrum: I configure the FPGA which
> brings up a PCIe interface to the processor. I scan both PCI buses on
> the system (I believe the second bus is behind the Freescale integrated
> bridge on the first), and it doesn't show up. I initiate a reset on the
> processor, and both U-boot and Linux now see the FPGA PCI device at
> 0000:01:00.00. I've noticed some of the memory mappings in the PCI
> bridge windows are different between the two boot sequences. I've tried
> all manner of pci calls (including the pcibios_fixup routines) on the
> bridge device (including removing and re-scanning it), and on bus 1,
> which is otherwise empty, to no avail. Following are some debug listings
> from dmesg; any help/ideas in tracking down the problem (hardware or
> software) is greatly appreciated.
>
> #Boot without FPGA configured:
> <snip>
> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
> 0->255
> PCI host bridge /pcie@8ff70a000 ranges:
> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
> Adjusting the memory map could reduce unnecessary bounce buffering.
> /pcie@8ff70a000: DMA window size is 0x80000000
> MPC85xx RDB board from Freescale Semiconductor
> <...>
> PCI: Probing PCI hardware
> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0000:00:00.0: supports D1 D2
> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:00:00.0: PME# disabled
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
> pci 0000:00:00.0: PCI bridge to [bus 01-01]
> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
> pci 0000:00:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: enabling device (0106 -> 0107)
> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
>
> #Reset with FPGA configured:
> <snip>
> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
> 0->255
> PCI host bridge /pcie@8ff70a000 ranges:
> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
> Adjusting the memory map could reduce unnecessary bounce buffering.
> /pcie@8ff70a000: DMA window size is 0x80000000
> MPC85xx RDB board from Freescale Semiconductor
> <...>
> PCI: Probing PCI hardware
> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0000:00:00.0: supports D1 D2
> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> pci 0000:00:00.0: PME# disabled
> pci 0000:01:00.0: [1172:0004] type 0 class 0x001000
> pci 0000:01:00.0: reg 10: [mem 0x80000000-0x80ffffff]
> pci 0000:01:00.0: reg 14: [mem 0x81000000-0x81ffffff]
> pci 0000:01:00.0: reg 18: [mem 0x82000000-0x82ffffff]
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
> pci 0000:00:00.0: bridge window [mem 0x80000000-0x82ffffff]
> pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref] (disabled)
> irq: irq 0 on host /soc@8ff700000/pic@40000 mapped to virtual irq 16
> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
> pci 0000:00:00.0: PCI bridge to [bus 01-01]
> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
> pci 0000:00:00.0: bridge window [mem pref disabled]
> pci 0000:00:00.0: enabling device (0106 -> 0107)
> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
Hi Mattias,
I'm doing the same on a similar setup, also a P2020 but a 2.6.36 and
with me it works just fine. However I encountered one problem. I
understand it as follows, if there is no physical PCIe link then
somewhere a flag PPC_INDIRECT_TYPE_NO_PCIE_LINK gets set. This has as
result that reading the PCIe config space will fail with a
PCIBIOS_DEVICE_NOT_FOUND (ref
http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/sysdev/indirect_pci.c#L24 )
At
http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/include/asm/pci-bridge.h#L105
they specify this as a workaround since the PCIe might hang if there is
no physical link. So my workaround for this issue was:
- load the fpga
- travel down the pci bus to the correct bus where the fpga is attached
use a pci_bus_to_host() to obtain a struct pci_controller, unset the
PPC_INDIRECT_TYPE_NO_PCIE_LINK and call a pci_rescon_bus() on that bus.
After doing this I can find access the FPGA, and reload it if needed.
Not a clue if this is 'the proper way' to do it, but it works for me.
gr
E.
--
Elie De Brauwer
^ permalink raw reply
* State of suspend-to-ram?
From: Mathias Krause @ 2011-01-29 18:43 UTC (permalink / raw)
To: linuxppc-dev
Hi all!
First of all: Sorry, this is the wrong mailing list, but I searched a =
lot and found none that would fit to PPC user-related problems -- =
linux-ppc would have been one but this one seems to be dead since 2004?!
I've a G4 based Mac mini and would like to suspend it to RAM, though the =
vanilla kernel doesn't allow me to do this (/sys/power/state mentions =
only "disk"). The reason for this is my platform is marked as =
PMAC_MB_MAY_SLEEP instead of PMAC_MB_CAN_SLEEP in =
arch/powerpc/platforms/powermac/feature.c. So I changed that to be =
PMAC_MB_CAN_SLEEP and was able to suspend the system using the =
pm-suspend script from the pm-utils suite. The LED on the front was =
pulsing like it is when suspended under MacOS X. After pushing the power =
button the system started to resume but just got stuck. I see no =
messages on the console, nothing in syslog. So I assume the system =
panics pretty early in the resume path. Because the system has no serial =
console the debug capabilities are fairly limited. Any hints why this =
doesn't work or how to debug this any further?
Some system information:
mk@maxi:~$ cat /proc/cpuinfo=20
processor : 0
cpu : 7447A, altivec supported
clock : 1416.666661MHz
revision : 1.2 (pvr 8003 0102)
bogomips : 83.24
timebase : 41620997
platform : PowerMac
model : PowerMac10,1
machine : PowerMac10,1
motherboard : PowerMac10,1 MacRISC3 Power Macintosh=20
detected as : 287 (Mac mini)
pmac flags : 00000001
L2 cache : 512K unified
pmac-generation : NewWorld
Memory : 1024 MB
mk@maxi:~$ uname -a=20
Linux maxi 2.6.37+ #2 Mon Jan 24 08:56:01 CET 2011 ppc GNU/Linux
Regards,
Mathias
^ permalink raw reply
* Re: 2.6.37-git17 virtual IO boot failure
From: Anton Blanchard @ 2011-01-29 22:22 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: jlarrew, linuxppc-dev
In-Reply-To: <20110119043757.GA29865@us.ibm.com>
Hi,
> FWIW, I looked at Anton's logs, and I don't think the boot failed, per
> se. I think it may have timed out (but not positive on that). I was
> able to boot 2.6.27-git17 on the exact same box, albeit it locks up
> at a later point (the sd abort I e-mailed about in a follow-up).
This fail bisects down to the VPHN (shared processor affinity) patch.
I've got some fixes on the way.
Anton
^ permalink raw reply
* [PATCH 1/5] powerpc/numa: Only use active VPHN count fields
From: Anton Blanchard @ 2011-01-29 22:24 UTC (permalink / raw)
To: Nishanth Aravamudan, Benjamin Herrenschmidt, jlarrew; +Cc: linuxppc-dev
In-Reply-To: <20110130092217.70ebb424@kryten>
VPHN supports up to 8 distance fields but the number of entries in
ibm,associativity-reference-points signifies how many are in use.
Don't look at all the VPHN counts, only distance_ref_points_depth
worth.
Since we already cap our distance metrics at MAX_DISTANCE_REF_POINTS,
use that to size the VPHN arrays and add a BUILD_BUG_ON to avoid it growing
larger than the VPHN maximum of 8.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/numa.c 2011-01-29 10:48:21.280075270 +1100
+++ linux-2.6/arch/powerpc/mm/numa.c 2011-01-29 10:54:24.547203014 +1100
@@ -1291,8 +1291,7 @@ u64 memory_hotplug_max(void)
/* Vrtual Processor Home Node (VPHN) support */
#ifdef CONFIG_PPC_SPLPAR
-#define VPHN_NR_CHANGE_CTRS (8)
-static u8 vphn_cpu_change_counts[NR_CPUS][VPHN_NR_CHANGE_CTRS];
+static u8 vphn_cpu_change_counts[NR_CPUS][MAX_DISTANCE_REF_POINTS];
static cpumask_t cpu_associativity_changes_mask;
static int vphn_enabled;
static void set_topology_timer(void);
@@ -1305,12 +1304,15 @@ static void setup_cpu_associativity_chan
{
int cpu = 0;
+ /* The VPHN feature supports a maximum of 8 reference points */
+ BUILD_BUG_ON(MAX_DISTANCE_REF_POINTS > 8);
+
for_each_possible_cpu(cpu) {
int i = 0;
u8 *counts = vphn_cpu_change_counts[cpu];
volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
- for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
+ for (i = 0; i < distance_ref_points_depth; i++) {
counts[i] = hypervisor_counts[i];
}
}
@@ -1339,7 +1341,7 @@ static int update_cpu_associativity_chan
u8 *counts = vphn_cpu_change_counts[cpu];
volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
- for (i = 0; i < VPHN_NR_CHANGE_CTRS; i++) {
+ for (i = 0; i < distance_ref_points_depth; i++) {
if (hypervisor_counts[i] > counts[i]) {
counts[i] = hypervisor_counts[i];
changed = 1;
^ permalink raw reply
* [PATCH 2/5] powerpc/numa: Check for all VPHN changes
From: Anton Blanchard @ 2011-01-29 22:26 UTC (permalink / raw)
To: Nishanth Aravamudan, Benjamin Herrenschmidt, jlarrew; +Cc: linuxppc-dev
In-Reply-To: <20110130092434.42a887ef@kryten>
The hypervisor uses unsigned 1 byte counters to signal topology changes to
the OS. Since they can wrap we need to check for any difference, not just if
the hypervisor count is greater than the previous count.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/numa.c 2011-01-29 11:16:56.741843175 +1100
+++ linux-2.6/arch/powerpc/mm/numa.c 2011-01-29 12:44:42.059356526 +1100
@@ -1342,7 +1342,7 @@ static int update_cpu_associativity_chan
volatile u8 *hypervisor_counts = lppaca[cpu].vphn_assoc_counts;
for (i = 0; i < distance_ref_points_depth; i++) {
- if (hypervisor_counts[i] > counts[i]) {
+ if (hypervisor_counts[i] != counts[i]) {
counts[i] = hypervisor_counts[i];
changed = 1;
}
^ permalink raw reply
* [PATCH 3/5] powerpc/numa: Add length when creating OF properties via VPHN
From: Anton Blanchard @ 2011-01-29 22:28 UTC (permalink / raw)
To: Nishanth Aravamudan, Benjamin Herrenschmidt, jlarrew; +Cc: linuxppc-dev
In-Reply-To: <20110130092434.42a887ef@kryten>
The rest of the NUMA code expects an OF associativity property with
the first cell containing the length. Without this fix all topology changes
cause us to misparse the property and put the cpu into node 0.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/numa.c 2011-01-29 12:45:09.257654450 +1100
+++ linux-2.6/arch/powerpc/mm/numa.c 2011-01-29 12:56:30.854975882 +1100
@@ -1356,8 +1356,11 @@ static int update_cpu_associativity_chan
return nr_cpus;
}
-/* 6 64-bit registers unpacked into 12 32-bit associativity values */
-#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32))
+/*
+ * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
+ * the complete property we have to add the length in the first cell.
+ */
+#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32) + 1)
/*
* Convert the associativity domain numbers returned from the hypervisor
@@ -1373,7 +1376,7 @@ static int vphn_unpack_associativity(con
#define VPHN_FIELD_MSB (0x8000)
#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
- for (i = 0; i < VPHN_ASSOC_BUFSIZE; i++) {
+ for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
if (*field == VPHN_FIELD_UNUSED) {
/* All significant fields processed, and remaining
* fields contain the reserved value of all 1's.
@@ -1398,6 +1401,9 @@ static int vphn_unpack_associativity(con
}
}
+ /* The first cell contains the length of the property */
+ unpacked[0] = nr_assoc_doms;
+
return nr_assoc_doms;
}
^ permalink raw reply
* [PATCH 4/5] powerpc/numa: Disable VPHN on dedicated processor partitions
From: Anton Blanchard @ 2011-01-29 22:35 UTC (permalink / raw)
To: Nishanth Aravamudan, Benjamin Herrenschmidt, jlarrew; +Cc: linuxppc-dev
In-Reply-To: <20110130092434.42a887ef@kryten>
There is no need to start up the timer and monitor topology changes on a
dedicated processor partition, so disable it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/numa.c 2011-01-29 12:58:01.849279835 +1100
+++ linux-2.6/arch/powerpc/mm/numa.c 2011-01-29 12:58:02.489239819 +1100
@@ -1520,7 +1520,8 @@ int start_topology_update(void)
{
int rc = 0;
- if (firmware_has_feature(FW_FEATURE_VPHN)) {
+ if (firmware_has_feature(FW_FEATURE_VPHN) &&
+ get_lppaca()->shared_proc) {
vphn_enabled = 1;
setup_cpu_associativity_change_counters();
init_timer_deferrable(&topology_timer);
^ permalink raw reply
* [PATCH 5/5] powerpc/numa: Fix bug in unmap_cpu_from_node
From: Anton Blanchard @ 2011-01-29 22:37 UTC (permalink / raw)
To: Nishanth Aravamudan, Benjamin Herrenschmidt, jlarrew; +Cc: linuxppc-dev
In-Reply-To: <20110130092434.42a887ef@kryten>
When converting to the new cpumask code I screwed up:
- if (cpu_isset(cpu, numa_cpumask_lookup_table[node])) {
- cpu_clear(cpu, numa_cpumask_lookup_table[node]);
+ if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
+ cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
This was introduced in commit 25863de07af9 (powerpc/cpumask: Convert NUMA code
to new cpumask API)
Fix it.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-2.6/arch/powerpc/mm/numa.c
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/numa.c 2011-01-29 13:06:05.259039081 +1100
+++ linux-2.6/arch/powerpc/mm/numa.c 2011-01-30 08:26:48.148366563 +1100
@@ -186,7 +186,7 @@ static void unmap_cpu_from_node(unsigned
dbg("removing cpu %lu from node %d\n", cpu, node);
if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
- cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
+ cpumask_clear_cpu(cpu, node_to_cpumask_map[node]);
} else {
printk(KERN_ERR "WARNING: cpu %lu not found in node %d\n",
cpu, node);
^ permalink raw reply
* Re: PCIe end-point on FPGA doesn't show up on PCI bus when configured
From: tiejun.chen @ 2011-01-30 3:07 UTC (permalink / raw)
To: Elie De Brauwer, Matias Garcia; +Cc: linuxppc-dev
In-Reply-To: <4D4321E1.7060506@gmail.com>
Elie De Brauwer wrote:
> On 01/28/11 19:37, Matias Garcia wrote:
>> I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-core
>> processor, and have the following conundrum: I configure the FPGA which
>> brings up a PCIe interface to the processor. I scan both PCI buses on
>> the system (I believe the second bus is behind the Freescale integrated
>> bridge on the first), and it doesn't show up. I initiate a reset on the
>> processor, and both U-boot and Linux now see the FPGA PCI device at
>> 0000:01:00.00. I've noticed some of the memory mappings in the PCI
>> bridge windows are different between the two boot sequences. I've tried
>> all manner of pci calls (including the pcibios_fixup routines) on the
>> bridge device (including removing and re-scanning it), and on bus 1,
>> which is otherwise empty, to no avail. Following are some debug listings
>> from dmesg; any help/ideas in tracking down the problem (hardware or
>> software) is greatly appreciated.
>>
>> #Boot without FPGA configured:
>> <snip>
>> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
>> 0->255
>> PCI host bridge /pcie@8ff70a000 ranges:
>> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
>> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
>> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
>> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
>> Adjusting the memory map could reduce unnecessary bounce buffering.
>> /pcie@8ff70a000: DMA window size is 0x80000000
>> MPC85xx RDB board from Freescale Semiconductor
>> <...>
>> PCI: Probing PCI hardware
>> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>> pci 0000:00:00.0: supports D1 D2
>> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
>> pci 0000:00:00.0: PME# disabled
>> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
>> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
>> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref]
>> (disabled)
>> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
>> pci 0000:00:00.0: PCI bridge to [bus 01-01]
>> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
>> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
>> pci 0000:00:00.0: bridge window [mem pref disabled]
>> pci 0000:00:00.0: enabling device (0106 -> 0107)
>> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
>> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
>> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
>> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
>>
>> #Reset with FPGA configured:
>> <snip>
>> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
>> 0->255
>> PCI host bridge /pcie@8ff70a000 ranges:
>> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
>> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
>> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
>> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
>> Adjusting the memory map could reduce unnecessary bounce buffering.
>> /pcie@8ff70a000: DMA window size is 0x80000000
>> MPC85xx RDB board from Freescale Semiconductor
>> <...>
>> PCI: Probing PCI hardware
>> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>> pci 0000:00:00.0: supports D1 D2
>> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
>> pci 0000:00:00.0: PME# disabled
>> pci 0000:01:00.0: [1172:0004] type 0 class 0x001000
>> pci 0000:01:00.0: reg 10: [mem 0x80000000-0x80ffffff]
>> pci 0000:01:00.0: reg 14: [mem 0x81000000-0x81ffffff]
>> pci 0000:01:00.0: reg 18: [mem 0x82000000-0x82ffffff]
>> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
>> pci 0000:00:00.0: bridge window [mem 0x80000000-0x82ffffff]
>> pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref]
>> (disabled)
>> irq: irq 0 on host /soc@8ff700000/pic@40000 mapped to virtual irq 16
>> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
>> pci 0000:00:00.0: PCI bridge to [bus 01-01]
>> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
>> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
>> pci 0000:00:00.0: bridge window [mem pref disabled]
>> pci 0000:00:00.0: enabling device (0106 -> 0107)
>> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
>> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
>> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
>> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
>
>
> Hi Mattias,
>
> I'm doing the same on a similar setup, also a P2020 but a 2.6.36 and
> with me it works just fine. However I encountered one problem. I
> understand it as follows, if there is no physical PCIe link then
> somewhere a flag PPC_INDIRECT_TYPE_NO_PCIE_LINK gets set. This has as
> result that reading the PCIe config space will fail with a
> PCIBIOS_DEVICE_NOT_FOUND (ref
> http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/sysdev/indirect_pci.c#L24 )
>
>
> At
> http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/include/asm/pci-bridge.h#L105
> they specify this as a workaround since the PCIe might hang if there is
> no physical link. So my workaround for this issue was:
>
> - load the fpga
> - travel down the pci bus to the correct bus where the fpga is attached
> use a pci_bus_to_host() to obtain a struct pci_controller, unset the
> PPC_INDIRECT_TYPE_NO_PCIE_LINK and call a pci_rescon_bus() on that bus.
>
> After doing this I can find access the FPGA, and reload it if needed.
> Not a clue if this is 'the proper way' to do it, but it works for me.
Looks this may be really related to the PCIe Link Training. So you have to reset
the PCIe after load the FPGA, but I think we should do this in the u-boot. For
more detail on this please refer to the code segments defined by
CONFIG_FSL_PCIE_RESET in the file, drivers/pci/fsl_pci_init.c.
Tiejun
>
> gr
> E.
>
^ permalink raw reply
* Re: PCIe end-point on FPGA doesn't show up on PCI bus when configured
From: Stijn Devriendt @ 2011-01-30 7:36 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev, Matias Garcia, Elie De Brauwer
In-Reply-To: <4D44D5DE.1060104@windriver.com>
As far as I know, you're violating PCIe spec.
PCIe base spec (rev1.0a) states that a device must start link training
within 80ms
after a fundamental reset and that each device must be ready to accept conf=
ig
requests within 100ms after fundamental reset.
Regards,
Stijn
On Sun, Jan 30, 2011 at 4:07 AM, tiejun.chen <tiejun.chen@windriver.com> wr=
ote:
> Elie De Brauwer wrote:
>> On 01/28/11 19:37, Matias Garcia wrote:
>>> I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-cor=
e
>>> processor, and have the following conundrum: I configure the FPGA which
>>> brings up a PCIe interface to the processor. I scan both PCI buses on
>>> the system (I believe the second bus is behind the Freescale integrated
>>> bridge on the first), and it doesn't show up. I initiate a reset on the
>>> processor, and both U-boot and Linux now see the FPGA PCI device at
>>> 0000:01:00.00. I've noticed some of the memory mappings in the PCI
>>> bridge windows are different between the two boot sequences. I've tried
>>> all manner of pci calls (including the pcibios_fixup routines) on the
>>> bridge device (including removing and re-scanning it), and on bus 1,
>>> which is otherwise empty, to no avail. Following are some debug listing=
s
>>> from dmesg; any help/ideas in tracking down the problem (hardware or
>>> software) is greatly appreciated.
>>>
>>> #Boot without FPGA configured:
>>> <snip>
>>> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
>>> 0->255
>>> PCI host bridge /pcie@8ff70a000 ranges:
>>> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
>>> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
>>> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
>>> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map=
.
>>> Adjusting the memory map could reduce unnecessary bounce buffering.
>>> /pcie@8ff70a000: DMA window size is 0x80000000
>>> MPC85xx RDB board from Freescale Semiconductor
>>> <...>
>>> PCI: Probing PCI hardware
>>> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
>>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>>> pci 0000:00:00.0: supports D1 D2
>>> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
>>> pci 0000:00:00.0: PME# disabled
>>> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>>> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
>>> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
>>> pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref]
>>> (disabled)
>>> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
>>> pci 0000:00:00.0: PCI bridge to [bus 01-01]
>>> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
>>> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
>>> pci 0000:00:00.0: bridge window [mem pref disabled]
>>> pci 0000:00:00.0: enabling device (0106 -> 0107)
>>> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
>>> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
>>> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
>>> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
>>>
>>> #Reset with FPGA configured:
>>> <snip>
>>> Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number:
>>> 0->255
>>> PCI host bridge /pcie@8ff70a000 ranges:
>>> MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
>>> IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
>>> /pcie@8ff70a000: PCICSRBAR @ 0xfff00000
>>> /pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map=
.
>>> Adjusting the memory map could reduce unnecessary bounce buffering.
>>> /pcie@8ff70a000: DMA window size is 0x80000000
>>> MPC85xx RDB board from Freescale Semiconductor
>>> <...>
>>> PCI: Probing PCI hardware
>>> pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
>>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>>> pci 0000:00:00.0: supports D1 D2
>>> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
>>> pci 0000:00:00.0: PME# disabled
>>> pci 0000:01:00.0: [1172:0004] type 0 class 0x001000
>>> pci 0000:01:00.0: reg 10: [mem 0x80000000-0x80ffffff]
>>> pci 0000:01:00.0: reg 14: [mem 0x81000000-0x81ffffff]
>>> pci 0000:01:00.0: reg 18: [mem 0x82000000-0x82ffffff]
>>> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>>> pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
>>> pci 0000:00:00.0: bridge window [mem 0x80000000-0x82ffffff]
>>> pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref]
>>> (disabled)
>>> irq: irq 0 on host /soc@8ff700000/pic@40000 mapped to virtual irq 16
>>> PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
>>> pci 0000:00:00.0: PCI bridge to [bus 01-01]
>>> pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
>>> pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
>>> pci 0000:00:00.0: bridge window [mem pref disabled]
>>> pci 0000:00:00.0: enabling device (0106 -> 0107)
>>> pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
>>> pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
>>> pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
>>> pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
>>
>>
>> Hi Mattias,
>>
>> I'm doing the same on a similar setup, also a P2020 but a 2.6.36 and
>> with me it works just fine. However I encountered one problem. I
>> understand it as follows, if there is no physical PCIe link then
>> somewhere a flag PPC_INDIRECT_TYPE_NO_PCIE_LINK gets set. This has as
>> result that reading the PCIe config space will fail with a
>> PCIBIOS_DEVICE_NOT_FOUND (ref
>> http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/sysdev/indirect_pci.c#L2=
4 )
>>
>>
>> At
>> http://lxr.linux.no/#linux+v2.6.37/arch/powerpc/include/asm/pci-bridge.h=
#L105
>> they specify this as a workaround since the PCIe might hang if there is
>> no physical link. So my workaround for this issue was:
>>
>> - load the fpga
>> - travel down the pci bus to the correct bus where the fpga is attached
>> =A0use a pci_bus_to_host() to obtain a struct pci_controller, unset the
>> PPC_INDIRECT_TYPE_NO_PCIE_LINK =A0and call a pci_rescon_bus() on that bu=
s.
>>
>> After doing this I can find access the FPGA, and reload it if needed.
>> Not a clue if this is 'the proper way' to do it, but it works for me.
>
> Looks this may be really related to the PCIe Link Training. So you have t=
o reset
> the PCIe after load the FPGA, but I think we should do this in the u-boot=
. For
> more detail on this please refer to the code segments defined by
> CONFIG_FSL_PCIE_RESET in the file, drivers/pci/fsl_pci_init.c.
>
> Tiejun
>
>>
>> gr
>> E.
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox