* Re: [Cbe-oss-dev] Please pull 'for-2.6.25' branch of cell tree
From: Arnd Bergmann @ 2008-03-03 8:14 UTC (permalink / raw)
To: linuxppc-dev, michael; +Cc: paulus, cbe-oss-dev
In-Reply-To: <1204265597.7729.27.camel@concordia.ozlabs.ibm.com>
On Friday 29 February 2008, Michael Ellerman wrote:
> On Fri, 2008-02-29 at 06:12 +0100, Arnd Bergmann wrote:
> > Hi Paul,
> >
> > Please pull from:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git for-2.6.25
> >
> > To pick up a few small fixes for the cell platform. Most of it is a follow-up
> > to the IOMMU rework that got merged in 2.6.25-rc1 and caused problems on
> > machines with large amounts of memory.
>
> Sorry, I have updated versions of the IOMMU patches to send. Arnd is
> away for the weekend, so Paul if you just want to cherry pick the other
> fixes that might work. I'll send the updated IOMMU patches momentarily.
The git tree should finally be fixed up now, same location as before,
commit ID is now da40451bba23b51eaca4170a095891646ce72104.
Arnd <><
^ permalink raw reply
* ml403 linux port with hard_temac
From: Antoine BRUNET @ 2008-03-03 9:17 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5326 bytes --]
Hi,
I try to build 2.6.24rc3 kernel of secretlab git for ml403.
I can build the kernel for a BSP (xilinx) without hard_temac and plb_temac.
And the kernel boot on ml403 :
loaded at: 00400000 007C01A0
board data at: 007BE124 007BE1A0
relocated to: 004040B8 00404134
zimage at: 00404EA9 0053D590
initrd at: 0053E000 007BE000
avail ram: 007C1000 04000000
Linux/PPC load: console=ttyS0,9600 root=/dev/ram0 rw initrd=/linuxrc
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.24-rc3-gd7ed933b-dirty (root@debian) (gcc version 4.0.2)
#28 Thu Feb 28 11:16:30 CET 2008
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 16256
[ 0.000000] Kernel command line: console=ttyS0,9600 root=/dev/ram0 rw
initrd=/linuxrc
[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000427] Console: colour dummy device 80x25
[ 0.001585] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.003394] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.037491] Memory: 59464k available (2100k kernel code, 672k data, 108k
init, 0k highmem)
[ 0.129388] Mount-cache hash table entries: 512
[ 0.138776] net_namespace: 64 bytes
[ 0.150035] NET: Registered protocol family 16
[ 0.222660] NET: Registered protocol family 2
[ 0.257836] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.264505] TCP established hash table entries: 2048 (order: 2, 16384
bytes)
[ 0.265237] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.265673] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.265756] TCP reno registered
[ 0.279119] checking if image is initramfs...it isn't (bad gzip magic
numbers); looks like an initrd
[ 0.393762] Freeing initrd memory: 2560k freed
[ 0.397985] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.398155] Call Trace:
[ 0.398209] [c3c17e80] [c000835c] show_stack+0x4c/0x174 (unreliable)
[ 0.398428] [c3c17eb0] [c003644c] set_fail+0x50/0x68
[ 0.398609] [c3c17ed0] [c0036ad4] sysctl_check_table+0x670/0x6bc
[ 0.398744] [c3c17f10] [c0036ae8] sysctl_check_table+0x684/0x6bc
[ 0.398873] [c3c17f50] [c002416c] register_sysctl_table+0x5c/0xac
[ 0.399053] [c3c17f70] [c0292a58] register_ppc_htab_sysctl+0x18/0x2c
[ 0.399257] [c3c17f80] [c028c824] kernel_init+0xb4/0x270
[ 0.399377] [c3c17ff0] [c0004b18] kernel_thread+0x44/0x60
[ 0.413198] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 0.418934] io scheduler noop registered (default)
[ 0.552627] Generic RTC Driver v1.07
[ 0.554582] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ
sharing disabled
[ 0.562210] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 0) is a 16550A
[ 0.562392] console [ttyS0] enabled
[ 3.488329] RAMDISK driver initialized: 4 RAM disks of 8192K size 1024
blocksize
[ 3.592001] loop: module loaded
[ 3.632702] $Id: ftl.c,v 1.59 2005/11/29 14:48:31 gleixner Exp $
[ 3.705897] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c$Revision:
1.41 $
[ 3.800355] INFTL: inftlcore.c $Revision: 1.19 $, inftlmount.c $Revision:
1.18 $
[ 3.891145] SSFDC read-only Flash Translation layer
[ 3.955590] TCP cubic registered
[ 3.994870] NET: Registered protocol family 1
[ 4.047673] NET: Registered protocol family 17
[ 4.103431] RPC: Registered udp transport module.
[ 4.160199] RPC: Registered tcp transport module.
[ 4.221066] RAMDISK: ext2 filesystem found at block 0
[ 4.282120] RAMDISK: Loading 2560KiB [1 disk] into ram disk... done.
[ 5.139783] EXT2-fs warning: mounting unchecked fs, running e2fsck is
recommended
[ 5.230262] VFS: Mounted root (ext2 filesystem).
[ 5.286631] Freeing unused kernel memory: 108k init
init started: BusyBox v1.8.2 (2008-02-11 16:09:57 CET)
starting pid 160, tty '': '/etc/init.d/rcS'
Cannot run '/etc/init.d/rcS': Permission denied
Please press Enter to activate this console.
starting pid 161, tty '': '/bin/sh'
#
If I add hard_temac and plb_temac in the same BSP and add in the .config of
the kernel:
CONFIG_NETDEV_1000=y
CONFIG_XILINX_TEMAC=y
#CONFIG_XILINX_TEMAC_PHY_GENERIC_PHY is not set
CONFIG_XILINX_TEMAC_PHY_MARVELL_88E1111=y
The kernel can't boot :
loaded at: 00400000 007BE1A0
board data at: 007BC124 007BC1A0
relocated to: 004040B8 00404134
zimage at: 00404EA9 0053B2E6
initrd at: 0053C000 007BC000
avail ram: 007BF000 04000000
Linux/PPC load: console=ttyS0,9600 root=/dev/ram0 rw initrd=/linuxrc
Uncompressing Linux...done.
Now booting the kernel
And the kernel displays nothing else...
I use a hard_temac 3.00a.
I have difficulties to locate the problem. Someone can help me? Thanks
--
-------------------------------------------------
Antoine BRUNET
[-- Attachment #2: Type: text/html, Size: 6930 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Gabriel Paubert @ 2008-03-03 9:19 UTC (permalink / raw)
To: Jarod Wilson
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, Stefan Richter,
sparclinux, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <47C79CB1.6050104@redhat.com>
On Fri, Feb 29, 2008 at 12:48:33AM -0500, Jarod Wilson wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote:
> >> On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote:
> >>>> Under Mac OS X, system.log says "FireWire (OHCI) Apple ID 31 built-in now
> >>>> active". Could still be lucent though, judging by the subsys device ID of
> >>>> 5811, which matches up w/the Lucent/Agere FW323. But no, apparently I
> >>>> don't have the interesting one.
> >>> Well, it's interesting in the sense that it's a "normal" OHCI then on a
> >>> BE machine :-) My Pismo, which had the weirdo one, unfortunately died a
> >>> while ago. I'll see if I can find another machine with that one in.
> >> Ah, the pismo has it, eh? I think I may actually know of someone in the office
> >> that still has one of those that I might be able to borrow and poke at...
> >
> > I -think- it has it... Pismo definitely has one of the first variant of
> > UniNorth with "working" FW afaik.
> >
> > The first UniNorth was used in the first "toilet-seat" ibook, but I
> > think this one didn't have firewire, or a non-working one... and in the
> > first Sawtooth G4 for which FW and Ethernet even were separate PCI chips
> > because the ones in UniNorth were too broken.
> >
> > It's possible that early G4 titanium powerbooks or other model of FW
> > iBooks have that UniNorth FW variant too.
>
> Still no luck finding one here. The person I was thinking of has a
> Lombard, which has no firewire. I did get ahold of a 667MHz Titanium,
> but its got an Agere FW323. Pretty sure my old man actually has a Pismo,
> but its about a 3000 mile drive over to my folks house. The search
> continues... I wonder how many people still actually 1) have a machine
> with this controller, 2) are running Linux on it and 3) use firewire
> devices with it. Both of you, please speak up, we're trying to help you!
> (if only out of morbid curiosity to see this mythical goofy controller).
Definitely yes to 1) and 2), I have a Pismo which I use on a virtually
daily basis (and about to remove the last remnants of MacOS on it).
However I have disabled Firewire because it would not sleep and wake
up properly.
I can test it on Wednesday with a 5GB fireflly disk from 2001.
Please tell me which configuration options I need to set for
Firewire (which stack, etc...).
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Gabriel Paubert @ 2008-03-03 9:54 UTC (permalink / raw)
To: Steven Rostedt; +Cc: paulus, LKML, linuxppc-dev
In-Reply-To: <Pine.LNX.4.58.0802292250490.21555@gandalf.stny.rr.com>
On Fri, Feb 29, 2008 at 10:56:45PM -0500, Steven Rostedt wrote:
>
> On Sat, 1 Mar 2008, Benjamin Herrenschmidt wrote:
> >
> > Do we have any indication that it performs better than the C one ?
>
> See below.
>
> >
> > Ben.
> >
>
> > >
> > > +_GLOBAL(strncmp)
> > > + mtctr r5
> > > + addi r5,r3,-1
> > > + addi r4,r4,-1
> > > +1: lbzu r3,1(r5)
> > > + cmpwi 1,r3,0
> > > + lbzu r0,1(r4)
> > > + subf. r3,r0,r3
> > > + beqlr 1
> > > + bdnzt eq,1b
> > > + blr
> > > +
>
>
> And here's the objdump of the C version:
>
> 0000000000000080 <.strncmp>:
> 80: fb e1 ff f0 std r31,-16(r1)
> 84: f8 21 ff c1 stdu r1,-64(r1)
> 88: 7c 69 1b 78 mr r9,r3
> 8c: 7c a0 2b 79 mr. r0,r5
> 90: 38 60 00 00 li r3,0
> 94: 7c 09 03 a6 mtctr r0
> 98: 7c 3f 0b 78 mr r31,r1
> 9c: 41 82 00 68 beq- 104 <.strncmp+0x84>
> a0: 89 69 00 00 lbz r11,0(r9)
> a4: 88 04 00 00 lbz r0,0(r4)
> a8: 7c 00 58 50 subf r0,r0,r11
> ac: 78 00 06 20 clrldi r0,r0,56
> b0: 2f a0 00 00 cmpdi cr7,r0,0
> b4: 7c 00 07 74 extsb r0,r0
> b8: 7c 03 03 78 mr r3,r0
> bc: 40 9e 00 48 bne- cr7,104 <.strncmp+0x84>
> c0: 2f ab 00 00 cmpdi cr7,r11,0
> c4: 41 9e 00 40 beq- cr7,104 <.strncmp+0x84>
> c8: 38 84 00 01 addi r4,r4,1
> cc: 38 69 00 01 addi r3,r9,1
> d0: 42 40 00 30 bdz- 100 <.strncmp+0x80>
> d4: 88 03 00 00 lbz r0,0(r3)
> d8: 89 24 00 00 lbz r9,0(r4)
> dc: 38 63 00 01 addi r3,r3,1
> e0: 38 84 00 01 addi r4,r4,1
> e4: 2f 20 00 00 cmpdi cr6,r0,0
> e8: 7c 09 00 50 subf r0,r9,r0
> ec: 78 00 06 20 clrldi r0,r0,56
> f0: 2f a0 00 00 cmpdi cr7,r0,0
> f4: 7c 00 07 74 extsb r0,r0
> f8: 40 9e 00 08 bne- cr7,100 <.strncmp+0x80>
> fc: 40 9a ff d4 bne+ cr6,d0 <.strncmp+0x50>
> 100: 7c 03 03 78 mr r3,r0
> 104: e8 21 00 00 ld r1,0(r1)
> 108: eb e1 ff f0 ld r31,-16(r1)
> 10c: 4e 80 00 20 blr
>
>
> I'll let you decide ;-)
>
> Even if it was logically faster (which I still doubt) it's a hell of a lot
> of cache lines to waste.
Indeed, but there are some corner cases that the C code handles. Like
a length of 0 which may lead to infinite loop in the asm code.
OTOH, I'm a bit surprised by the extsb instructions in the compiler generated
code. We don't compile with -fsigned-char, do we? The clrldi
instructions are also extremely stupid.
Now that I think a bit more about it, I believe that the C version is
incorrect: the clrldi/extsb dance takes a value between -255 and +255
and collapses it into the -128 to 127 range, meaning that the return
value may be wrong if we rely on the sign of the result. So unless I
miss something, the problem is much more serious than just stupid code
(I had just a look at the libc version in C and characters are cast to
unsigned char before the comparison).
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Andreas Schwab @ 2008-03-03 10:10 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, paulus, LKML, Steven Rostedt
In-Reply-To: <20080303095443.GB27105@iram.es>
Gabriel Paubert <paubert@iram.es> writes:
> Now that I think a bit more about it, I believe that the C version is
> incorrect: the clrldi/extsb dance takes a value between -255 and +255
> and collapses it into the -128 to 127 range, meaning that the return
> value may be wrong if we rely on the sign of the result. So unless I
> miss something, the problem is much more serious than just stupid code
> (I had just a look at the libc version in C and characters are cast to
> unsigned char before the comparison).
The latter is explicitly required by the C standard. Ie. even if your
characters are signed they are always compared as unsigned by
strcmp/strncmp/memcmp.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-03-03 11:41 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug-fixes for powerpc, for the Cell, 4xx and
52xx platforms.
Thanks,
Paul.
arch/powerpc/boot/cuboot-bamboo.c | 1
arch/powerpc/boot/cuboot-ebony.c | 1
arch/powerpc/boot/cuboot-katmai.c | 1
arch/powerpc/boot/cuboot-taishan.c | 2
arch/powerpc/boot/cuboot-warp.c | 1
arch/powerpc/boot/dts/haleakala.dts | 2
arch/powerpc/boot/dts/katmai.dts | 58 +++++-----
arch/powerpc/oprofile/op_model_cell.c | 2
arch/powerpc/platforms/52xx/mpc52xx_common.c | 1
arch/powerpc/platforms/cell/iommu.c | 151 +++++++++++++++-----------
arch/powerpc/platforms/cell/setup.c | 7 +
arch/powerpc/platforms/cell/spu_base.c | 16 ++-
arch/powerpc/platforms/cell/spufs/context.c | 7 +
arch/powerpc/platforms/cell/spufs/file.c | 12 ++
arch/powerpc/platforms/cell/spufs/sched.c | 2
arch/powerpc/platforms/cell/spufs/sputrace.c | 7 +
arch/powerpc/platforms/cell/spufs/switch.c | 6 +
arch/powerpc/platforms/celleb/beat.h | 3 -
drivers/char/xilinx_hwicap/buffer_icap.c | 80 +++++++-------
drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++++-----
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 138 +++++++++++-------------
drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 ++--
include/asm-powerpc/reg.h | 3 +
23 files changed, 318 insertions(+), 267 deletions(-)
Andre Detsch (1):
[POWERPC] spufs: fix use time accounting on SPE-overcommit
Arnd Bergmann (3):
[POWERPC] spufs: synchronize IRQ when disabling
[POWERPC] spufs: invalidate SLB translation before adding a new entry
[POWERPC] spufs: serialize SLB invalidation against SLB loading
Bob Nelson (1):
[POWERPC] OProfile: enable callgraph support for Cell
Eric Dujardin (1):
[POWERPC] Add export for mpc52xx_set_psc_clkdiv
Jens Osterkamp (2):
[POWERPC] move celleb DABRX definitions
[POWERPC] enable hardware watchpoints on cell blades
Jeremy Kerr (3):
[POWERPC] spufs: fix context destruction during psmap fault
[POWERPC] spufs: fix invalid scheduling of forgotten contexts
[POWERPC] spufs: fix order of sputrace thread IDs
Josh Boyer (1):
[POWERPC] 4xx: Use correct board info structure in cuboot wrappers
Michael Ellerman (8):
[POWERPC] Clearup cell IOMMU fixed mapping terminology
[POWERPC] Use it_offset not pte_offset in cell IOMMU code
[POWERPC] Remove unused pte_offset variable
[POWERPC] Move allocation of cell IOMMU pad page
[POWERPC] Split setup of IOMMU stab and ptab, allocate dynamic/fixed ptabs separately
[POWERPC] Cell IOMMU: n_pte_pages is in 4K page units, not IOMMU_PAGE_SIZE
[POWERPC] Allow for different IOMMU page sizes in cell IOMMU code
[POWERPC] Convert the cell IOMMU fixed mapping to 16M IOMMU pages
Stefan Roese (2):
[POWERPC] 4xx: Fix Haleakala PCIe compatibility problem in dts
[POWERPC] 4xx: Fix L1 cache size in katmai DTS
Stephen Neuendorffer (1):
[POWERPC] Xilinx: hwicap cleanup
Valentine Barshak (1):
[POWERPC] 44x: add missing define TARGET_4xx and TARGET_440GX to cuboot-taishan
^ permalink raw reply
* I2S driver
From: Angelo @ 2008-03-03 12:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
Hi my name is Angelo.
I'm working on I2S driver, on MPC5200b board.
Does anyone tell me where i can found some information on HOW to write it?
Thanks for help.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 486 bytes --]
^ permalink raw reply
* Re: I2S driver
From: Roman Fietze @ 2008-03-03 12:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Hello Ngelo,
On Monday 03 March 2008 13:08:43 Angelo wrote:
> I'm working on I2S driver, on MPC5200b board.
An ALSA sound driver?
If yes, there are many places where you can find documentation. If
not, there are still many places where you can find documentation.
Could you please specify more precisely what you want to do or where
you are having problems.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ permalink raw reply
* [PATCH] ehea: Fix missing Kconfig dependency
From: Thomas Klein @ 2008-03-03 12:52 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Stefan Roscher
Fixed Kconfig: ehea driver requires sparse mem
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp linux-2.6.25-rc3.org/drivers/net/Kconfig linux-2.6.25-rc3/drivers/net/Kconfig
--- linux-2.6.25-rc3.org/drivers/net/Kconfig 2008-02-24 22:25:54.000000000 +0100
+++ linux-2.6.25-rc3/drivers/net/Kconfig 2008-03-03 13:36:48.000000000 +0100
@@ -2513,7 +2513,7 @@ config CHELSIO_T3
config EHEA
tristate "eHEA Ethernet support"
- depends on IBMEBUS && INET
+ depends on IBMEBUS && INET && SPARSEMEM
select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
^ permalink raw reply
* RE: I2S driver
From: Pedro Luis D. L. @ 2008-03-03 13:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Angelo wrote:
=20
> Hi my name is Angelo.
>=20
> I'm working on I2S driver, on MPC5200b board.
> Does anyone tell me where i can found some information on HOW to write it=
?
>=20
> Thanks for help.
>=20
Hello Angelo,
depends on which kernel version are you using. You can find some working co=
de in DENX repository:
http://source.denx.net/cgi-bin/gitweb.cgi
=20
I can also send you some GPL'd code that works. It is extremely bad comment=
ed (:-p) and probably not useful (it's not an ALSA driver itself, but it us=
es the DMA to copy data to the PSC - I2S mode) but it works. But this code =
is based on 2.6.16 kernel.
Tell me the version and I would guide you a little bit.
=20
Regards,
Pedro.
_________________________________________________________________
MSN Video.=20
http://video.msn.com/?mkt=3Des-es=
^ permalink raw reply
* i2s driver
From: Angelo @ 2008-03-03 13:18 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
Thanks for answer.
>I can also send you some GPL'd code that works.
>It is extremely bad commented (:-p) and probably not useful
> (it's not an ALSA driver itself, but it uses the DMA to
> copy data to the PSC - I2S mode) but it works.
It is a great idea; i can use it to start.
You can send it via mail..
> But this code is based on 2.6.16 kernel.
I'm using 2.6.22 kernel version.
I just enabled in lite5200b.dts:
//PSC3 in CODEC mode example //asimmini
i2s@2400 { // PSC3
device_type = "sound";
compatible = "mpc5200b-psc-i2s";//not 5200 compatible
cell-index = <2>;
reg = <2400 100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
..and added in lite5200.c, in function mpc52xx_psc_functions
...
struct mpc52xx_psc_func mpc52xx_psc_functions[]= {
{ .id = 2,
.func = "i2s",
},
...
thanks for help.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 1567 bytes --]
^ permalink raw reply
* The problem about the GETH speed on MPC8360?
From: 郭劲 @ 2008-03-03 13:21 UTC (permalink / raw)
To: support.asia, b09033, linuxppc-embedded
Hi,freescale,
I used the linux-2.6.11 version. I designed the MPC8360 system with 1GB DDR-1
memory and the GMII 1 to interface the 88E1111(RJ45) and GMII 2 to interface the
BCM5387 switch chip(SFP). Now we do the internet test for those GETH. We connect
those RJ45 or SFP to server PC.We used "iperf" test software to test them.
Follow is the test result:
UDP protocol:
Server PC send 1GB data to MPC8360, the speed is about 300Mbps, MPC8360 CPU
used 100%;
MPC8360 send 1GB data to Server PC, the speed is about 600Mbps,MPC8360 CPU
used 100%;
Server PC send 100MB data to MPC8360, and MPC8360 send 100MB to server PC at
the same time, both send and receiver of MPC8360 is 100Mbps. MPC8360 CPU used
100%;
TCP protocol:
Server PC send 1GB data to MPC8360, the speed is about 250Mbps, MPC8360 CPU
used 100%;
MPC8360 send 1GB data to Server PC, the speed is about 6Mbps,MPC8360 CPU
used 20%;
The problem is why the speed is so slow and the cpu used so little during the
last TCP test? The Gigebyte internet is only 6M bit per sencond, it's too slow.
Could you help me to test the MPC8360EMDS board and send me the test report?
Could you tell me why the GETH on MPC8360 is so poor? Even the UDP protocol
just only realize the 100Mbps with the send and receive at the same time on
MPC8360. It just like the 100M internet, not 1000M internet.
Could you tell me why the TCP protocol is much slower then UTP procotol?
We need up to about 900Mbps TCP protocol both on send and receive at the same
time.
^ permalink raw reply
* Re: I2S driver
From: Mark Brown @ 2008-03-03 13:47 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-embedded
In-Reply-To: <200803031340.36665.roman.fietze@telemotive.de>
On Mon, Mar 03, 2008 at 01:40:36PM +0100, Roman Fietze wrote:
> On Monday 03 March 2008 13:08:43 Angelo wrote:
> > I'm working on I2S driver, on MPC5200b board.
> An ALSA sound driver?
> If yes, there are many places where you can find documentation. If
> not, there are still many places where you can find documentation.
> Could you please specify more precisely what you want to do or where
> you are having problems.
If you are working on an audio device in an embedded system you probably
want to use the ALSA SoC subsystem - have a look at
Documentation/sound/alsa/soc and sound/soc for information. There is a
development git tree for this availiable at:
git://opensource.wolfsonmicro.com/linux-2.6-asoc
^ permalink raw reply
* ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 14:47 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).
Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.
I have copied the mpc8540ads.dts file to a new dts file, and added the
following :
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <2b 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ rtc@68 {
+ compatible = "stm,m41t81";
+ reg = <68>;
+ };
};
and I see in the boot log that my RTC chip is now working.
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
irq 18: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
but my boot finally fails with :
VFS: Cannot open root device "hda1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the
available partitions:
1f00 8192 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
Is there an easy way to use values found in /proc or even in the sources
in my working ppc setup to put them in the dts file to make my new powerpc
configuration work ?
Thanks for listening
Philippe
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Grant Likely @ 2008-03-03 14:54 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303144727.GA27949@ingate.macqel>
On Mon, Mar 3, 2008 at 7:47 AM, Philippe De Muyter <phdm@macqel.be> wrote:
> My root device is on a compact-flash connected to a PCI yenta chip from TI,
> and this one is not working, altough it seems to be discovered :
>
> Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
>
> but my boot finally fails with :
>
> VFS: Cannot open root device "hda1" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the
> available partitions:
> 1f00 8192 mtdblock0 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs
> on unknown-block(0,0)
>
> Is there an easy way to use values found in /proc or even in the sources
> in my working ppc setup to put them in the dts file to make my new powerpc
> configuration work ?
It does not look like you are having dts problems. Once your in the
PCI domain, Linux will probe the devices (as your boot log shows).
Rather, your boot failure is due to the yenta device failure.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-03-03 14:35 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <20080303091927.GA27105@iram.es>
Gabriel Paubert wrote:
> I have a Pismo which I use on a virtually
> daily basis (and about to remove the last remnants of MacOS on it).
> However I have disabled Firewire because it would not sleep and wake
> up properly.
>
> I can test it on Wednesday with a 5GB fireflly disk from 2001.
>
> Please tell me which configuration options I need to set for
> Firewire (which stack, etc...).
Config options of the new stack:
FIREWIRE=m
FIREWIRE_OHCI=m
FIREWIRE_SBP2=m
Config options of the old stack:
IEEE1394=m
IEEE1394_OHCI1394=m
IEEE1394_SBP2=m
and if desired also the other drivers for raw userspace access,
isochronous I/O (alias video1394 even though it can also be used for
other purposes), DV I/O, and IPv4 over 1394.
The two SBP2 drivers also need SCSI and BLK_DEV_SD a.k.a. SCSI disk
support or/and BLK_DEV_SR a.k.a. SCSI CDROM support.
You can also set the options to Y but I find loadable and hence
unloadable modules more practical... 'cause I unload and reload them all
the time. :-)
Regarding which of the two stacks to build: If you are going to test
FireWire with a storage device only, then you can choose either stack.
Caveats:
- You could build and install both stacks but should then blacklist
at least one of ohci1394 or firewire-ohci. Better keep it simple
and install only one of the stacks at a time.
- We still have a serious use-after-free bug in the new stack. This
may lead to kernel panic if the kernel was build with (slab? or
page allocation?) debugging enabled.
Users of IP over 1394 and pro/semipro audio still need the old stack.
Users of video should stick with the stack which their distribution has
enabled because our support in the lowlevel libraries libraw1394 and
libdc1394 to switch between the stacks is not quite comfortable yet.
Suspend (to RAM) and resume worked for me [TM] when I last tested them
with each stack. I tested i586/APM, x86-64/ACPI, and last weekend ppc32
on 1st generation PowerBook G4. I haven't tested hibernate (to disk)
and restore yet.
For successful resume on the Pismo with the new stack, you will most
certainly need the brand new patches which add PPC_PMAC platform support
to firewire-ohci. From what I saw with the PowerBook, you will also
need the UniNorth rev1 related patch. I wasn't able to fully test that
patch though because the electrical interface of my PowerBook's onboard
FireWire is dead. You can get the patches from kernel.org's
linux1394-2.6.git (master branch, close to Linus's latest linux-2.6.git)
or http://me.in-berlin.de/~s5r6/linux1394/updates/ (for a few kernel.org
kernels).
The old stack as found in any remotely recent 2.6 kernel should be OK
out of the box without patches... in theory. I wouldn't be surprised of
until now unreported bugs or old reported but forgotten bugs though.
--
Stefan Richter
-=====-==--- --== ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Grant Likely @ 2008-03-03 15:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <18379.58317.223229.950553@cargo.ozlabs.ibm.com>
Paul, can you please pick up this one too?
http://patchwork.ozlabs.org/linuxppc/patch?id=16965
Thanks,
g.
On Mon, Mar 3, 2008 at 4:41 AM, Paul Mackerras <paulus@samba.org> wrote:
> Linus,
>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get a collection of bug-fixes for powerpc, for the Cell, 4xx and
> 52xx platforms.
>
> Thanks,
> Paul.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: I2S driver
From: Timur Tabi @ 2008-03-03 16:42 UTC (permalink / raw)
To: Angelo; +Cc: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Angelo wrote:
> Hi my name is Angelo.
>
> I'm working on I2S driver, on MPC5200b board.
> Does anyone tell me where i can found some information on HOW to write it?
I wrote an ASoC driver for the MPC8610, which also has an I2S interface. You
can find it in sound/soc/fsl.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* I2S driver
From: Angelo @ 2008-03-03 17:05 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Timur wrote:
>I wrote an ASoC driver for the MPC8610, which also has
>an I2S interface. You can find it in sound/soc/fsl.
in my kernel version (2.6.22) there isn't any folder named
fsl in sound/soc/
So where i can found it?
thanks for help.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 597 bytes --]
^ permalink raw reply
* Re: I2S driver
From: Phillip Lougher @ 2008-03-03 17:14 UTC (permalink / raw)
To: Angelo; +Cc: Linuxppc-embedded
In-Reply-To: <157246.48338.qm@web23111.mail.ird.yahoo.com>
On Mon, Mar 3, 2008 at 5:05 PM, Angelo <s104259@yahoo.it> wrote:
> in my kernel version (2.6.22) there isn't any folder named
> fsl in sound/soc/
>
> So where i can found it?
>
Get the development git tree, available at:
git://opensource.wolfsonmicro.com/linux-2.6-asoc
http://opensource.wolfsonmicro.com/node/6 gives more info on the
development trees.
Phillip
> thanks for help.
>
>
>
>
>
> ________________________________
> ________________________________
>
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-03-03 17:26 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <200802251256.41037.bernhard@intevation.de>
[-- Attachment #1.1: Type: text/plain, Size: 1338 bytes --]
On Monday 25 February 2008 12:56, Bernhard Reiter wrote:
> On Friday 22 February 2008 15:50, Bernhard Reiter wrote:
> > > Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> > > has been around since 2001. Seeing as how there really isn't anything
> > > 440 specific in the files effected, we should be able to pass -mcpu=405
> > > for everything and have it still work.
> > >
> > > Bernhard, can you try the patch below?
> >
> > I will test it in the next days.
>
> Done. Looks good.
> (I did _not_ do a full rebuild and installation, only a build test.
> I will do a full blown test with 2.6.24.3.)
Worked fine for me with the attached patch.
Thanks again.
> Note: Your original did not fully apply, I think it had lines like
> -$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> which I did not have in my 2.6.24.
> Probably because you've used a git version of linux.
> What I did was to change the similiar occurances from 440 to 405.
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #1.2: linux-2.4.24-fix-ppcbuild-josh-boyer2.diff --]
[-- Type: text/x-diff, Size: 506 bytes --]
--- linux-2.6.24.3/arch/powerpc/boot/Makefile.org 2008-02-26 22:48:00.709872603 +0100
+++ linux-2.6.24.3/arch/powerpc/boot/Makefile 2008-02-26 22:48:17.509876780 +0100
@@ -35,8 +35,8 @@
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
-$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
+$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] fix QE firmware uploading limit
From: Timur Tabi @ 2008-03-03 17:11 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Timur Tabi
Fix a typo in qe_upload_firmware() that prevented uploading firmware on
systems with more than one RISC core.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch is for 2.6.25.
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 6efbd5e..f963fbf 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -509,7 +509,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate some of the fields */
- if ((firmware->count < 1) || (firmware->count >= MAX_QE_RISC)) {
+ if ((firmware->count < 1) || (firmware->count > MAX_QE_RISC)) {
printk(KERN_ERR "qe-firmware: invalid data\n");
return -EINVAL;
}
--
1.5.4
^ permalink raw reply related
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 17:07 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303144727.GA27949@ingate.macqel>
On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> My root device is on a compact-flash connected to a PCI yenta chip from TI,
> and this one is not working, altough it seems to be discovered :
>
> Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
Maybe your PCI interrupt-map is wrong...
-Scott
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 17:59 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.013269726@ldl.fc.hp.com>
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> Move bridge enable from pcibios_enable_resources() to
> platform_pci_enable_device() so the former matches other
> architectures and can be shared.
I really like the direction of these patches. Getting PCI resources assigned
& devices setup correctly for new arches has always been a bit more trouble
than it should be...
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> Index: work6/arch/arm/kernel/bios32.c
> ===================================================================
> --- work6.orig/arch/arm/kernel/bios32.c 2008-02-27 11:25:29.000000000 -0700
> +++ work6/arch/arm/kernel/bios32.c 2008-02-27 11:55:59.000000000 -0700
> @@ -683,15 +683,32 @@
> cmd |= PCI_COMMAND_MEMORY;
> }
>
> + if (cmd != old_cmd) {
> + printk("PCI: enabling device %s (%04x -> %04x)\n",
> + pci_name(dev), old_cmd, cmd);
Probably worth giving this printk a prefix at some point (doesn't matter for
this patchset though since you're just moving it around).
Rest of it looks good.
Jesse
^ permalink raw reply
* Re: [patch 5/6] PARISC: move PERR & SERR enables out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 18:30 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228173125.GA16270@colo.lackof.org>
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote:
> In general, I'm wondering if the check for device class would be
> sufficient here to NOT enable PERR/SERR for graphics automatically.
> While disabling PERR was "the right thing" for older "mostly write"
> devices of the 1990's and early 2000, it might not be correct for
> current 3-D graphics devices which use host mem to buffer processed
> results. I'm thinking of Intel graphics controllers in particular
> but I don't know any details of how they actually work.
Well, in general chipset devices aren't required to support parity checking,
AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0).
> I'm also a bit concerned about this now becuase (IIRC) AGP didn't
> implement parity though it looked like PCI protocol. PCI-e certainly
> does but it's possible BIOS/Firmware disable parity generation
> on the host bridge when connected to a gfx device.
> We wouldn't want to enable parity checking on a PCI-e gfx device in this
> case and I hope someone (perhaps at Intel) could double check this.
I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It
would be a bad idea to disable any PCIe error reporting (including legacy
error mapping) just because a gfx device was attached. Apparently the AMD
PCIe parts include PERR generation, so disabling upstream reporting at boot
time seems like it would be an outright bug; it should be left up to driver &
OS software.
Jesse
^ 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