* Re: Gianfar tx-babbling-errors
From: Kumar Gala @ 2009-02-19 17:03 UTC (permalink / raw)
To: sjoyeau; +Cc: linuxppc-dev, Scott Coulter
In-Reply-To: <d194b8ce0902190848hb53166cj32e7d0bd65021d2e@mail.gmail.com>
On Feb 19, 2009, at 10:48 AM, sjoyeau@wanadoo.fr wrote:
> Hi Scott,
>
> Your issue may come from data setup (or corruption) instead of code
> path: babbling error may occurs when a TSEC TX descriptor hasn't its
> "last frame" bit set or when the data length is greated than max
> frame length.
>
> --
Take a look at TxBD[TR] and see if its getting set ever.
- k
^ permalink raw reply
* [patch] powerpc: estimate G5 cpufreq transition latency
From: Nick Piggin @ 2009-02-19 17:07 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev
Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
ondemand governor from working. I measured the latency using sched_clock
and haven't seen much higher than 11000ns, so I set this to 12000ns for
my configuration. Possibly other configurations will be different?
Ideally the generic code would be able to measure it in case the platform
does not provide it.
But this simple patch at least makes it throttle again.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:42:41.000000000 +1100
+++ linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c 2009-02-20 01:50:15.000000000 +1100
@@ -86,6 +86,7 @@
static DEFINE_MUTEX(g5_switch_mutex);
+static unsigned long transition_latency;
#ifdef CONFIG_PMAC_SMU
@@ -357,7 +358,7 @@
static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+ policy->cpuinfo.transition_latency = transition_latency;
policy->cur = g5_cpu_freqs[g5_query_freq()].frequency;
/* secondary CPUs are tied to the primary one by the
* cpufreq core if in the secondary policy we tell it that
@@ -500,6 +501,7 @@
g5_cpu_freqs[1].frequency = max_freq/2;
/* Set callbacks */
+ transition_latency = 12000;
g5_switch_freq = g5_scom_switch_freq;
g5_query_freq = g5_scom_query_freq;
freq_method = "SCOM";
@@ -675,6 +677,7 @@
g5_cpu_freqs[1].frequency = min_freq;
/* Set callbacks */
+ transition_latency = CPUFREQ_ETERNAL;
g5_switch_volt = g5_pfunc_switch_volt;
g5_switch_freq = g5_pfunc_switch_freq;
g5_query_freq = g5_pfunc_query_freq;
Index: linux-2.6/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.orig/drivers/cpufreq/cpufreq.c 2009-02-20 01:42:43.000000000 +1100
+++ linux-2.6/drivers/cpufreq/cpufreq.c 2009-02-20 01:50:15.000000000 +1100
@@ -1559,9 +1559,11 @@
else {
printk(KERN_WARNING "%s governor failed, too long"
" transition latency of HW, fallback"
- " to %s governor\n",
+ " to %s governor (latency=%lld max=%lld)\n",
policy->governor->name,
- gov->name);
+ gov->name,
+ policy->cpuinfo.transition_latency,
+ policy->governor->max_transition_latency);
policy->governor = gov;
}
}
^ permalink raw reply
* [patch 1/2] powerpc: optimise smp_mb
From: Nick Piggin @ 2009-02-19 17:12 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev
Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than
using sync for smp_mb. Although it takes more instructions.
Running tbench with 4 clients on my 4 core G5 (20 times) gives the
following:
unpatched AVG=920.33 STD=2.36
patched AVG=921.27 STD=2.77
So not a big improvement here, actually it could even be in the noise.
But other workloads or systems might see a bigger win, and the patch
maybe is interesting or could be improved, so I'll ask for comments.
---
Index: linux-2.6/arch/powerpc/include/asm/system.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/system.h 2009-02-20 01:51:24.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 02:09:41.000000000 +1100
@@ -52,7 +52,16 @@
# define SMPWMB eieio
#endif
+#ifdef __powerpc64__
+#define smp_mb() __asm__ __volatile__ ( \
+ "1: lwsync \n" \
+ " cmpw 0,%%r0,%%r0 \n" \
+ " bne- 1b \n" \
+ " isync \n" \
+ : : : "memory")
+#else
#define smp_mb() mb()
+#endif
#define smp_rmb() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory")
#define smp_wmb() __asm__ __volatile__ (stringify_in_c(SMPWMB) : : :"memory")
#define smp_read_barrier_depends() read_barrier_depends()
^ permalink raw reply
* [patch 2/2] powerpc: replace isync with lwsync
From: Nick Piggin @ 2009-02-19 17:21 UTC (permalink / raw)
To: benh, paulus, linuxppc-dev
In-Reply-To: <20090219171229.GJ1747@wotan.suse.de>
OK, here is this patch again. You didn't think I'd let a 2% performance
improvement be forgotten? :)
Anyway, patch won't work well on architecture without lwsync, but I won't
bother fixing that kind of thing and making it merge worthy until you
guys say something positive about it.
20 runs of tbench on the G5
unpatched AVG=920.37 STD=2.36
patched AVG=938.89 STD=3.33
(throughput in MB/s) This is a 1.9% throughput increase.
---
Index: linux-2.6/arch/powerpc/include/asm/atomic.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/atomic.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/atomic.h 2009-02-20 02:13:22.000000000 +1100
@@ -55,7 +55,7 @@
PPC405_ERR77(0,%2)
" stwcx. %0,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
@@ -91,7 +91,7 @@
PPC405_ERR77(0,%2)
" stwcx. %0,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
@@ -125,7 +125,7 @@
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (&v->counter)
: "cc", "xer", "memory");
@@ -169,7 +169,7 @@
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (&v->counter)
: "cc", "xer", "memory");
@@ -202,7 +202,7 @@
PPC405_ERR77(0,%2)
" stwcx. %0,0,%1 \n\
bne- 1b \n"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
" subf %0,%2,%0 \n\
2:"
: "=&r" (t)
@@ -235,7 +235,7 @@
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"\n\
2:" : "=&b" (t)
: "r" (&v->counter)
@@ -291,7 +291,7 @@
add %0,%1,%0\n\
stdcx. %0,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
@@ -325,7 +325,7 @@
subf %0,%1,%0\n\
stdcx. %0,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (a), "r" (&v->counter)
: "cc", "memory");
@@ -357,7 +357,7 @@
addic %0,%0,1\n\
stdcx. %0,0,%1 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (&v->counter)
: "cc", "xer", "memory");
@@ -399,7 +399,7 @@
addic %0,%0,-1\n\
stdcx. %0,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (&v->counter)
: "cc", "xer", "memory");
@@ -425,7 +425,7 @@
blt- 2f\n\
stdcx. %0,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"\n\
2:" : "=&r" (t)
: "r" (&v->counter)
@@ -458,7 +458,7 @@
add %0,%2,%0 \n"
" stdcx. %0,0,%1 \n\
bne- 1b \n"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
" subf %0,%2,%0 \n\
2:"
: "=&r" (t)
Index: linux-2.6/arch/powerpc/include/asm/bitops.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/bitops.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/bitops.h 2009-02-20 02:13:22.000000000 +1100
@@ -139,7 +139,7 @@
PPC405_ERR77(0,%3)
PPC_STLCX "%1,0,%3 \n"
"bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (old), "=&r" (t)
: "r" (mask), "r" (p)
: "cc", "memory");
@@ -160,7 +160,7 @@
PPC405_ERR77(0,%3)
PPC_STLCX "%1,0,%3 \n"
"bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (old), "=&r" (t)
: "r" (mask), "r" (p)
: "cc", "memory");
@@ -182,7 +182,7 @@
PPC405_ERR77(0,%3)
PPC_STLCX "%1,0,%3 \n"
"bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (old), "=&r" (t)
: "r" (mask), "r" (p)
: "cc", "memory");
@@ -204,7 +204,7 @@
PPC405_ERR77(0,%3)
PPC_STLCX "%1,0,%3 \n"
"bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (old), "=&r" (t)
: "r" (mask), "r" (p)
: "cc", "memory");
Index: linux-2.6/arch/powerpc/include/asm/futex.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/futex.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/futex.h 2009-02-20 02:13:22.000000000 +1100
@@ -97,7 +97,7 @@
PPC405_ERR77(0,%2)
"2: stwcx. %4,0,%2\n\
bne- 1b\n"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"3: .section .fixup,\"ax\"\n\
4: li %0,%5\n\
b 3b\n\
Index: linux-2.6/arch/powerpc/include/asm/spinlock.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/spinlock.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/spinlock.h 2009-02-20 02:13:22.000000000 +1100
@@ -65,7 +65,7 @@
bne- 2f\n\
stwcx. %1,0,%2\n\
bne- 1b\n\
- isync\n\
+ lwsync\n\
2:" : "=&r" (tmp)
: "r" (token), "r" (&lock->slock)
: "cr0", "memory");
@@ -193,7 +193,7 @@
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b\n\
- isync\n\
+ lwsync\n\
2:" : "=&r" (tmp)
: "r" (&rw->lock)
: "cr0", "xer", "memory");
@@ -217,7 +217,7 @@
PPC405_ERR77(0,%1)
" stwcx. %1,0,%2\n\
bne- 1b\n\
- isync\n\
+ lwsync\n\
2:" : "=&r" (tmp)
: "r" (token), "r" (&rw->lock)
: "cr0", "memory");
Index: linux-2.6/arch/powerpc/include/asm/system.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/system.h 2009-02-20 02:09:41.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 02:13:22.000000000 +1100
@@ -246,7 +246,7 @@
PPC405_ERR77(0,%2)
" stwcx. %3,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (prev), "+m" (*(volatile unsigned int *)p)
: "r" (p), "r" (val)
: "cc", "memory");
@@ -289,7 +289,7 @@
PPC405_ERR77(0,%2)
" stdcx. %3,0,%2 \n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (prev), "+m" (*(volatile unsigned long *)p)
: "r" (p), "r" (val)
: "cc", "memory");
@@ -382,7 +382,7 @@
PPC405_ERR77(0,%2)
" stwcx. %4,0,%2\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"\n\
2:"
: "=&r" (prev), "+m" (*p)
@@ -427,7 +427,7 @@
bne- 2f\n\
stdcx. %4,0,%2\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"\n\
2:"
: "=&r" (prev), "+m" (*p)
Index: linux-2.6/arch/powerpc/include/asm/synch.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/synch.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/synch.h 2009-02-20 02:13:22.000000000 +1100
@@ -38,7 +38,7 @@
#ifdef CONFIG_SMP
#define ISYNC_ON_SMP "\n\tisync\n"
-#define LWSYNC_ON_SMP stringify_in_c(LWSYNC) "\n"
+#define LWSYNC_ON_SMP "\n\t" stringify_in_c(LWSYNC) "\n"
#else
#define ISYNC_ON_SMP
#define LWSYNC_ON_SMP
Index: linux-2.6/arch/powerpc/include/asm/mutex.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/mutex.h 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/include/asm/mutex.h 2009-02-20 02:13:22.000000000 +1100
@@ -15,7 +15,7 @@
PPC405_ERR77(0,%1)
" stwcx. %3,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
"\n\
2:"
: "=&r" (t)
@@ -35,7 +35,7 @@
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b"
- ISYNC_ON_SMP
+ LWSYNC_ON_SMP
: "=&r" (t)
: "r" (&v->counter)
: "cc", "memory");
Index: linux-2.6/arch/powerpc/mm/hash_low_64.S
===================================================================
--- linux-2.6.orig/arch/powerpc/mm/hash_low_64.S 2009-02-20 01:50:20.000000000 +1100
+++ linux-2.6/arch/powerpc/mm/hash_low_64.S 2009-02-20 02:13:22.000000000 +1100
@@ -110,7 +110,7 @@
/* Write the linux PTE atomically (setting busy) */
stdcx. r30,0,r6
bne- 1b
- isync
+ lwsync
/* Step 2:
*
@@ -393,7 +393,7 @@
/* Write the linux PTE atomically (setting busy) */
stdcx. r30,0,r6
bne- 1b
- isync
+ lwsync
/* Step 2:
*
@@ -734,7 +734,7 @@
/* Write the linux PTE atomically (setting busy) */
stdcx. r30,0,r6
bne- 1b
- isync
+ lwsync
/* Step 2:
*
^ permalink raw reply
* Re: Regarding irq_of_parse_and_map
From: Jon Loeliger @ 2009-02-19 17:24 UTC (permalink / raw)
To: Vijay Nikam; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <f234e2140902190351i41f99cbu22c3654eadf03f49@mail.gmail.com>
On Thu, 2009-02-19 at 17:21 +0530, Vijay Nikam wrote:
> Also is it possible to compile device tree on Linux host and genreate
> dtb for powerpc ? ? ? If yes, then how ? ? ? please let me know ...
> thanks ...
Uh, get a copy of the DTC using:
$ git clone git://git.jdl.com/software/dtc.git
$ cd dtc
$ make
HTH,
jdl
^ permalink raw reply
* Re: [PATCH] powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
From: Anton Vorontsov @ 2009-02-19 17:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: Liu Dave, Andy Fleming, linuxppc-dev
In-Reply-To: <8EC0BAAB-7261-406F-BA42-BE6D9EC55AAB@kernel.crashing.org>
On Thu, Feb 19, 2009 at 10:19:05AM -0600, Kumar Gala wrote:
>
> On Feb 19, 2009, at 10:02 AM, Anton Vorontsov wrote:
>
>> On MPC837X CPUs Dual-Role USB isn't always available (for example DR
>> USB pins can be muxed away to eSDHC).
>>
>> U-Boot adds status = "disabled" property into the DR USB nodes to
>> indicate that we must not try to configure or probe Dual-Role USB,
>> otherwise we'll break eSDHC support on targets with MPC837X CPUs.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> arch/powerpc/platforms/83xx/usb.c | 3 ++-
>> arch/powerpc/sysdev/fsl_soc.c | 4 ++++
>> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> Mind looking at possibly killing the fsl_soc.c usb code and making the
> usb a real of-platform driver?
Sure, but it's a bit complicated because of OTG support (which
doesn't currently work, btw).
Just need to think about whether we want to leave UDC and HOST
drivers as pure platform drivers, and implement an of platform
driver as a proxy for Host/UDC/OTG...
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: Gianfar tx-babbling-errors
From: Scott Coulter @ 2009-02-19 17:29 UTC (permalink / raw)
To: Kumar Gala, sjoyeau; +Cc: linuxppc-dev
In-Reply-To: <12B2E46F-9CA4-4950-B58A-D02E5F3AA079@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: February 19, 2009 12:04PM
> >
> > Your issue may come from data setup (or corruption) instead of code
> > path: babbling error may occurs when a TSEC TX descriptor hasn't its
> > "last frame" bit set or when the data length is greated than max
> > frame length.
> >
> > --
>=20
> Take a look at TxBD[TR] and see if its getting set ever.
>=20
I added two bug checks:
- one in gfar_clean_tx_ring() after the check for completed frames:
/* see if any transmits were truncated */
BUG_ON(lstatus & BD_LFLAG(TXBD_TR));
- one in gfar_start_xmit() at the end to check a flag to see if
TXBD_LAST never gets set.
Within a couple of minutes it bug checked in gfar_clean_tx_ring():
kernel BUG at drivers/net/gianfar.c:1826!
Oops: Exception in kernel mode, sig: 5 [#1]
CYC833-8568
Modules linked in:
NIP: c019a7b8 LR: c019a824 CTR: 00000000
REGS: c0307d50 TRAP: 0700 Not tainted (2.6.27.6)
MSR: 00021000 <ME> CR: 44044044 XER: 20000000
TASK =3D c02eb4a8[0] 'swapper' THREAD: c0306000
GPR00: 00010000 c0307e00 c02eb4a8 00000002 00000010 00000001 c030dc48
c0e003c0
GPR08: c0314e80 180107a8 00000000 efab6dd0 24044022 002ae6bc 0000007f
00000010
GPR16: ef84a800 00029000 ef84abec ef84abc0 00000000 00000001 00000073
000001cc
GPR24: 00100100 00000001 ef84abc0 00000400 efab7400 00000000 ef0f9f00
efab71c8
NIP [c019a7b8] gfar_poll+0xb0/0x408
LR [c019a824] gfar_poll+0x11c/0x408
Call Trace:
[c0307e00] [c019a824] gfar_poll+0x11c/0x408 (unreliable)
[c0307e50] [c01cb144] net_rx_action+0xc4/0x180
[c0307e80] [c0036404] __do_softirq+0x74/0xe0
[c0307ea0] [c0004a20] do_softirq+0x54/0x58
[c0307eb0] [c00362b0] irq_exit+0x94/0x98
[c0307ec0] [c0004acc] do_IRQ+0xa8/0xc8
[c0307ed0] [c000e40c] ret_from_except+0x0/0x18
[c0307f90] [c0007c88] cpu_idle+0x50/0xd8
[c0307fb0] [c024b220] __got2_end+0x58/0x68
[c0307fc0] [c02c5808] start_kernel+0x230/0x2ac
[c0307ff0] [c00003c4] skpinv+0x2ec/0x328
Instruction dump:
3a800000 817e0094 a32b0004 57291838 7d3f4a14 7f89e040 7d7b4850 7d295f1e
81290000 2f890000 419c0160 552003de <0f000000> 813f0000 2f190000
55290084
Kernel panic - not syncing: Fatal exception in interrupt
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* Re: Newby trying to get Ethernet going on MPC83xx series device.
From: Scott Wood @ 2009-02-19 18:38 UTC (permalink / raw)
To: Dushara Jayasinghe; +Cc: 'linuxppc-dev@ozlabs.org'
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B40549@mailsvr>
On Thu, Feb 19, 2009 at 03:26:41PM +1100, Dushara Jayasinghe wrote:
> I get the following error during the boot sequence:
>
> IP-Config: Device `eth0' not found
>
> I also found that both gfar_init (in gianfar.c) and gfar_mdio_init (in
> gianfar_mii.c) are called but the probe handlers of either of these
> devices are not executed.
Check your board code to see if the soc node is being probed by
of_platform_bus_probe. Ideally, the soc node would have "simple-bus"
included in the compatible property, as would the of_device_id array.
-Scott
^ permalink raw reply
* Re: How to bring up fs_enet on 2.6.27?
From: Scott Wood @ 2009-02-19 18:44 UTC (permalink / raw)
To: Daniel Ng; +Cc: linuxppc-dev, Mike Ditto
In-Reply-To: <547eba1b0902182247g66c8b83se0855ff048413c01@mail.gmail.com>
On Thu, Feb 19, 2009 at 05:47:22PM +1100, Daniel Ng wrote:
> Or, perhaps it is ok for the 'of_platform' bus to have no devices on
> it, and so I might be using the wrong bus?? Why would this be?
>
> Or is it something else??
>
> Either way, I still get the following boot error message:
>
> IP-Config: Device `eth0' not found.
>
> -and fs_enet_probe() is NEVER called.
>
See this thread:
http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html
-Scott
^ permalink raw reply
* [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
From: Kumar Gala @ 2009-02-19 20:49 UTC (permalink / raw)
Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-1-git-send-email-galak@kernel.crashing.org>
Since a number of powerpc chips are SoCs we end up having dma-able
devices that are registered as platform or of_platform devices. We need
to hook the archdata to setup proper dma_ops for these devices.
In the short term the majority of these devices only need the
direct_dma_ops as the platforms don't have any IOMMUs.
In the future to enable >4G DMA support on ppc32 we can hook swiotlb ops.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/machdep.h | 4 ++++
arch/powerpc/kernel/setup-common.c | 22 ++++++++++++++++++++++
arch/powerpc/kernel/setup.h | 4 ++++
arch/powerpc/kernel/setup_32.c | 3 +++
arch/powerpc/kernel/setup_64.c | 3 +++
arch/powerpc/platforms/cell/qpace_setup.c | 13 -------------
6 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 6c34a0d..9a28e5b 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -262,6 +262,10 @@ struct machdep_calls {
void (*suspend_disable_irqs)(void);
void (*suspend_enable_irqs)(void);
#endif
+ /* These are called via the driver core. They mainly exist
+ * for setting up archdata properly */
+ int (*platform_notify)(struct device *dev);
+ int (*platform_notify_remove)(struct device *dev);
};
extern void e500_idle(void);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 705fc4b..62dfa75 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -669,3 +669,25 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+int ppc_platform_notify(struct device *dev)
+{
+ if (ppc_md.platform_notify)
+ return ppc_md.platform_notify(dev);
+
+ /* set dma_ops for platform or of_platform bus */
+ if (dev->bus && dev->bus->name &&
+ (!strcmp(dev->bus->name, "platform") ||
+ !strcmp(dev->bus->name, "of_platform")))
+ set_dma_ops(dev, &dma_direct_ops);
+
+ return 0;
+}
+
+int ppc_platform_notify_remove(struct device *dev)
+{
+ if (ppc_md.platform_notify_remove)
+ return ppc_md.platform_notify_remove(dev);
+
+ return 0;
+}
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 4c67ad7..34899cf 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -1,9 +1,13 @@
#ifndef _POWERPC_KERNEL_SETUP_H
#define _POWERPC_KERNEL_SETUP_H
+#include <linux/device.h>
+
void check_for_initrd(void);
void do_init_bootmem(void);
void setup_panic(void);
+int ppc_platform_notify(struct device *dev);
+int ppc_platform_notify_remove(struct device *dev);
extern int do_early_xmon;
#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e1ca74..c20a49d 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -328,6 +328,9 @@ void __init setup_arch(char **cmdline_p)
conswitchp = &dummy_con;
#endif
+ platform_notify = &ppc_platform_notify;
+ platform_notify_remove = &ppc_platform_notify_remove;
+
if (ppc_md.setup_arch)
ppc_md.setup_arch();
if ( ppc_md.progress ) ppc_md.progress("arch: exit", 0x3eab);
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 73e16e2..b22a3d9 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -546,6 +546,9 @@ void __init setup_arch(char **cmdline_p)
conswitchp = &dummy_con;
#endif
+ platform_notify = &ppc_platform_notify;
+ platform_notify_remove = &ppc_platform_notify_remove;
+
if (ppc_md.setup_arch)
ppc_md.setup_arch();
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c b/arch/powerpc/platforms/cell/qpace_setup.c
index be84e6a..775cd80 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -81,16 +81,6 @@ static int __init qpace_publish_devices(void)
}
machine_subsys_initcall(qpace, qpace_publish_devices);
-extern int qpace_notify(struct device *dev)
-{
- /* set dma_ops for of_platform bus */
- if (dev->bus && dev->bus->name
- && !strcmp(dev->bus->name, "of_platform"))
- set_dma_ops(dev, &dma_direct_ops);
-
- return 0;
-}
-
static void __init qpace_setup_arch(void)
{
#ifdef CONFIG_SPU_BASE
@@ -115,9 +105,6 @@ static void __init qpace_setup_arch(void)
#ifdef CONFIG_DUMMY_CONSOLE
conswitchp = &dummy_con;
#endif
-
- /* set notifier function */
- platform_notify = &qpace_notify;
}
static int __init qpace_probe(void)
--
1.5.6.6
^ permalink raw reply related
* [PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
From: Kumar Gala @ 2009-02-19 20:49 UTC (permalink / raw)
Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-2-git-send-email-galak@kernel.crashing.org>
Now that we set archdata for of_platform and platform devices via
platform_notify() we no longer need to special case having a NULL device
pointer or NULL archdata. It should be a driver error if this condition
shows up and the driver should be fixed.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/dma-mapping.h | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 86cef7d..c69f2b5 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -109,18 +109,8 @@ static inline struct dma_mapping_ops *get_dma_ops(struct device *dev)
* only ISA DMA device we support is the floppy and we have a hack
* in the floppy driver directly to get a device for us.
*/
-
- if (unlikely(dev == NULL) || dev->archdata.dma_ops == NULL) {
-#ifdef CONFIG_PPC64
+ if (unlikely(dev == NULL))
return NULL;
-#else
- /* Use default on 32-bit if dma_ops is not set up */
- /* TODO: Long term, we should fix drivers so that dev and
- * archdata dma_ops are set up for all buses.
- */
- return &dma_direct_ops;
-#endif
- }
return dev->archdata.dma_ops;
}
--
1.5.6.6
^ permalink raw reply related
* [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
From: Kumar Gala @ 2009-02-19 20:49 UTC (permalink / raw)
Cc: linuxppc-dev, arnd
This will allow us to remove the ppc32 specific checks in get_dma_ops()
that defaults to dma_direct_ops if the archdata is NULL. We really
should always have archdata set to something going forward.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/pci-common.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 2ad1731..633e871 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -50,7 +50,7 @@ resource_size_t isa_mem_base;
unsigned int ppc_pci_flags = 0;
-static struct dma_mapping_ops *pci_dma_ops;
+static struct dma_mapping_ops *pci_dma_ops = &dma_direct_ops;
void set_pci_dma_ops(struct dma_mapping_ops *dma_ops)
{
--
1.5.6.6
^ permalink raw reply related
* Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
From: Kumar Gala @ 2009-02-19 20:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Arnd Bergmann
In-Reply-To: <1235076557-24464-1-git-send-email-galak@kernel.crashing.org>
On Feb 19, 2009, at 2:49 PM, Kumar Gala wrote:
> This will allow us to remove the ppc32 specific checks in
> get_dma_ops()
> that defaults to dma_direct_ops if the archdata is NULL. We really
> should always have archdata set to something going forward.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/kernel/pci-common.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Ben,
If you can look at putting these in testing that would be great.
I'd like to see of Josh can get some 4xx/44x runs to see if we break
anything there. I don't expect it but good to see.
- k
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pci: Default to dma_direct_ops for pci dma_ops
From: Benjamin Krill @ 2009-02-19 22:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-1-git-send-email-galak@kernel.crashing.org>
* Kumar Gala | 2009-02-19 14:49:15 [-0600]:
>This will allow us to remove the ppc32 specific checks in get_dma_ops()
>that defaults to dma_direct_ops if the archdata is NULL. We really
>should always have archdata set to something going forward.
>
>Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Benjamin Krill <ben@codiert.org>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: setup archdata for {of_}platform via a single platform_notify
From: Benjamin Krill @ 2009-02-19 22:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-2-git-send-email-galak@kernel.crashing.org>
* Kumar Gala | 2009-02-19 14:49:16 [-0600]:
>Since a number of powerpc chips are SoCs we end up having dma-able
>devices that are registered as platform or of_platform devices. We need
>to hook the archdata to setup proper dma_ops for these devices.
>
>In the short term the majority of these devices only need the
>direct_dma_ops as the platforms don't have any IOMMUs.
>
>In the future to enable >4G DMA support on ppc32 we can hook swiotlb ops.
>
>Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Benjamin Krill <ben@codiert.org>
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: expect all devices calling dma ops to have archdata set
From: Benjamin Krill @ 2009-02-19 22:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, arnd
In-Reply-To: <1235076557-24464-3-git-send-email-galak@kernel.crashing.org>
* Kumar Gala | 2009-02-19 14:49:17 [-0600]:
>Now that we set archdata for of_platform and platform devices via
>platform_notify() we no longer need to special case having a NULL device
>pointer or NULL archdata. It should be a driver error if this condition
>shows up and the driver should be fixed.
>
>Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Benjamin Krill <ben@codiert.org>
^ permalink raw reply
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-20 0:36 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Cc: 'Aggrwal Poonam-B10812', 'Timur Tabi'
In-Reply-To: <FD3D453EC8A8D5479E7E063D31E2FA4426866A@zin33exm24.fsl.freescale.net>
Yes I now base it on mpc834x_mds.c and it works (almost) :-(
The devices are successfully probed, but I'm getting this error on the debu=
g console:
[ 7.119389] mdio@24520:00 not found
[ 7.161370] eth0: Could not attach to PHY
[ 7.209600] IP-Config: Failed to open eth0
[ 7.258879] IP-Config: Device `eth0' not found.
My mdio & Ethernet nodes are as follows (commenting out device_type below i=
s an experiment)
mdio@24520 {
/*device_type =3D "mdio";*/
compatible =3D "fsl,gianfar-mdio";
#address-cells =3D <1>;
#size-cells =3D <0>;
reg =3D <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent =3D <&ipic>;
interrupts =3D <3 8>;
reg =3D <0>;
device_type =3D "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent =3D <&ipic>;
interrupts =3D <3 8>;
reg =3D <1>;
device_type =3D "ethernet-phy";
};
};
enet0: ethernet@24000 {
cell-index =3D <0>;
device_type =3D "network";
model =3D "TSEC";
compatible =3D "gianfar";
reg =3D <24000 1000>;
local-mac-address =3D [ 00 00 00 00 00 00 ];
interrupts =3D <20 8 21 8 22 8>;
interrupt-parent =3D <&ipic>;
phy-handle =3D <&phy0>;
linux,network-index =3D <0>;
};
enet1: ethernet@25000 {
cell-index =3D <1>;
device_type =3D "network";
model =3D "TSEC";
compatible =3D "gianfar";
reg =3D <25000 1000>;
local-mac-address =3D [ 00 00 00 00 00 00 ];
interrupts =3D <23 8 24 8 25 8>;
interrupt-parent =3D <&ipic>;
phy-handle =3D <&phy1>;
linux,network-index =3D <1>;
phy-connection-type =3D "gmii";
};
Any clues as to where I should start looking?
BTW, I assume CCing all those who replied to me is accepted/expected conduc=
t or should I avoid this and just write to the list?
Also is top posting ok? I haven't figured out how to enable '>' on bloody M=
icrosoft Outlook, for incoming plain text messages.
Thanks again for all your help.
D
-----Original Message-----
From: Aggrwal Poonam-B10812 [mailto:Poonam.Aggrwal@freescale.com]=20
Sent: Thursday, 19 February 2009 6:25 PM
To: Li Yang-R58472; Dushara Jayasinghe
Cc: linuxppc-dev@ozlabs.org
Subject: RE: Newby trying to get Ethernet going on MPC83xx series device.
Probably better would be to check the board file for mpc834x_mds.c
I mean just cross that you probe all the buses which are on the device.
What is fsl,pq2pro-localbus? Do u have such node in dts as the
mpc8349_itx has.
> -----Original Message-----
> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com] On Behalf=20
> Of Li Yang-R58472
> Sent: Thursday, February 19, 2009 12:50 PM
> To: Dushara Jayasinghe
> Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812
> Subject: Re: Newby trying to get Ethernet going on MPC83xx=20
> series device.
>=20
> On Thu, Feb 19, 2009 at 2:58 PM, Dushara Jayasinghe=20
> <DusharaJ@optiscan.com> wrote:
> > That did it.
> >
> >
> >
> > I based my board specific file on mpc834x_itx.c which had
> >
> >
> >
> > static struct of_device_id __initdata mpc834x_itx_ids[] =3D {
> >
> > { .compatible =3D "fsl,pq2pro-localbus", },
> >
> > { .compatible =3D "simple-bus", },
> >
> > {},
> >
> > };
> >
> >
> >
> > Don't know if this is broken?
>=20
> It's not broken as long as you have compatible =3D "simple-bus"=20
> for your soc node.
>=20
> - Leo
>=20
>=20
^ permalink raw reply
* RE: [RFC v1] virtio: add virtio-over-PCI driver
From: Zang Roy-R61911 @ 2009-02-20 3:37 UTC (permalink / raw)
To: Ira Snyder
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <20090219161438.GA12795@ovro.caltech.edu>
=20
> -----Original Message-----
> From: Ira Snyder [mailto:iws@ovro.caltech.edu]=20
> Sent: Friday, February 20, 2009 0:15 AM
> To: Zang Roy-R61911
> Cc: linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
> netdev@vger.kernel.org; Rusty Russell; Arnd Bergmann;=20
> Jan-Bernd Themann
> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
>=20
> On Thu, Feb 19, 2009 at 02:10:08PM +0800, Zang Roy-R61911 wrote:
> > =20
> >=20
> > > -----Original Message-----
> > > From:=20
> > > linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs.org=20
> > > [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs
> > > .org] On Behalf Of Ira Snyder
> > > Sent: Wednesday, February 18, 2009 6:24 AM
> > > To: linux-kernel@vger.kernel.org
> > > Cc: linuxppc-dev@ozlabs.org; netdev@vger.kernel.org; Rusty=20
> > > Russell; Arnd Bergmann; Jan-Bernd Themann
> > > Subject: [RFC v1] virtio: add virtio-over-PCI driver
> > snip
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 3dd6294..efcf56b 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -33,3 +33,25 @@ config VIRTIO_BALLOON
> > > =20
> > > If unsure, say M.
> > > =20
> > > +config VIRTIO_OVER_PCI_HOST
> > > + tristate "Virtio-over-PCI Host support (EXPERIMENTAL)"
> > > + depends on PCI && EXPERIMENTAL
> > > + select VIRTIO
> > > + ---help---
> > > + This driver provides the host support necessary for=20
> > > using virtio
> > > + over the PCI bus with a Freescale MPC8349EMDS=20
> > > evaluation board.
> > > +
> > > + If unsure, say N.
> > > +
> > > +config VIRTIO_OVER_PCI_FSL
> > > + tristate "Virtio-over-PCI Guest support (EXPERIMENTAL)"
> > > + depends on MPC834x_MDS && EXPERIMENTAL
> > > + select VIRTIO
> > > + select DMA_ENGINE
> > > + select FSL_DMA
> > > + ---help---
> > > + This driver provides the guest support necessary for=20
> > > using virtio
> > > + over the PCI bus.
> > > +
> > > + If unsure, say N.
> > > +
> > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > index 6738c44..f31afaa 100644
> > > --- a/drivers/virtio/Makefile
> > > +++ b/drivers/virtio/Makefile
> > > @@ -2,3 +2,5 @@ obj-$(CONFIG_VIRTIO) +=3D virtio.o
> > > obj-$(CONFIG_VIRTIO_RING) +=3D virtio_ring.o
> > > obj-$(CONFIG_VIRTIO_PCI) +=3D virtio_pci.o
> > > obj-$(CONFIG_VIRTIO_BALLOON) +=3D virtio_balloon.o
> > > +obj-$(CONFIG_VIRTIO_OVER_PCI_HOST) +=3D vop_host.o
> > > +obj-$(CONFIG_VIRTIO_OVER_PCI_FSL) +=3D vop_fsl.o
> > I suppose we need to build the kernel twice. one for=20
> vop_host (on host
> > with pci enabled) and the
> > other is for vop_fsl ( on agent with pci disabled). Is it=20
> possible to
> > build one image for both host and=20
> > agent. We do not scan the pci bus if the controller is=20
> configured to
> > agent.
> >=20
>=20
> You should be able to build a kernel with support for both host and
> guest operation, and then use the device tree to switch which=20
> driver you
> get. The host driver won't be used without a PCI bus, and the guest
> driver won't be used without the message unit.
Good.
Is it necssary to commit a extra dts for the agent mode? or just
document it?
>=20
> > Also, is it possible to include mpc85xx architecture? They should be
> > same.
> > There is some code for 85xx in Fresscale BSP.
> >=20
> http://www.bitshrine.org/gpp/linux-fsl-2.6.23-MPC8568MDS_PCI_A
> gent_PCIe_
> > EP_Drvier.patch
>=20
> I looked at the cardnet driver before I implemented my PCINet=20
> driver. I
> hunch it would be rejected for the same reasons, but maybe=20
> not.=20
That is also our concern :-(
>Also, it
> makes no use of DMA, which is critical for good transfer speed. Using
> memcpy() in PCINet gives performance around 10 mbit/sec, which is
> terrible.
I can see your improvement for performance.
>=20
> I'm sure the driver isn't very hard to port to 85xx, I just don't have
> any 85xx boards to test with. The driver only directly interacts with
> the messaging unit, which is a pretty simple piece of hardware.
No matter. It is OK to just support 83xx boards currently.
85xx baords can be dealed with later.
Finally, I hope this driver can support 83xx /85xx boards pci and pci
express mode.
Roy
^ permalink raw reply
* RE: [RFC v1] virtio: add virtio-over-PCI driver
From: Zang Roy-R61911 @ 2009-02-20 3:44 UTC (permalink / raw)
To: Kumar Gala
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev, Ira Snyder
In-Reply-To: <C04B22C6-BCE8-4D99-A160-22F8846C8209@kernel.crashing.org>
=20
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, February 20, 2009 0:52 AM
> To: Zang Roy-R61911
> Cc: Ira Snyder; Arnd Bergmann; Jan-Bernd Themann;=20
> netdev@vger.kernel.org; Rusty Russell;=20
> linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org
> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
>=20
>=20
> On Feb 19, 2009, at 12:13 AM, Zang Roy-R61911 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From:
> >> linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs.org
> >> [mailto:linuxppc-dev-bounces+tie-fei.zang=3Dfreescale.com@ozlabs
> >> .org] On Behalf Of Kumar Gala
> >> Sent: Thursday, February 19, 2009 0:47 AM
> >> To: Ira Snyder
> >> Cc: Arnd Bergmann; Jan-Bernd Themann; netdev@vger.kernel.org;
> >> Rusty Russell; linux-kernel@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org
> >> Subject: Re: [RFC v1] virtio: add virtio-over-PCI driver
> >>
> >>
> >> On Feb 17, 2009, at 4:24 PM, Ira Snyder wrote:
> >>
> >>>
> >>> Documentation/virtio-over-PCI.txt | 61 ++
> >>> arch/powerpc/boot/dts/mpc834x_mds.dts | 7 +
> >>
> >> we'll have to review the .dts and expect a documentation update for
> >> the node. But that's pretty minor at this point.
> >>
> >>> drivers/virtio/Kconfig | 22 +
> >>> drivers/virtio/Makefile | 2 +
> >>> drivers/virtio/vop.h | 119 ++
> >>> drivers/virtio/vop_fsl.c | 1911
> >> ++++++++++++++++++++++++
> >>> +++++++++
> >>
> >> make this vop_fsl_mpc83xx.c or something along those lines.
> > why?
>=20
> so we can deal with 85xx as well.=20
After some modificaiton, the driver should be used on 85xx.
For 85xx, most of the cases are for pci express.
> We just need to isolate the 83xx =20
> specific bits (message usage)
Yes.
Roy
^ permalink raw reply
* [PATCH] powerpc: Add alignment handler for new lfiwzx instruction
From: Michael Neuling @ 2009-02-20 4:51 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
lfiwzx is a new floating point load instruction in 2.06 that needs an
alignment handler for Linux.
Turns out to be the worlds easiest handler to add.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Benh: this is for 2.6.30, but would be nice to be back in 2.6.27/28/29
too.
arch/powerpc/kernel/align.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/align.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/align.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/align.c
@@ -187,7 +187,7 @@ static struct aligninfo aligninfo[128] =
{ 4, ST+F+S+U }, /* 11 1 1010: stfsux */
{ 8, ST+F+U }, /* 11 1 1011: stfdux */
INVALID, /* 11 1 1100 */
- INVALID, /* 11 1 1101 */
+ { 4, LD+F }, /* 11 1 1101: lfiwzx */
INVALID, /* 11 1 1110 */
INVALID, /* 11 1 1111 */
};
^ permalink raw reply
* [PATCH] powerpc: Fix load/store float double alignment handler
From: Michael Neuling @ 2009-02-20 4:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
When we introduced VSX, we changed the way FPRs are stored in the
thread_struct. Unfortunately we missed the load/store float double
alignment handler code when updating how we access FPRs in the
thread_struct.
Below fixes this and merges the little/big endian case.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
benh: this needs to go into 27,28 and 29. Sorry :-)
arch/powerpc/kernel/align.c | 29 +++++++++++++----------------
1 file changed, 13 insertions(+), 16 deletions(-)
Index: linux-bml/arch/powerpc/kernel/align.c
===================================================================
--- linux-bml.orig/arch/powerpc/kernel/align.c
+++ linux-bml/arch/powerpc/kernel/align.c
@@ -367,27 +367,24 @@ static int emulate_multiple(struct pt_re
static int emulate_fp_pair(unsigned char __user *addr, unsigned int reg,
unsigned int flags)
{
- char *ptr = (char *) ¤t->thread.TS_FPR(reg);
- int i, ret;
+ char *ptr0 = (char *) ¤t->thread.TS_FPR(reg);
+ char *ptr1 = (char *) ¤t->thread.TS_FPR(reg+1);
+ int i, ret, sw = 0;
if (!(flags & F))
return 0;
if (reg & 1)
return 0; /* invalid form: FRS/FRT must be even */
- if (!(flags & SW)) {
- /* not byte-swapped - easy */
- if (!(flags & ST))
- ret = __copy_from_user(ptr, addr, 16);
- else
- ret = __copy_to_user(addr, ptr, 16);
- } else {
- /* each FPR value is byte-swapped separately */
- ret = 0;
- for (i = 0; i < 16; ++i) {
- if (!(flags & ST))
- ret |= __get_user(ptr[i^7], addr + i);
- else
- ret |= __put_user(ptr[i^7], addr + i);
+ if (flags & SW)
+ sw = 7;
+ ret = 0;
+ for (i = 0; i < 8; ++i) {
+ if (!(flags & ST)) {
+ ret |= __get_user(ptr0[i^sw], addr + i);
+ ret |= __get_user(ptr1[i^sw], addr + i + 8);
+ } else {
+ ret |= __put_user(ptr0[i^sw], addr + i);
+ ret |= __put_user(ptr1[i^sw], addr + i + 8);
}
}
if (ret)
^ permalink raw reply
* Re: Newby trying to get Ethernet going on MPC83xx series device.
From: Michael Bergandi @ 2009-02-20 5:00 UTC (permalink / raw)
To: Dushara Jayasinghe
Cc: linuxppc-dev@ozlabs.org, Aggrwal Poonam-B10812, Timur Tabi
In-Reply-To: <DE0CCFFBFF707949BEABD4537A14ACBA0C04B4054D@mailsvr>
[-- Attachment #1: Type: text/plain, Size: 4891 bytes --]
Hi Dushara,
Sorry, I'm a late comer here, but I might have an idea. First off, I don't
see below what
kernel version you are using? I may have missed it somewhere.
> The devices are successfully probed, but I'm getting this error on the
> debug console:
>
> [ 7.119389] mdio@24520:00 not found
> [ 7.161370] eth0: Could not attach to PHY
> [ 7.209600] IP-Config: Failed to open eth0
> [ 7.258879] IP-Config: Device `eth0' not found.
I have similar output on my MPC8313E RDB. In my case, eth0 shared lines with
the external USB OTG and its PHY. I modified the resister banks on the board
that essentially cuts off the interrupt to the eth0 PHY. So, I don't expect
it to find it. Here is the kernel output at init time:
24520:01 not found
eth0: Could not attach to PHY
My mdio & Ethernet nodes are as follows (commenting out device_type below is
> an experiment)
>
> mdio@24520 {
> /*device_type = "mdio";*/
> compatible = "fsl,gianfar-mdio";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <24520 20>;
Hmm, well, the first thing I catch is this is an old dts format. Depending
on your kernel version, you
may want to comply with the dts v1 spec. The v1 spec is much more strict on
the format of the values
that are provided for the properties.
ex. reg = <0x24520 0x20> makes it very clear that these values are hex, not
decimal.
You will notice this ambiguity below with the 'interrupts' properties. Are
the values decimal or hex?
Turns out that the values are hex. You will find dts version specifier "
/dts-v1/; " at the top or just before
the root node in any dts file that meets the v1 spec.
>
> phy0: ethernet-phy@0 {
> interrupt-parent = <&ipic>;
> interrupts = <3 8>;
> reg = <0>;
> device_type = "ethernet-phy";
> };
> phy1: ethernet-phy@1 {
> interrupt-parent = <&ipic>;
> interrupts = <3 8>;
> reg = <1>;
> device_type = "ethernet-phy";
> };
> };
Are you sure both PHY's use interrupt 3? I would think not.
enet0: ethernet@24000 {
> cell-index = <0>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <20 8 21 8 22 8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy0>;
> linux,network-index = <0>;
> };
>
> enet1: ethernet@25000 {
> cell-index = <1>;
> device_type = "network";
> model = "TSEC";
> compatible = "gianfar";
> reg = <25000 1000>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <23 8 24 8 25 8>;
> interrupt-parent = <&ipic>;
> phy-handle = <&phy1>;
> linux,network-index = <1>;
> phy-connection-type = "gmii";
> };
Finally, I don't know which silicon rev that you are using, but I have seen
the enet0 and enet1 interrupts swapped.
As in the very latest silicon may have the interrupt lines switched between
them. You can find a statement to that
affect on this list somewhere. I am using a revB MPC8313E and I specify the
interrupts as you have them here.
However, the dts file for the mpc8313erdb in the 2.6.28 kernel has them
reversed. Presumably for a revC chip.
ex.
enet0: ethernet@24000 {
...
interrupts = <23 8 24 8 25 8>;
...
};
enet1: ethernet@25000 {
...
interrupts = <20 8 21 8 22 8>;
...
};
> BTW, I assume CCing all those who replied to me is accepted/expected
> conduct or should I avoid this and just write to the list?
Yes, you should cc those who have replied. It is expected --- well, at least
by me.
Also is top posting ok? I haven't figured out how to enable '>' on bloody
> Microsoft Outlook, for incoming plain text messages.
I'm a little new to this list, but in general top posting is frowned upon.
Unfortunately, I can't help you with the Outlook problem.
I can tell you that not being able to determine what part of a message came
when is extremely annoying. I hope you find a fix
for it. Or, you could try Thunderbird :)
Mike
[-- Attachment #2: Type: text/html, Size: 9422 bytes --]
^ permalink raw reply
* Re: How to bring up fs_enet on 2.6.27?
From: Daniel Ng @ 2009-02-20 5:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Mike Ditto
In-Reply-To: <20090219184410.GB4180@ld0162-tx32.am.freescale.net>
On Fri, Feb 20, 2009 at 5:44 AM, Scott Wood <scottwood@freescale.com> wrote:
> See this thread:
> http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068467.html
>
Great, that's helped. Thanks Scott.
Now, I'm seeing these boot messages:
f0010d40:00 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
Previous mailing list discussions suggest that I use the correct PHY,
which I am sure about because my 8272-based board only has the one PHY
ie. PHY0 with reg = <0x0>.
Note the relevant parts of my Device Tree below. Currently, our PHY
attributes eg. 'auto-negotiate' are not changeable, so we aren't
actually using MDC+MDIO even the MDC+MDIO lines exist. Also, the PHY
interrupt line is not wired up. Hence the PHY0 interrupts field is <0
8> (or should it be removed altogether?).
I am usig FCC2.
What might I need to change to get the ethernet driver working?
ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
// FCC2-
reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x16200300>;
};
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <0x10d40 0x14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <5>;
fsl,mdc-pin = <19>;
PHY0: ethernet-phy@0 {
interrupt-parenn = <&PIC>;
interrupts = <0 8>;
reg = <0x0>;
device_type = "ethernet-phy";
};
.
.
.
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
Cheers,
Daniel
^ permalink raw reply
* Re: [PATCH] Enable hashdist by default on PowerPC
From: Anton Blanchard @ 2009-02-20 5:19 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20090218.011924.07030610.davem@davemloft.net>
Hi David,
> I should probably do this on sparc64 too.
>
> Why don't we just change this thing to CONFIG_64BIT?
I agree. How does this look?
Anton
--
On PowerPC we allocate large boot time hashes on node 0. This leads to
an imbalance in the free memory, for example on a 64GB box (4 x 16GB
nodes):
Free memory:
Node 0: 97.03%
Node 1: 98.54%
Node 2: 98.42%
Node 3: 98.53%
If we switch to using vmalloc (like ia64 and x86-64) things are more
balanced:
Free memory:
Node 0: 97.53%
Node 1: 98.35%
Node 2: 98.33%
Node 3: 98.33%
For many HPC applications we are limited by the free available memory on
the smallest node, so even though the same amount of memory is used the
better balancing helps.
Since all 64bit NUMA capable architectures should have sufficient
vmalloc space, it makes sense to enable it via CONFIG_64BIT.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 95837bf..aa861d5 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -144,10 +144,10 @@ extern void *alloc_large_system_hash(const char *tablename,
#define HASH_EARLY 0x00000001 /* Allocating during early boot? */
-/* Only NUMA needs hash distribution.
- * IA64 and x86_64 have sufficient vmalloc space.
+/* Only NUMA needs hash distribution. 64bit NUMA architectures have
+ * sufficient vmalloc space.
*/
-#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64))
+#if defined(CONFIG_64BIT)
#define HASHDIST_DEFAULT 1
#else
#define HASHDIST_DEFAULT 0
^ permalink raw reply related
* RE: Newby trying to get Ethernet going on MPC83xx series device.
From: Dushara Jayasinghe @ 2009-02-20 7:18 UTC (permalink / raw)
To: 'Michael Bergandi'
Cc: linuxppc-dev@ozlabs.org, Aggrwal Poonam-B10812, Timur Tabi
In-Reply-To: <1c641bc80902192100w2c46a447ued43a6b98b877676@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]
Sorry, I'm a late comer here, but I might have an idea. First off, I don't see below what
kernel version you are using? I may have missed it somewhere.
[dj]
Sorry I should have mentioned that earlier. I'm using 2.6.29-rc5 (pulled couple of days ago)
Hmm, well, the first thing I catch is this is an old dts format. Depending on your kernel version, you
may want to comply with the dts v1 spec. The v1 spec is much more strict on the format of the values
that are provided for the properties.
[dj]
I've fixed that since. Thanks.
phy0: ethernet-phy@0 {
interrupt-parent = <&ipic>;
interrupts = <3 8>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&ipic>;
interrupts = <3 8>;
reg = <1>;
device_type = "ethernet-phy";
};
};
Are you sure both PHY's use interrupt 3? I would think not.
[dj]
I need to follow that through and see.
Also is top posting ok? I haven't figured out how to enable '>' on bloody Microsoft Outlook, for incoming plain text messages.
I'm a little new to this list, but in general top posting is frowned upon. Unfortunately, I can't help you with the Outlook problem.
I can tell you that not being able to determine what part of a message came when is extremely annoying. I hope you find a fix
for it. Or, you could try Thunderbird :)
[dj]
I'm using the HTML format. I've tagged my comments just in case the context is lost.
Consequently, I found, some further insights into the issue. Here's a debug output.
[ 7.124188] {
[ 7.143107] bus_id=mdio@24520:00 < - - printed in drivers/net/phy/phy_device.c : phy_connect()
[ 7.181907] match check mdio@24520:1f < - - printed in drivers/base/bus.c : match_name()
[ 7.225946] mdio@24520:00 not found
[ 7.267883] }
Where does the :1f or :00 get added?
Thanks
D
[-- Attachment #2: Type: text/html, Size: 9093 bytes --]
^ 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