* Re: [PATCH] gianfar mii needs to zero out the mii_bus structure
From: Jeff Garzik @ 2005-11-11 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0511091211030.26349-100000@gate.crashing.org>
applied
^ permalink raw reply
* Re: "Now booting the kernel"
From: drizzt @ 2005-11-11 12:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051111010005.016A868717@ozlabs.org>
Hi,
> I tried the stuff but I am still getting the same result.
This step can be quite hard to go over... do not deseparate :)
> I did not find the section "/* 2. Invalidate all entries except the
> entry we're executing in */" So I commented the TLBWE line in the
> section which says "invalidate all TLB entries " . Is it correct?
I think it is.
Do not forget to uncomment it when you start having outputs.
> The ASM code for rebooting will have to be changed for my board... right?
Yes
On my board, this is a feature of the VME bus, which you should'nt have,
so check for an instruction or register to perform a reset.
Have fun :) :)
Nathael.
^ permalink raw reply
* [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel
From: Benjamin Herrenschmidt @ 2005-11-11 10:15 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc64-dev, linuxppc-dev list, Steve Munroe, tom_gall@mac.com
This patch moves the vdso's to arch/powerpc, adds support for the 32
bits vdso to the 32 bits kernel, rename systemcfg (finally !), and adds
some new (still untested) routines to both vdso's: clock_gettime() with
support for CLOCK_REALTIME and CLOCK_MONOTONIC, clock_getres() (same
clocks) and get_tbfreq() for glibc to retreive the timebase frequency.
Tom,Steve: The implementation of get_tbfreq() I've done for 32 bits
returns a long long (r3, r4) not a long. This is such that if we ever
add support for >4Ghz timebases on ppc32, the userland interface won't
have to change.
I have tested gettimeofday() using some glibc patches in both ppc32 and
ppc64 kernels using 32 bits userland (I haven't had a chance to test a
64 bits userland yet, but the implementation didn't change and was
tested earlier). I haven't tested yet the new functions.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Due to the size of the patch, I haven't posted it to the lists, it's
available at http://gate.crashing.org/~benh/ppc64-vdso-update.diff
Ben.
^ permalink raw reply
* packet name created by rpmbuild
From: debora liu @ 2005-11-11 9:58 UTC (permalink / raw)
To: linuxppc-embedde
SGVsbG8gRGVueA0KDQpJJ20gdXNpbmcgcnBtYnVpbGQsIGJ1dCBpdCBjcmVhdCBycG0gcGFja2V0
IG5hbWUgaXMgIk5BTUUtcHBjXzh4eC1WRVJTSU9OLVJFTEVBU0UucHBjLnJwbSIsDQpJIHRoaW5r
IGl0IHNob3VsZCBpcyAiTkFNRS1WRVJTSU9OLVJFTEVBU0UucHBjLnJwbSIsIHRydWU/DQpJIHVz
ZSBuYXRpdmUgcnBtYnVpbGQgb24gbXkgYm9hcmQgd2l0aCBlbGRrLTMuMS4xIFBQQzh4eCBORlMg
cm9vdC4NCg0KoaGhoaGhoaGhoaGhoaGhoWRlYm9yYSBsaXUNCqGhoaGhoaGhoaGhoaGhoaFkZWJv
cmFsaEBzaW5vdmVlLmNvbQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTExLTExDQo=
^ permalink raw reply
* floating point operation of ppc
From: lily @ 2005-11-11 9:13 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
hi,all:
i build an embedded linux on powerpc 405ep,i need execute floating point operation,and i enable "math emulate" option in kernel, i run a while(1)loop ,in the loop there was floating point expression ,after test ,i found the while (1) exit because of the floating point computation,that is the floating point can't execute on ppc stablely.Is there someone meets the same problems ,please give me some suggestion,thanks!!!
lily
[-- Attachment #2: Type: text/html, Size: 1466 bytes --]
^ permalink raw reply
* Re: 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: Wolfgang Denk @ 2005-11-11 8:39 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051111020420.9644C1073@smtp.263.net>
In message <20051111020420.9644C1073@smtp.263.net> you wrote:
>
> With today's update, I can make the kernel by Yosemite_defconfig,
> but
> When boot my board with this new kernel, it halt at boot time, the
> attachment
> Is the boot message.
What you show is NOT the current code.
> U-Boot 1.1.3 (Sep 7 2005 - 09:03:02)
Please update U-Boot as well. You need this commit included:
commit f190c11b1f22ff766e046588e5a7bb55f28ae305
tree 1c41a7beffe8a293174dcb7c28b394349204a047
parent 4d03a21f2329bb13a9661a23742ac0b77a7a76d5
author Stefan Roese <sr@denx.de> Sat, 05 Nov 2005 15:50:16 +0100
committer Stefan Roese <sr@denx.de> Sat, 05 Nov 2005 15:50:16 +0100
Adjust bd->bi_flashstart on Yellowstone & Yosemite to correct size
Patch by Stefan Roese, 05 Nov 2005
I recommend to use the top-of-tree from the CVS or GIT repositories.
> Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #1 Fri Nov 11
> 09:51:04 CST 2005
This is not the current code base. You should use top-of-tree from
GIT repository (commit ff1df84b3c3154ffdb646941e1c70d17554e3042); the
kernel will display something like this:
Linux version 2.6.14-gff1df84b ...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Nail here --X-- for new monitor.
^ permalink raw reply
* 11-11-05 2.6.14 on AMCC Yosemite board(boot error)
From: KylongMu @ 2005-11-11 2:04 UTC (permalink / raw)
To: wd; +Cc: Linuxppc-embedded
In-Reply-To: <20051102164644.6D167353A2C@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
Dear Denk:
With today's update, I can make the kernel by Yosemite_defconfig,
but
When boot my board with this new kernel, it halt at boot time, the
attachment
Is the boot message.
Cordially,
Kylong Mu
[-- Attachment #2: bootmessage.txt --]
[-- Type: text/plain, Size: 5911 bytes --]
U-Boot 1.1.3 (Sep 7 2005 - 09:03:02)
IBM PowerPC 440 EP Rev. B
Board: AMCC YOSEMITE
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
PER: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: ppc_440x_eth0, ppc_440x_eth1
Hit any key to stop autoboot: 0
=> tftp 0x400000 uImage
Waiting for PHY auto negotiation to complete.. done
Using ppc_440x_eth0 device
TFTP from server 192.168.0.93; our IP address is 192.168.0.66
Filename 'uImage'.
Load address: 0x400000
Loading: #################################################################
#################################################################
#################################################################
##########################################
done
Bytes transferred = 1212626 (1280d2 hex)
=> bootm 0x400000 0xfed40000
## Booting image at 00400000 ...
Image Name: Linux-2.6.14
Created: 2005-11-11 1:51:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1212562 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fed40000 ...
Image Name: Yosemite Ramdisk
Created: 2005-08-30 2:13:49 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 17770706 Bytes = 16.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0ee9b000, end 0ff8d8d2 ... OK
Linux version 2.6.14 (root@dxp) (gcc version 4.0.0) #1 Fri Nov 11 09:51:04 CST 2005
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: ramdisk=49152 root=/dev/ram ip=192.168.1.62:::::eth0:off
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 239488k available (1852k kernel code, 604k data, 136k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
Freeing initrd memory: 17354k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
SCSI subsystem initialized
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
usbmon: debugfs is not available
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci.0: irq 40, io mem 0xef601000
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
pegasus: v0.6.12 (2005/01/13), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new driver pegasus
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:8f:aa
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:80:8f:aa
eth1: found Generic MII PHY (0x03)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdfff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C0157E9C SP: CFFA1EE0 REGS: c0270f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: cffa0000
Last syscall: 120
GPR00: 00000002 CFFA1EE0 CEE98B10 C022673C 00000000 00000000 CFFA1F18 00000000
GPR08: 00000002 00000002 00000002 00000001 000F1FFF 60000428 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: C01D0000 C01D0000 C0270000 00000000 C022673C CFFA1F18 00000000 C022673C
NIP [00000000] 0x0
LR [c0157e9c] mtd_do_chip_probe+0xdc/0x334
Call trace:
[c0157e9c] mtd_do_chip_probe+0xdc/0x334
[c0152214] cfi_probe+0x18/0x28
[c0152160] do_map_probe+0x40/0xdc
[c0265568] init_yosemite_flash+0xb4/0x110
[c00013ac] init+0xb4/0x254
[c00046c0] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdfff7ff
POB0: BEAR=0xc27e3194ffffffff BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C000235C SP: C0270E70 REGS: c0270f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: cffa0000
Last syscall: 120
GPR00: 08000000 C0270E70 CEE98B10 C0270E80 00001529 FFFFFFFF C0270000 00004000
GPR08: C0270000 C000235C 00021002 C00039E8 CEE98CD8 60000428 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: C01D0000 C01D0000 C0270000 00000000 C022673C CFFA1F18 00000007 C0270F50
NIP [00000000] 0x0
LR [c000235c] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Wolfgang Pfeiffer @ 2005-11-11 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1130999620.4680.28.camel@gaston>
Hi Ben
Thanks for your work, for the patches: on a Titanium IV a kernel-org
based, self-made (via "make-kpkg") 2.6.14.1 patched kernel works. USB
seems being fine here: I put the machine to sleep with a camera and a
Logitech mouse plugged in to USB connectors: After resuming the system
from sleep the mouse is still working, and the camera is usable and
fine. I'm running pbbuttons here.
It seems I have problems because of a - I still can't believe that -
missing pcmciautils package on Debian. But that's unrelated to what
we're discussing here, I believe. I'll start another thread perhaps for
this latter issue ...
On Thu, Nov 03, 2005 at 05:33:39PM +1100, Benjamin Herrenschmidt wrote:
> For those who experience crashes on sleep and/or wakeup (typically due
> to USB) with 2.6.14, I made a test patch that might help. Please let me
> know if it makes things more reliable.
>
> http://gate.crashing.org/~benh/fix-ohci-sleep.diff
[ ... ]
I didn't use the one above, but just the one you posted here Nov.8
(this thread), IINM:
$ patch -p1 < /home/shorty/downloads/ben-patches/benh.nov.8.sleep.diff
patching file drivers/usb/core/hcd-pci.c
patching file drivers/usb/core/hcd.c
patching file drivers/usb/core/hcd.h
patching file drivers/usb/host/ehci-hcd.c
patching file drivers/usb/host/ehci-q.c
patching file drivers/usb/host/ehci-sched.c
patching file drivers/usb/host/ohci-hcd.c
patching file drivers/usb/host/ohci-hub.c
patching file drivers/usb/host/ohci-pci.c
patching file drivers/usb/host/uhci-hcd.c
Following that, provided my .bash_history is well organised enough to
be trusted ( ... :) I applied the 2.6.14.1 patch
("patch-2.6.14.1.bz2")
So: As to sleep/USB: Everything seems being fine here on 2.6.14.1.
FYI:
Kismet still does not seem work for hermes/orinoco on 2.6.14.1.
Thanks again for the patches, Ben.
Best Regards
Wolfgang
--
Wolfgang Pfeiffer
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
Key fingerprint = A8CA 9D8C 54C4 4CC1 0B26 AA3C 9108 FB42 E303 7113
^ permalink raw reply
* 82xxHCI driver for MPC8280 Specifically
From: Russell McGuire @ 2005-11-10 21:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051110145136.3E4EC68715@ozlabs.org>
All,
I have been trying to get the 82xxHCI driver to work on our protoboard and
after a lot of correspondence with Freescale FAE's there are some real
differences in code implementation for some CPU parts.
Our board is using a MPC8280 Rev 0.1 part, the Rev number of course is the
last bit of the IMMR register. So 0xXXXX0A01 is our CPU, the 0A is all 8280
parts.
I was curious if anyone else has gotten this driver to operation
specifically on an 8280 CPU. Freescale says that ALL 8280's do NOT NEED any
microcode patch only some Rev's only need hardware workarounds to generate
the SOF packets, mainly wiring a BRG or TIMER to the DREQ1 / 4 lines at
least for Rev 0.0 and Rev 0.1. Rev A parts do not need this, as it is all
working internally, guess they finally fixed it.
This documentation is not conclusive as to how to wire and setup the DREQ
lines, and is no longer available on their websites, I have the PDF file
entitled MPC8280UMAD_D.pdf if anyone is curious about Rev 0.0 and Rev 0.1
parts.
So help, has anyone got this working with the Rev 0.0 and Rev 0.1 parts, and
if so, how? I have been spending way to much time reading and hacking code
to this barely functional. I would be happy to send anyone the code I have
currently, if they want to start in on this.
Russell McGuire
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
linuxppc-embedded-request@ozlabs.org
Sent: Thursday, November 10, 2005 6:52 AM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 15, Issue 21
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: [PATCH 2.6.14] mm: 8xx MM fix for (David Jander)
2. PowerPC reservations (Kalle Pokki)
3. Re: "Now booting the kernel" (Nathael PAJANI)
4. floating point + kernel (PPC) (srideep.devireddy@wipro.com)
5. SCC QMC driver for 8247 (Robin Mathew)
6. Re: "Now booting the kernel" (Nathael PAJANI)
7. Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update (Dominik Brodowski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Nov 2005 10:18:07 +0200
From: David Jander <david.jander@protonic.nl>
Subject: Re: [PATCH 2.6.14] mm: 8xx MM fix for
To: linuxppc-embedded@ozlabs.org
Message-ID: <200511100918.08060.david.jander@protonic.nl>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.
Sorry, I obviously did not mean this thread, but the following post on
another
thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html
Regards,
--
David Jander
------------------------------
Message: 2
Date: Thu, 10 Nov 2005 10:20:30 +0200
From: Kalle Pokki <kalle.pokki@iki.fi>
Subject: PowerPC reservations
To: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Message-ID: <437302CE.8070309@iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Can someone please help me understand how the memory reservations in
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive
scheduler, and take a text-book example of an atomic increment case,
which is also frequently used in e.g. the Linux kernel. With two atomic
operations, everything seems to be just fine. But how about with three
concurrent threads of execution?
From the following code, assume r3 contains the same address for each
incrementing operation. If the first atomic increment is pre-empted in
the middle, execution then jumps to the second increment (by the
scheduler). The second increment runs through and succeeds, and
continues straight to the third increment. Then it is again pre-empted
in the middle, execution returning to the first increment. Now the
processor has the reservation with the correct address, and the first
increment succeeds when still holding the original input value. The
first and the second increment thus write the same value in memory.
After the first increment, the scheduler again continues the third
increment, which doesn't succeed a first, but the second round succeeds.
However, the value in the address pointed by r3 was not increased by
three, but by two.
Am I just not getting how this is really supposed to work? Are there
still some other constructs in use to prevent this, e.g. extra stwcx.
instructions when changing the thread of execution?
I'm also wondering why the architecture specifically defines the stwcx.
instruction to have, well, undefined behavior in case the reservation
address differs from the address of the previous lwarx...
1: lwarx r6, r0, r3
addi r6, r6, 1
stwcx. r6, r0, r3
bne- 1b
.....
2: lwarx r7, r0, r3
addi r7, r7, 1
stwcx. r7, r0, r3
bne- 2b
3: lwarx r8, r0, r3
addi r8, r8, 1
stwcx. r8, r0, r3
bne- 3b
------------------------------
Message: 3
Date: Thu, 10 Nov 2005 11:40:14 +0100
From: Nathael PAJANI <nathael.pajani@cpe.fr>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded@ozlabs.org
Message-ID: <4373238E.8000405@cpe.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
(Sorry, I first replyed with the wrong mail address)
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
------------------------------
Message: 4
Date: Thu, 10 Nov 2005 18:07:31 +0530
From: <srideep.devireddy@wipro.com>
Subject: floating point + kernel (PPC)
To: <linuxppc-embedded@ozlabs.org>
Message-ID:
<6AD9F6A5F6E096408F0B703773355A07605C40@CHN-SNR-MBX01.wipro.com>
Content-Type: text/plain; charset="us-ascii"
Thanks for your help friends ...
I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)
10.0.0.2 login: root
Last login: Tnhu Jan 1 00:00sole
Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown
MontaVista(R) Linux(R) Professional Edition 3.1
root@10.0.0.2:~# <mailto:root@10.0.0.2:~>
root@10.0.0.2:/home# cd ..
root@10.0.0.2:/# ls
bin boot dev etc home lib mnt opt proc root sbin tmp usr
var
root@10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)
What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?
Best Regards
srideep
Confidentiality Notice
The information contained in this electronic message and any attachments to
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051110/30c43a42/
attachment-0001.htm
------------------------------
Message: 5
Date: Thu, 10 Nov 2005 20:18:48 +0530
From: Robin Mathew <robin@india.tejasnetworks.com>
Subject: SCC QMC driver for 8247
To: Linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Cc: Nicholas Basker <nbasker@india.tejasnetworks.com>
Message-ID: <43735DD0.9030205@india.tejasnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello:
We are working on implementing driver for SCC operating in QMC mode that
supports multiple HDLC channels. The details of the system we are using
are the following.
CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
FCC2 in 10/100 ethernet
SCC1 currently not used, but
proposed to be used in HDLC mode.
SCC3 is not used.
SCC4 operating in QMC mode
with super -channel capability. Trying to operate 192kbps HDLC channel
(using 3x64kbps QMC channels).
SMC2 in UART mode (as a
simple debug port without any modem signals).
SPI interface currently not
used but shall be used in future.
I2C is being used.
01. Can the channel specific parameters of the SCC4 in QMC mode be
relocated from DPRAM base address?? There is no mention in the
8272RM.pdf about configuring the base address of channel specific
parameters. From the QMC memory structure diagram, it looks like the
channel specific parameters will be taken from the the DPRAM base
address. Can you please confirm it?
02. We have changed the function m8260_cpm_dpalloc() used for DPRAM
allocation in the linux source code. It was allocating memory from
128Byte location to 8KByte location in DPRAM. But since QMC requires the
lower 4KByte for channel specific parameters, we changed the function to
allocate DPRAM from 4KByte location. Will this change lead to any
problem for proper linux operation?
03. We are encountering a strange problem with scc4 parameter RAM. When
the driver is coming up, its trying to initialize the SCC4 parameter RAM
for QMC. In the location (immr + 0x8318), we are writing the value
0x8320 but the value magically changes to 0x8300. We tried to write to
the location using BDI and again the problem is seen. Is this a known
problem with the processor?? This problem doesnot appear everytime. Is
there any known cause for this problem?
Regards,
Robin
------------------------------
Message: 6
Date: Thu, 10 Nov 2005 09:46:30 +0100
From: Nathael PAJANI <nathael.pajani@ecrin.com>
Subject: Re: "Now booting the kernel"
To: linuxppc-embedded@ozlabs.org
Message-ID: <437308E6.2070804@ecrin.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
------------------------------
Message: 7
Date: Thu, 10 Nov 2005 11:03:04 +0100
From: Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update
To: Paul Mackerras <paulus@samba.org>
Cc: linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Message-ID: <20051110100304.GA21855@dominikbrodowski.de>
Content-Type: text/plain; charset=us-ascii
Hi,
On Mon, Nov 07, 2005 at 12:03:45PM +1100, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > The following patch updates the MPC8xx PCMCIA driver:
>
> This and the following patch look OK as far as I can tell - Dominik,
> will you take care of sending them to Linus?
Yes, will do.
Thanks,
Dominik
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 15, Issue 21
*************************************************
^ permalink raw reply
* Re: "Now booting the kernel"
From: Nitesh Guinde @ 2005-11-10 18:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello Nathael,
I tried the stuff but I am still getting the same result.
I did not find the section "/* 2. Invalidate all entries except the
entry we're executing in */" So I commented the TLBWE line in the
section which says "invalidate all TLB entries " . Is it correct? The
ASM code for rebooting will have to be changed for my board... right?
Nitesh
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Kumar Gala @ 2005-11-10 17:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051110164404.GA7303@pb15.lixom.net>
On Nov 10, 2005, at 10:44 AM, Olof Johansson wrote:
> On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>>>
>>> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>
>> I don't think I'm adding much value handling ppc/ppc64 patches,
>> really.
>> I'd prefer to get out of that business.
>
> Main benefit for me, as a patch submitter, is that you consistently,
> always, ACK when you pick up or drop a patch. In other words, I don't
> have to go polling a tree to see if it made it in or not.
>
>> It would be better to have an arch maintainer who runs a git tree,
>> same as
>> ia64, arm, etc.
>>
>> And, given the amount of shared infrastructure, I suspect it would
>> have to
>> be a single git tree for both architectures.
>>
>> I'd still sweep up random ppc patches, but those will go into
>> mainline via the
>> originator->mm->git-powerpc->linus route.
>>
>> Possible?
>
> I'm fine with all that; to be honest I haven't been certain where the
> smaller ppc/ppc64 patches should go during this whole merge
> business (or
> after, for that matter).
>
> If Paulus wants to start an arch tree, that's fine with me. I do share
> Ben's opinion about less review though, I guess we'll just have to
> deal
> with that.
>
> Also, Paul, I kindly request some sort of ACK mechanism similar to
> Andrew's when patches are picked up. :-)
I agree with Olof's comments. Additionally, I think one reason we
had been sending things to Andrew for PPC32 embedded was that the sub-
arch maintainers (Matt, Marcelo, Tom, Dan, Sylvain, myself, etc..)
needed a responsive path to get things to Linus which Andrew was
providing. If Paul's going to be able to handle accepting and
dealing with all the embedded patches I'm fine with having a PPC git
tree. I'm even willing to setup some GIT tree's for sub-arch's I
deal with for Paul to pull from if he wants.
Just my two cents.
- kumar
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Olof Johansson @ 2005-11-10 16:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051109213837.47c8dce7.akpm@osdl.org>
On Wed, Nov 09, 2005 at 09:38:37PM -0800, Andrew Morton wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> I don't think I'm adding much value handling ppc/ppc64 patches, really.
> I'd prefer to get out of that business.
Main benefit for me, as a patch submitter, is that you consistently,
always, ACK when you pick up or drop a patch. In other words, I don't
have to go polling a tree to see if it made it in or not.
> It would be better to have an arch maintainer who runs a git tree, same as
> ia64, arm, etc.
>
> And, given the amount of shared infrastructure, I suspect it would have to
> be a single git tree for both architectures.
>
> I'd still sweep up random ppc patches, but those will go into mainline via the
> originator->mm->git-powerpc->linus route.
>
> Possible?
I'm fine with all that; to be honest I haven't been certain where the
smaller ppc/ppc64 patches should go during this whole merge business (or
after, for that matter).
If Paulus wants to start an arch tree, that's fine with me. I do share
Ben's opinion about less review though, I guess we'll just have to deal
with that.
Also, Paul, I kindly request some sort of ACK mechanism similar to
Andrew's when patches are picked up. :-)
Thanks,
-Olof
^ permalink raw reply
* [PATCH] ppc32: fix PQ2 PCI DMA interrupt handling
From: Kumar Gala @ 2005-11-10 16:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc-embedded
The bit position in the status register corresponding to the
PCI DMA interrupt was incorrect. Additionally, we did not
have a define for the PCI DMA interrupt.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 6a9fa9805be85c33a177061d6bf4f4c2a95c9c7e
tree 2a72692b7373d2f4d328aee3652ece9d9ff7e750
parent b23f8a20b85440d4bebf1a2ddea5830ca85ff655
author Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 10 Nov 2005 10:35:15 -0600
arch/ppc/syslib/cpm2_pic.c | 2 +-
include/asm-powerpc/irq.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
index c867be6..29d95d4 100644
--- a/arch/ppc/syslib/cpm2_pic.c
+++ b/arch/ppc/syslib/cpm2_pic.c
@@ -37,7 +37,7 @@ static u_char irq_to_siureg[] = {
static u_char irq_to_siubit[] = {
0, 15, 14, 13, 12, 11, 10, 9,
8, 7, 6, 5, 4, 3, 2, 1,
- 2, 1, 15, 14, 13, 12, 11, 10,
+ 2, 1, 0, 14, 13, 12, 11, 10,
9, 8, 7, 6, 5, 4, 3, 0,
31, 30, 29, 28, 27, 26, 25, 24,
23, 22, 21, 20, 19, 18, 17, 16,
diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
index b3935ea..921bfa9 100644
--- a/include/asm-powerpc/irq.h
+++ b/include/asm-powerpc/irq.h
@@ -389,6 +389,7 @@ extern u64 ppc64_interrupt_controller;
#define SIU_INT_TIMER4 ((uint)0x0f + CPM_IRQ_OFFSET)
#define SIU_INT_TMCNT ((uint)0x10 + CPM_IRQ_OFFSET)
#define SIU_INT_PIT ((uint)0x11 + CPM_IRQ_OFFSET)
+#define SIU_INT_PCI ((uint)0x12 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ2 ((uint)0x14 + CPM_IRQ_OFFSET)
#define SIU_INT_IRQ3 ((uint)0x15 + CPM_IRQ_OFFSET)
^ permalink raw reply related
* Re: PowerPC reservations
From: Michael R. Zucca @ 2005-11-10 15:20 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <437302CE.8070309@iki.fi>
Kalle Pokki wrote:
> Am I just not getting how this is really supposed to work? Are there
> still some other constructs in use to prevent this, e.g. extra stwcx.
> instructions when changing the thread of execution?
Yes. When a context switch occurs, there's a stcwx. to clear any
reservations from the previous thread. When you enter another thread
from a context switch, you enter it with no reservations pending.
So you might have something that looks like this:
thread 1 -> lwarx w/ successful reservation
context switch -> stwcx.. to garbage location to clear any reservations
thread 2 -> stwcx. fails since there's no reservation pending
context switch -> stwcx. to garbage location to clear any reservations
thread 1 -> stwcx. fails since there's no reservation pending
thread 1 -> loops to try lwarx again
So the context switcher protects a reservation from "leaking" into
another thread. In that sense, you can act as though lwarx/stwcx. pairs
belong to a single thread.
The other important thing to remember is that there can only be one
outstanding reservation. Thus, lwarx and stcwx. instructions have to be
"paired" or you're going to get unexpected results.
^ permalink raw reply
* SCC QMC driver for 8247
From: Robin Mathew @ 2005-11-10 14:48 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: Nicholas Basker
Hello:
We are working on implementing driver for SCC operating in QMC mode that
supports multiple HDLC channels. The details of the system we are using
are the following.
CPU Version = 8247 based on 82xx family of processor(PVR 80822014)
The Linux OS Version = DENKS Linux version 2.4.20.
The Peripherals used are = FCC1 in 10/100 ethernet
FCC2 in 10/100 ethernet
SCC1 currently not used, but
proposed to be used in HDLC mode.
SCC3 is not used.
SCC4 operating in QMC mode
with super -channel capability. Trying to operate 192kbps HDLC channel
(using 3x64kbps QMC channels).
SMC2 in UART mode (as a
simple debug port without any modem signals).
SPI interface currently not
used but shall be used in future.
I2C is being used.
01. Can the channel specific parameters of the SCC4 in QMC mode be
relocated from DPRAM base address?? There is no mention in the
8272RM.pdf about configuring the base address of channel specific
parameters. From the QMC memory structure diagram, it looks like the
channel specific parameters will be taken from the the DPRAM base
address. Can you please confirm it?
02. We have changed the function m8260_cpm_dpalloc() used for DPRAM
allocation in the linux source code. It was allocating memory from
128Byte location to 8KByte location in DPRAM. But since QMC requires the
lower 4KByte for channel specific parameters, we changed the function to
allocate DPRAM from 4KByte location. Will this change lead to any
problem for proper linux operation?
03. We are encountering a strange problem with scc4 parameter RAM. When
the driver is coming up, its trying to initialize the SCC4 parameter RAM
for QMC. In the location (immr + 0x8318), we are writing the value
0x8320 but the value magically changes to 0x8300. We tried to write to
the location using BDI and again the problem is seen. Is this a known
problem with the processor?? This problem doesnot appear everytime. Is
there any known cause for this problem?
Regards,
Robin
^ permalink raw reply
* floating point + kernel (PPC)
From: srideep.devireddy @ 2005-11-10 12:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
Thanks for your help friends ...
I am able to bring my kernel up ...... right now I have a problem
after some time at the console .... I get floating point used in kernel
(task=C0188480,pc=1100)
10.0.0.2 login: root
Last login: Tnhu Jan 1 00:00sole
Linux 10.0.0.2 2.4.22 #1 Tue Nov 8 12:03:26 UTC 2005 ppc unknown
MontaVista(R) Linux(R) Professional Edition 3.1
root@10.0.0.2:~# <mailto:root@10.0.0.2:~>
root@10.0.0.2:/home# cd ..
root@10.0.0.2:/# ls
bin boot dev etc home lib mnt opt proc root sbin tmp usr
var
root@10.0.0.2:/# floating point used in kernel (task=c0188480, pc=1100)
What does this mean ...? This makes the console hang .....Can any 1 help
me on in this?
Best Regards
srideep
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 7550 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32 8xx: MPC8xx PCMCIA update
From: Dominik Brodowski @ 2005-11-10 10:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17262.42993.975296.653728@cargo.ozlabs.ibm.com>
Hi,
On Mon, Nov 07, 2005 at 12:03:45PM +1100, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > The following patch updates the MPC8xx PCMCIA driver:
>
> This and the following patch look OK as far as I can tell - Dominik,
> will you take care of sending them to Linus?
Yes, will do.
Thanks,
Dominik
^ permalink raw reply
* Re: "Now booting the kernel"
From: Nathael PAJANI @ 2005-11-10 10:40 UTC (permalink / raw)
To: linuxppc-embedded
(Sorry, I first replyed with the wrong mail address)
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
^ permalink raw reply
* Re: "Now booting the kernel"
From: Nathael PAJANI @ 2005-11-10 8:46 UTC (permalink / raw)
To: linuxppc-embedded
>Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
>Uncompressing Linux...done.
>Now booting the kernel
Hi!
At this state the bootloader stops executing and the Linux Kernel
starts. The problem is that the Linux kernel does not know yet how to
use the serial.
You won't have any message before it is set up (in early-console if my
memory is allright)
So what you can do to check what's going on, is put "breakpoints" in the
boot sequence. This means in the file arch/ppc/kernel/head*.S used for
your board you should try to comment the line with the "tlbwe"
instruction in the section "/* 2. Invalidate all entries except the
entry we're executing in */"
This will allow you to keep access to your board registers.
Then you go step by step, putting some code which will reboot the board
when executed, so you know you're going up to that point, and then move
the "breakpoint" further.
This code does the reboot (for the booke I can reboot the board by
writting '4' at address 0xfa001001):
ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync
C:
*((volatile unsigned char*)0xfa001001 = 4;
This way, instead of hanging up, the board reboots and you know where
you are.
If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific,
once again, check that the ones used (compiled) are those you need.
And next you've got the "start_kernel" call, which leads you to C code
definitely. It's in init/main.c.
I hope I did not tell anything wrong, and that this will help.
Have fun.
Nathael.
^ permalink raw reply
* PowerPC reservations
From: Kalle Pokki @ 2005-11-10 8:20 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Can someone please help me understand how the memory reservations in
PowerPC actually work. Let's just assume uniprocessor with a pre-emptive
scheduler, and take a text-book example of an atomic increment case,
which is also frequently used in e.g. the Linux kernel. With two atomic
operations, everything seems to be just fine. But how about with three
concurrent threads of execution?
From the following code, assume r3 contains the same address for each
incrementing operation. If the first atomic increment is pre-empted in
the middle, execution then jumps to the second increment (by the
scheduler). The second increment runs through and succeeds, and
continues straight to the third increment. Then it is again pre-empted
in the middle, execution returning to the first increment. Now the
processor has the reservation with the correct address, and the first
increment succeeds when still holding the original input value. The
first and the second increment thus write the same value in memory.
After the first increment, the scheduler again continues the third
increment, which doesn't succeed a first, but the second round succeeds.
However, the value in the address pointed by r3 was not increased by
three, but by two.
Am I just not getting how this is really supposed to work? Are there
still some other constructs in use to prevent this, e.g. extra stwcx.
instructions when changing the thread of execution?
I'm also wondering why the architecture specifically defines the stwcx.
instruction to have, well, undefined behavior in case the reservation
address differs from the address of the previous lwarx...
1: lwarx r6, r0, r3
addi r6, r6, 1
stwcx. r6, r0, r3
bne- 1b
.....
2: lwarx r7, r0, r3
addi r7, r7, 1
stwcx. r7, r0, r3
bne- 2b
3: lwarx r8, r0, r3
addi r8, r8, 1
stwcx. r8, r0, r3
bne- 3b
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: David Jander @ 2005-11-10 8:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200511100848.46263.david.jander@protonic.nl>
On Thursday 10 November 2005 08:48, David Jander wrote:
>[...]
> Hmmm. This is a lot in the line of the tests I did with (the more generic
> benchmark) nbench. After looking at those results (see my other post in
> this thread) I already suspected something like this.
Sorry, I obviously did not mean this thread, but the following post on another
thread:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-November/020775.html
Regards,
--
David Jander
^ permalink raw reply
* [PATCH] 2.6: PRTPPC board-support was: Re: about MPC 8XX SPI Driver
From: David Jander @ 2005-11-10 8:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 徐小威的EMAIL
In-Reply-To: <1131605445.4691.4.camel@banana>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
On Thursday 10 November 2005 07:50, 徐小威的EMAIL wrote:
> Anybody know where can found 'CPM SPI Driver' for MPC852T.I found a
> cpm_spi.c at /arch/ppc/8260_io directory in Linux 2.4.25.But I don't
> know how to program application to
> handle this driver.
Do you want it for 2.4 or 2.6? (I have both running on a mpc852T).
Here's a patch for 2.6.14 (denx-git tree).
Sorry to send you the complete patch for prtppc board support, but the spi
driver makes up most part of it, so it wouldn't be much smaller anyway ;-)
Regards,
--
David Jander
Protonic Holland.
[-- Attachment #2: linux-2.6.14-20051107-prt.patch --]
[-- Type: text/x-diff, Size: 33276 bytes --]
diff --git a/arch/ppc/8xx_io/Kconfig b/arch/ppc/8xx_io/Kconfig
--- a/arch/ppc/8xx_io/Kconfig
+++ b/arch/ppc/8xx_io/Kconfig
@@ -77,6 +77,14 @@ config ENET_BIG_BUFFERS
config HTDMSOUND
bool "Embedded Planet HIOX Audio"
depends on SOUND=y
+
+config CPM_SPI
+ bool "Simple CPM SPI driver"
+
+config CPM_SPI_BDSIZE
+ int "Size of Rx/Tx Buffer for SPI"
+ depends on CPM_SPI
+ default "16"
# This doesn't really belong here, but it is convenient to ask
# 8xx specific questions.
diff --git a/arch/ppc/8xx_io/Makefile b/arch/ppc/8xx_io/Makefile
--- a/arch/ppc/8xx_io/Makefile
+++ b/arch/ppc/8xx_io/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_FEC_ENET) += fec.o
obj-$(CONFIG_SCC_ENET) += enet.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
obj-$(CONFIG_HTDMSOUND) += cs4218_tdm.o
+obj-$(CONFIG_CPM_SPI) += cpm_spi.o
diff --git a/arch/ppc/8xx_io/cpm_spi.c b/arch/ppc/8xx_io/cpm_spi.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/8xx_io/cpm_spi.c
@@ -0,0 +1,448 @@
+/*
+ * Simple CPM SPI interface for the MPC 8xx.
+ *
+ * Copyright (c) 2002 Wolfgang Grandegger (wg@denx.de)
+ *
+ * This interface is partially derived from code copyrighted
+ * by Navin Boppuri (nboppuri@trinetcommunication.co) and
+ * Prashant Patel (pmpatel@trinetcommunication.com).
+ *
+ * This driver implements the function "cpm_spi_io()" to be
+ * used by other drivers and a simple read/write interface
+ * for user-land applications. The latter is mainly useful
+ * for debugging purposes. Some further remarks:
+ *
+ * - Board specific definitions and code should go into
+ * the file "cpm_spi.h".
+ *
+ * - For the moment, no interrupts are used. This be useful
+ * for (very) long transfers.
+ *
+ * Ported back from 2.4.25/mpc82xx to 2.6.14/mpc8xx by
+ * David Jander (david@protonic.nl)
+ *
+ */
+
+#ifndef EXPORT_SYMTAB
+# define EXPORT_SYMTAB /* need this one 'cause we export symbols */
+#endif
+
+#include <linux/config.h>
+#include <linux/module.h>
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/fs.h>
+#include <linux/errno.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/proc_fs.h>
+#include <linux/device.h>
+#include <asm/page.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+#include <asm/8xx_immap.h>
+#include <asm/mpc8xx.h>
+
+#include <asm/commproc.h>
+#include <asm/cpm_spi.h>
+
+#define DRIVER_NAME "cmp_spi"
+
+MODULE_AUTHOR("Wolfgang Grandegger (wg@denx.de)");
+MODULE_DESCRIPTION("Simple Driver for the CPM SPI");
+
+#undef DEBUG
+#ifdef DEBUG
+# define debugk(fmt,args...) printk(fmt ,##args)
+#else
+# define debugk(fmt,args...)
+#endif
+
+#if defined(CONFIG_SCC2_ENET) && !defined(CONFIG_UCODE_PATCH)
+#error "I2C/SPI Microcode Patch is needed, please enable it!"
+#endif
+
+#define CPM_SPI_MAJOR 65 /* "borrowed" from "plink" driver */
+
+extern void invalidate_dcache_range(unsigned long start, unsigned long end);
+
+static volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+
+static unsigned int dp_addr;
+static ushort r_tbase, r_rbase;
+static cbd_t *tx_bdf, *rx_bdf;
+static u_char *tx_buf, *rx_buf;
+
+#if CPM_SPI_SWAP_BYTES
+static void swap_bytes(u_char *buf, int len)
+{
+ u_short *sbuf = (u_short *)buf;
+ while (len > 0) {
+ *sbuf = cpu_to_le16(*sbuf);
+ sbuf++;
+ len -= 2;
+ }
+}
+#else
+#define swap_bytes(buf, len)
+#endif
+
+/*
+ * CPM SPI Kernel API function(s)
+ */
+ssize_t cpm_spi_io (int chip_id, int serial,
+ u_char *tx_buffer, int tx_size,
+ u_char *rx_buffer, int rx_size)
+{
+ unsigned long flags;
+ int i;
+
+ /*
+ * Serialize access to the SPI. We have to disable interrupts
+ * because we may need to call it from interrupt handlers.
+ */
+ local_irq_save(flags); local_irq_disable();
+
+ rx_bdf->cbd_datlen = 0;
+ if (serial)
+ tx_bdf->cbd_datlen = tx_size + rx_size;
+ else
+ tx_bdf->cbd_datlen = tx_size > rx_size ? tx_size : rx_size;
+ if (tx_bdf->cbd_datlen > CONFIG_CPM_SPI_BDSIZE) {
+ printk("cpm_spi_io: Invalid size\n");
+ local_irq_restore(flags);
+ return -EINVAL;
+ }
+ if (tx_size > 0) {
+ memcpy(tx_buf, tx_buffer, tx_size);
+#ifdef DEBUG
+ printk("Tx:");
+ for (i = 0; i < tx_size; i++)
+ printk(" %02x", tx_buf[i]);
+ printk("\n");
+#endif
+ swap_bytes(tx_buf, tx_size);
+ }
+
+ flush_dcache_range((unsigned long) tx_buf,
+ (unsigned long) (tx_buf+CONFIG_CPM_SPI_BDSIZE-1));
+ flush_dcache_range((unsigned long) rx_buf,
+ (unsigned long) (rx_buf+CONFIG_CPM_SPI_BDSIZE-1));
+ invalidate_dcache_range((unsigned long) rx_buf,
+ (unsigned long) (rx_buf+
+ CONFIG_CPM_SPI_BDSIZE-1));
+
+ /* Setting Rx and Tx BD status and data length */
+ tx_bdf->cbd_sc = BD_SC_READY | BD_SC_LAST | BD_SC_WRAP;
+ rx_bdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP;
+
+ /* Chip select for device */
+ cpm_spi_set_cs(immap, chip_id, 1);
+
+ /* Start SPI Tx/Rx transfer */
+ cpmp->cp_spcom |= 0x80;
+
+ /*
+ * Wait until the Tx/Rx transfer is done.
+ */
+ for (i = 0; i < CPM_SPI_POLL_RETRIES; i++) {
+ udelay(1);
+ if ((tx_bdf->cbd_sc & BD_SC_EMPTY) == 0 &&
+ (rx_bdf->cbd_sc & BD_SC_EMPTY) == 0)
+ break;
+ }
+
+ /* De-select device */
+ cpm_spi_set_cs(immap, chip_id, 0);
+
+ /* Check for timeout */
+ if (i == CPM_SPI_POLL_RETRIES) {
+ printk("cpm_spi_io: Tx/Rx transfer timeout\n");
+ local_irq_restore(flags);
+ return -EIO;
+ }
+
+#ifdef DEBUG
+ printk("Transfer time approx. %d us\n", i);
+ if (rx_bdf->cbd_datlen > 0) {
+ printk("Rx:");
+ for (i = 0; i < rx_bdf->cbd_datlen; i++)
+ printk(" %02x", rx_buf[i]);
+ printk("\n");
+ }
+#endif
+
+ /* Copy receive data if appropriate */
+ i = rx_bdf->cbd_datlen;
+#ifdef DEBUG
+ if (i != tx_bdf->cbd_datlen)
+ {
+ printk("i=%d tx_size=%d rx_size=%d\n", i, tx_size, rx_size);
+ }
+#endif
+ if (i > tx_bdf->cbd_datlen)
+ {
+ local_irq_restore(flags);
+ return -EIO;
+ }
+ swap_bytes(rx_buf, i);
+ if (rx_size > 0) {
+ if (serial) {
+ i -= tx_size;
+ memcpy(rx_buffer, rx_buf + tx_size, i);
+ } else {
+ memcpy(rx_buffer, rx_buf, i);
+ }
+ }
+
+ local_irq_restore(flags);
+
+ return i;
+}
+
+EXPORT_SYMBOL(cpm_spi_io);
+
+/*
+ * Prototypes for driver entry functions.
+ */
+static int
+cpm_spi_open(struct inode *inode, struct file *filp);
+static int
+cpm_spi_release(struct inode *inode, struct file *filp);
+static ssize_t
+cpm_spi_read(struct file *filp, char *buf, size_t count, loff_t *f_pos);
+static ssize_t
+cpm_spi_write(struct file *filp, const char *buf, size_t count, loff_t *f_pos);
+static int
+cpm_spi_init(void);
+static void
+cpm_spi_cleanup(void);
+
+/*
+ * File operations supported by this driver.
+ */
+struct file_operations cpm_spi_fops = {
+ owner: THIS_MODULE,
+ open: cpm_spi_open,
+ release: cpm_spi_release,
+ read: cpm_spi_read,
+ write: cpm_spi_write,
+};
+
+
+static int
+cpm_spi_open (struct inode *inode, struct file *filp)
+{
+ int minor = MINOR(inode->i_rdev);
+
+ if (minor >= CPM_SPI_MAX_CHIPS)
+ return -ENODEV;
+
+ filp->private_data = (void *)minor;
+ // MOD_INC_USE_COUNT;
+ return 0;
+}
+
+static int
+cpm_spi_release(struct inode *inode, struct file *filp)
+{
+ // MOD_DEC_USE_COUNT;
+ return 0;
+}
+
+static ssize_t
+cpm_spi_read(struct file *filp, char *buf, size_t count, loff_t *f_pos)
+{
+ u_char tx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+ u_char rx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+ int chip_id = (int)filp->private_data;
+ ssize_t size;
+
+ debugk("cpm_spi_read: count=%d, chip_id=%d\n", count, chip_id);
+
+ if (count > CONFIG_CPM_SPI_BDSIZE)
+ return -ENXIO;
+
+ if (copy_from_user(tx_kbuf, buf, count))
+ return -EFAULT;
+
+ size = cpm_spi_io(chip_id, 0, tx_kbuf, count, rx_kbuf, count);
+ if (size < 0)
+ return size;
+
+ if (copy_to_user(buf, rx_kbuf, size))
+ return -EFAULT;
+
+ return size;
+}
+
+static ssize_t
+cpm_spi_write(struct file *filp, const char *buf, size_t count, loff_t *f_pos)
+{
+ int chip_id = (int)filp->private_data;
+ u_char tx_kbuf[CONFIG_CPM_SPI_BDSIZE];
+
+ if (count > CONFIG_CPM_SPI_BDSIZE)
+ return -ENXIO;
+
+ if (copy_from_user(tx_kbuf, buf, count))
+ return -EFAULT;
+
+ return cpm_spi_io(chip_id, 0, tx_kbuf, count, NULL, 0);
+}
+
+/* Tx and Rx buffers are so small, we don't need to worry about
+ * consistent alloc. Just make them static here (ugly, but simple).
+ */
+static unsigned char txbufspace[CONFIG_CPM_SPI_BDSIZE];
+static unsigned char rxbufspace[CONFIG_CPM_SPI_BDSIZE];
+
+static int
+cpm_spi_init(void)
+{
+ int err = 0;
+ volatile spi_t *spi;
+
+
+ printk (KERN_INFO "CPM SPI Driver: $Revision: 1.1 $ wg@denx.de\n");
+
+ /* Global pointer to internal registers */
+ immap = (immap_t *)IMAP_ADDR;
+
+ spi = (spi_t *)&cpmp->cp_dparam[PROFF_SPI];
+
+#ifdef USE_IIC_PATCH
+ /* Check for and use a microcode relocation patch. */
+ if (spi->spi_rpbase)
+ spi = (spi_t *)&cpmp->cp_dpmem[spi->spi_rpbase];
+ printk("cpm_spi: using microcode patch (spi_rpbase=0x%p)\n", spi);
+#endif
+
+ /*
+ * Initialize the parameter RAM. We need to make sure
+ * many things are initialized to zero, especially in
+ * the case of a microcode patch.
+ */
+ spi->spi_rdp = 0;
+ spi->spi_rbptr = 0;
+ spi->spi_rbc = 0;
+ spi->spi_rxtmp = 0;
+ spi->spi_tstate = 0;
+ spi->spi_tdp = 0;
+ spi->spi_tbptr = 0;
+ spi->spi_tbc = 0;
+ spi->spi_txtmp = 0;
+
+ /*
+ * Allocate space for one transmit and one receive buffer
+ * descriptor in the DP RAM.
+ */
+ dp_addr = cpm_dpalloc(sizeof(cbd_t) * 2,0);
+ if (dp_addr == CPM_DP_NOSPACE) {
+ printk("cpm_spi: m8xx_cpm_dpalloc() failed\n");
+ return -ENOMEM;
+ }
+
+ /*
+ * Set up the IIC parameters in the parameter RAM.
+ */
+ spi->spi_rbase = r_rbase = dp_addr;
+ spi->spi_tbase = r_tbase = dp_addr + sizeof(cbd_t);
+
+ /*
+ * Setting transmit and receive buffer descriptor pointers
+ * intially to rbase and rbase.
+ */
+ spi->spi_rbptr = spi->spi_rbase;
+ spi->spi_tbptr = spi->spi_tbase;
+
+ /* Setting CPCR */
+ while(cpmp->cp_cpcr & CPM_CR_FLG) ;
+ cpmp->cp_cpcr |=
+ mk_cr_cmd(CPM_CR_CH_SPI, CPM_CR_INIT_TRX) | CPM_CR_FLG;
+ udelay(1);
+ while(cpmp->cp_cpcr & CPM_CR_FLG) ;
+
+ /* Sets the SDMA configuration register. */
+ immap->im_siu_conf.sc_sdcr = 0x0001;
+
+ /* Set to big endian. */
+ spi->spi_tfcr = SMC_EB;
+ spi->spi_rfcr = SMC_EB;
+
+ /* Set maximum receive size. */
+ spi->spi_mrblr = CONFIG_CPM_SPI_BDSIZE;
+
+ /*
+ * Clear all pending SPI events and mask all possible SPI
+ * interrupts. For the moment we don't use interrupts.
+ */
+ cpmp->cp_spie = 0xff;
+ cpmp->cp_spim = 0x00;
+
+ /*
+ * Set SPI Mode register.
+ * Note: the board-specific definitions are in cpm_spi.h.
+ */
+ cpmp->cp_spmode = CPM_SPI_SPMODE | SPMODE_EN;
+
+ /*
+ * Initiliaze port pins for SPI
+ * par dir odr
+ * PB28 -> SPIMISO: 1 1 0
+ * PB29 -> SPIMOSI: 1 1 0
+ * PB30 -> SPICLK : 1 1 0
+ */
+ cpmp->cp_pbpar |= 0x000e;
+ cpmp->cp_pbdir |= 0x000e;
+ cpmp->cp_pbodr &= ~(0x000e);
+
+ /*
+ * Initialize board-specific port for chip select etc.
+ * Note: the board-specific definitions are in cpm_spi.h.
+ */
+ cpm_spi_init_ports(immap);
+
+ /* Tx and Rx buffer descriptors. */
+ tx_bdf = (cbd_t *)&cpmp->cp_dpmem[r_tbase];
+ rx_bdf = (cbd_t *)&cpmp->cp_dpmem[r_rbase];
+
+ /* Initialize Tx and Tx BD's */
+ rx_bdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP;
+ tx_bdf->cbd_sc = BD_SC_LAST | BD_SC_WRAP;
+
+ /* Allocate memory for Rx and Tx buffers */
+ tx_buf = (u_char *)txbufspace;
+ rx_buf = (u_char *)rxbufspace;
+ debugk("rxbuf = 0x%p tx_buf = 0x%p\n", rx_buf, tx_buf);
+
+ /* Set the bd's rx and tx buffer address pointers */
+ tx_bdf->cbd_bufaddr = virt_to_bus(tx_buf);
+ rx_bdf->cbd_bufaddr = virt_to_bus(rx_buf);
+ debugk("pa:rxbuf = 0x%p pa:tx_buf = 0x%p\n", rx_bdf->cbd_bufaddr, tx_bdf->cbd_bufaddr);
+
+ /*
+ * Finally register the driver.
+ */
+ err = register_chrdev(CPM_SPI_MAJOR, DRIVER_NAME, &cpm_spi_fops);
+ if (err < 0) {
+ printk("cpm_spi: Couldn't register driver (major=%d)\n",
+ CPM_SPI_MAJOR);
+ return err;
+ }
+
+ return 0;
+}
+
+static void
+cpm_spi_cleanup(void)
+{
+ unregister_chrdev(CPM_SPI_MAJOR, DRIVER_NAME);
+ cpm_dpfree(dp_addr);
+}
+
+module_init(cpm_spi_init);
+module_exit(cpm_spi_cleanup);
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -504,6 +504,13 @@ config WINCEPT
MPC821 PowerPC, introduced in 1998 and designed to be used in
thin-client machines. Say Y to support it directly.
+config PRTPPC
+ bool "PRTPPC"
+ help
+ PRTPPC is a single-board computer module based on a Freescale MPC852T
+ embedded processor. It is used in different products designed and
+ manufactured by Protonic Holland.
+
endchoice
choice
@@ -954,6 +961,16 @@ config NR_CPUS
config HIGHMEM
bool "High memory support"
+config PRT_IOADDR
+ hex "PRTPPC IO-address space start"
+ depends on PRTPPC
+ default "0xf8100000"
+
+config PRT_IOSIZE
+ hex "PRTPPC IO-address space size"
+ depends on PRTPPC
+ default "0x00040000"
+
source kernel/Kconfig.hz
source kernel/Kconfig.preempt
source "mm/Kconfig"
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
obj-$(CONFIG_LITE5200) += lite5200.o
obj-$(CONFIG_EV64360) += ev64360.o
+obj-$(CONFIG_PRTPPC) += prtppc_setup.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_PMAC) += pmac_smp.o
diff --git a/arch/ppc/platforms/prtppc.h b/arch/ppc/platforms/prtppc.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc.h
@@ -0,0 +1,40 @@
+/*
+ * PRTPPC board definitions, loosely based on:
+ * TQM8xx(L/M) board specific definitions
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __PRTPPC_H__
+#define __PRTPPC_H__
+
+#include <linux/config.h>
+
+#include <asm/ppcboot.h>
+
+#define BOARD_CHIP_NAME "MPC86X"
+
+#define PRTPPC_IMMR_BASE 0xF8000000 /* phys. addr of IMMR */
+#define PRTPPC_IMAP_SIZE (64 * 1024) /* size of mapped area */
+
+#define IMAP_ADDR PRTPPC_IMMR_BASE /* physical base address of IMMR area */
+#define IMAP_SIZE PRTPPC_IMAP_SIZE /* mapped size of IMMR area */
+
+/* define IO_BASE for External bus devices */
+#define _IO_BASE CONFIG_PRT_IOADDR
+#define _IO_BASE_SIZE CONFIG_PRT_IOSIZE
+
+#define FEC_INTERRUPT 9 /* = SIU_LEVEL4 */
+
+/* We don't use the 8259.
+*/
+#define NR_8259_INTS 0
+
+#endif /* __PRTPPC_H__ */
diff --git a/arch/ppc/platforms/prtppc_serial.h b/arch/ppc/platforms/prtppc_serial.h
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc_serial.h
@@ -0,0 +1,100 @@
+/*
+ * include/asm-ppc/prtppc_serial.h
+ *
+ * Definitions for Protonic PRTPPC board multi-uart interface
+ * Usable for PRTACM and MSAMPS doughterboards.
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __PRTPPC_SERIAL_H
+#define __PRTPPC_SERIAL_H
+
+#include <linux/config.h>
+
+/* Make room for 3 mpc8xx SCM devices at minor 64,65 and 66 */
+// #define SERIAL_DEV_OFFSET 3
+
+#if !defined(CONFIG_PRT_UARTADDR)
+#define CONFIG_PRT_UARTADDR _IO_BASE
+#endif
+
+/* Define the UART base addresses and IRQs */
+#define PRTPPC_UART0_BASE (CONFIG_PRT_UARTADDR)
+#define PRTPPC_UART1_BASE (CONFIG_PRT_UARTADDR + 8)
+#define PRTPPC_UART2_BASE (CONFIG_PRT_UARTADDR + 16)
+#define PRTPPC_UART3_BASE (CONFIG_PRT_UARTADDR + 24)
+#define PRTPPC_UART4_BASE (CONFIG_PRT_UARTADDR + 32)
+#define PRTPPC_UART5_BASE (CONFIG_PRT_UARTADDR + 40)
+#define PRTPPC_UART6_BASE (CONFIG_PRT_UARTADDR + 48)
+#define PRTPPC_UART7_BASE (CONFIG_PRT_UARTADDR + 56)
+
+/* On PRTACM there are 2 16C554 quad uart chips, with INTx outputs
+ * Negted and OR'd together 4 on 1.
+ * Chip one goes to IRQ1, Chip two to IRQ2
+ */
+#define PRTPPC_UART0_IRQ SIU_IRQ1
+#define PRTPPC_UART1_IRQ SIU_IRQ1
+#define PRTPPC_UART2_IRQ SIU_IRQ1
+#define PRTPPC_UART3_IRQ SIU_IRQ1
+#define PRTPPC_UART4_IRQ SIU_IRQ2
+#define PRTPPC_UART5_IRQ SIU_IRQ2
+#define PRTPPC_UART6_IRQ SIU_IRQ2
+#define PRTPPC_UART7_IRQ SIU_IRQ2
+
+
+#ifdef CONFIG_SERIAL_MANY_PORTS
+#define RS_TABLE_SIZE 16
+#else
+#define RS_TABLE_SIZE 8
+#endif
+
+/* Rate for the 1.8432 Mhz clock for the onboard serial chip */
+#define BASE_BAUD ( 1843200 / 16 )
+
+/* AUTO_IRQ is scary, but maybe it even works :-) */
+#ifdef CONFIG_SERIAL_DETECT_IRQ
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST|ASYNC_AUTO_IRQ)
+#else
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF|ASYNC_SKIP_TEST)
+#endif
+
+/* Define a prototype UART entry.... */
+#define STD_SERIAL_PORT_ITEM(num) \
+ { 0, BASE_BAUD, PRTPPC_UART##num##_BASE, \
+ PRTPPC_UART##num##_IRQ, \
+ STD_COM_FLAGS, \
+ iomem_base: (u8 *)PRTPPC_UART##num##_BASE, \
+ iomem_reg_shift: 0, \
+ io_type: SERIAL_IO_MEM }
+
+/* Make a table from it */
+#if (CONFIG_SERIAL_8250_NR_UARTS > 4)
+#define STD_SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_ITEM(0), \
+ STD_SERIAL_PORT_ITEM(1), \
+ STD_SERIAL_PORT_ITEM(2), \
+ STD_SERIAL_PORT_ITEM(3), \
+ STD_SERIAL_PORT_ITEM(4), \
+ STD_SERIAL_PORT_ITEM(5), \
+ STD_SERIAL_PORT_ITEM(6), \
+ STD_SERIAL_PORT_ITEM(7)
+#else
+#define STD_SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_ITEM(0), \
+ STD_SERIAL_PORT_ITEM(1), \
+ STD_SERIAL_PORT_ITEM(2), \
+ STD_SERIAL_PORT_ITEM(3)
+#endif /* CONFIG_SERIAL_8250_NR_UARTS */
+
+#define SERIAL_PORT_DFNS \
+ STD_SERIAL_PORT_DFNS
+
+#endif /* __PRTPPC_SERIAL_H */
diff --git a/arch/ppc/platforms/prtppc_setup.c b/arch/ppc/platforms/prtppc_setup.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/platforms/prtppc_setup.c
@@ -0,0 +1,88 @@
+/*
+ * arch/ppc/platforms/prtppc_setup.c
+ *
+ * PRTPPC platform support
+ *
+ * Author: David Jander <david@protonic.nl>
+ *
+ * Copyright (c) 2005 Protonic Holland b.v.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/usb_isp116x.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+
+#include <asm/mpc8xx.h>
+#include <asm/8xx_immap.h>
+#include <asm/machdep.h>
+#include <asm/irq.h>
+#include <asm/delay.h>
+
+struct resource prt_isp1160_resource[] =
+{
+ {
+ .name = "isp1160_data",
+ .flags = IORESOURCE_MEM,
+ .start = 0xf8100040,
+ .end = 0xf8100041,
+ },
+ {
+ .name = "isp1160_addr",
+ .flags = IORESOURCE_MEM,
+ .start = 0xf8100042,
+ .end = 0xf8100043,
+ },
+ {
+ .name = "isp1160_irq",
+ .flags = IORESOURCE_IRQ,
+ .start = SIU_IRQ6,
+ .end = SIU_IRQ6,
+ }
+};
+
+
+void platform_delay(struct device * dev, int delay)
+{
+ ndelay(delay);
+}
+
+struct isp116x_platform_data isp1160_config =
+{
+ .sel15Kres = 1,
+ .oc_enable = 1,
+ .int_act_high = 0,
+ .int_edge_triggered = 1,
+ .remote_wakeup_enable = 0,
+ .delay = platform_delay,
+};
+
+void __init prtppc_platform_init(void)
+{
+ struct platform_device *pdev;
+ static volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+
+ printk("prtppc_platform_init()\n");
+
+ pdev = platform_device_register_simple("isp116x-hcd",0,prt_isp1160_resource,3);
+ pdev->dev.platform_data = &isp1160_config;
+
+ /* Configure SIU_IRQ6 as edge triggered */
+ immap->im_siu_conf.sc_siel |= 0x00080000;
+ irq_desc[SIU_IRQ6].status &= ~IRQ_LEVEL;
+}
+
+/* Anything special for this platform */
+void __init board_init(void)
+{
+ /* Register a platform_init function */
+ ppc_md.init=prtppc_platform_init;
+}
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -367,7 +367,7 @@ m8xx_map_io(void)
#ifdef CONFIG_PCI
io_block_mapping(PCI_CSR_ADDR, PCI_CSR_ADDR, PCI_CSR_SIZE, _PAGE_IO);
#endif
-#if defined(CONFIG_NETTA)
+#if defined(CONFIG_NETTA) || defined (CONFIG_PRTPPC)
io_block_mapping(_IO_BASE,_IO_BASE,_IO_BASE_SIZE, _PAGE_IO);
#endif
}
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -10,7 +10,8 @@ menu "USB support"
config USB_ARCH_HAS_HCD
boolean
default y if USB_ARCH_HAS_OHCI
- default y if ARM # SL-811
+ default y if ARM # SL-811
+ default y if PRTPPC
default PCI
# many non-PCI SOC chips embed OHCI
diff --git a/drivers/usb/host/isp116x.h b/drivers/usb/host/isp116x.h
--- a/drivers/usb/host/isp116x.h
+++ b/drivers/usb/host/isp116x.h
@@ -365,6 +365,33 @@ struct isp116x_ep {
#define IRQ_TEST() do{}while(0)
#endif
+#if defined(CONFIG_PRTPPC)
+/* On the PRTPPC the ISP1160 is connected through an 8-bit bus via a CPLD
+ * which translates the 8-bit data to 16-bit back and forth.
+ * The UPM splits the 16-bit bus-cycles up into two 8-bit cycles.
+ * The only caveat is that on writing, we have to write to the higher address first
+ * and then to the lower address, while on reading it has to be done the other way around,
+ * that is first the lower address and then the higher address.
+ * So for reading we can use normal 16-bit read functions, while for writing,
+ * we just redefine (temporarily) writew() and __raw_writew() to these below.
+ */
+static void inline writew_hcd(unsigned int port,u16 data)
+{
+ out_8((volatile unsigned char __iomem *)(port | 0x00000001), (data>>8) & 0x00ff);
+ out_8((volatile unsigned char __iomem *)(port & 0xfffffffe), data & 0x00ff);
+}
+
+static void inline raw_writew_hcd(unsigned int port,u16 data)
+{
+ __raw_writeb(data & 0x00ff, (volatile unsigned char __iomem *)(port | 0x00000001));
+ __raw_writeb((data>>8) & 0x00ff, (volatile unsigned char __iomem *)(port & 0xfffffffe));
+}
+
+#define writew(b,a) writew_hcd((unsigned int)(a),b)
+#define __raw_writew(b,a) raw_writew_hcd((unsigned int)(a),b)
+
+#endif /* CONFIG_PRTPPC */
+
static inline void isp116x_write_addr(struct isp116x *isp116x, unsigned reg)
{
IRQ_TEST();
@@ -421,6 +448,11 @@ static inline u32 isp116x_read_data32(st
return val;
}
+#if defined(CONFIG_PRTPPC)
+#undef writew
+#undef __raw_writew
+#endif /* CONFIG_PRTPPC */
+
/* Let's keep register access functions out of line. Hint:
we wait at least 150 ns at every access.
*/
diff --git a/include/asm-ppc/cpm_spi.h b/include/asm-ppc/cpm_spi.h
new file mode 100644
--- /dev/null
+++ b/include/asm-ppc/cpm_spi.h
@@ -0,0 +1,340 @@
+/*
+ * Simple CPM SPI interface for the MPC 8260 and MPC 8xx.
+ *
+ * Copyright (c) 2002 Wolfgang Grandegger (wg@denx.de)
+ *
+ * This interface is partly derived from code copyrighted
+ * by Navin Boppuri (nboppuri@trinetcommunication.co) and
+ * Prashant Patel (pmpatel@trinetcommunication.com).
+ */
+
+#ifndef __CPM_SPI_H
+#define __CPM_SPI_H
+
+#define SPMODE_LEN(x) (((x) - 1) << 4)
+
+#define CPM_SPI_POLL_RETRIES 1000 /* in micro-seconds */
+
+/*
+ * Board specific setting and functions:
+ *
+ * CPM_SPI_MAX_CHIPS: Maximum number of chips on the SPI.
+ *
+ * CPM_SPI_CLOCK: the bitwise or of the DIV16 and PM bits,
+ * see 16.12.4.1 in the MPC823e User's Manual.
+ *
+ * CPM_SPI_MODE : SPI mode setting,
+ * see 16.12.4.1 in the MPC823e User's Manual.
+ *
+ */
+
+#ifdef CONFIG_R360MPI
+/* There are two MPC2510 connected to the SPI */
+
+#define CPM_SPI_MAX_CHIPS 2
+#if 1
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+#else
+#define CPM_SPI_BITS_PER_CHAR 16
+#define CPM_SPI_SWAP_BYTES 1
+#endif
+
+/* There are read timeouts with a clock value of 2 */
+#define CPM_SPI_CLOCK 3
+
+#define CPM_SPI_SPMODE (SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PC14 and PC15 for chip select */
+ iop->iop_pcpar &= ~(0x0003);
+ iop->iop_pcdir |= 0x0003;
+ iop->iop_pcso &= ~(0x0003);
+ iop->iop_pcdat |= 0x0003 ; /* de-select */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PC14/PC15 for chip 0/1 select */
+ if (select)
+ iop->iop_pcdat &= ~(2 >> id);
+ else
+ iop->iop_pcdat |= (2 >> id);
+}
+
+#elif defined(CONFIG_HMI10)
+
+#define CPM_SPI_MAX_CHIPS 1
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+
+#define CPM_SPI_CLOCK 15
+
+#define CPM_SPI_SPMODE (SPMODE_CP | SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PA6 for chip select */
+ iop->iop_papar &= ~(0x0200);
+ iop->iop_padir |= 0x0200;
+ iop->iop_padat |= 0x0200 ; /* de-select */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8xx_t *iop = &immap->im_ioport;
+ /* we use PA6 for chip select */
+ if (select)
+ iop->iop_padat &= ~(0x0200);
+ else
+ iop->iop_padat |= (0x0200);
+}
+
+#elif defined (CONFIG_PM826)
+/* There are two MPC2510 connected to the SPI */
+
+#define CPM_SPI_MAX_CHIPS 32
+#if 0
+#define CPM_SPI_BITS_PER_CHAR 8
+#define CPM_SPI_SWAP_BYTES 0
+#else
+#define CPM_SPI_BITS_PER_CHAR 16
+#define CPM_SPI_SWAP_BYTES 1
+#endif
+
+/* There are read timeouts with a clock value of 2 */
+#define CPM_SPI_CLOCK 0
+
+#define CPM_SPI_SPMODE (SPMODE_REV | SPMODE_MSTR | \
+ SPMODE_LEN(CPM_SPI_BITS_PER_CHAR) |\
+ CPM_SPI_CLOCK)
+
+/*
+ * Pin configuration:
+ *
+ * SEL:
+ * PD19
+ *
+ * CS:
+ * PA9 PA8 PB17 PB16 PB13 PB12
+ * High Low
+ *
+ * IRQ:
+ * PC7 PC6 PC5 PC4 PC3 PC2 PC1
+ * High Low
+ */
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ volatile iop8260_t *iop = &immap->im_ioport;
+
+ /* Configure CS pins */
+ iop->iop_ppara &= ~0x00c00000;
+ iop->iop_pdira |= 0x00c00000;
+ iop->iop_podra &= ~0x00c00000;
+ iop->iop_pdata &= ~0x00c00000;
+
+ iop->iop_pparb &= ~0x000cc000;
+ iop->iop_pdirb |= 0x000cc000;
+ iop->iop_podrb &= ~0x000cc000;
+ iop->iop_pdatb &= ~0x000cc000;
+
+ iop->iop_ppard &= ~0x00001000;
+ iop->iop_pdird |= 0x00001000;
+ iop->iop_podrd &= ~0x00001000;
+ iop->iop_podrd |= 0x00001000;
+
+ /* Configure IRQ pins */
+ iop->iop_pparc &= ~0x7f000000;
+ iop->iop_pdirc &= ~0x7f000000;
+ iop->iop_podrc |= 0x7f000000;
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ volatile iop8260_t *iop = &immap->im_ioport;
+ unsigned long portb, porta;
+
+ if (select) {
+ iop->iop_pdatd |= 0x00001000;
+
+ porta = portb = 0;
+ if (id & 0x01) portb |= 0x00080000;
+ if (id & 0x02) portb |= 0x00040000;
+ if (id & 0x04) portb |= 0x00008000;
+ if (id & 0x08) portb |= 0x00004000;
+ if (id & 0x10) porta |= 0x00800000;
+ if (id & 0x20) porta |= 0x00400000;
+
+ iop->iop_pdata = (iop->iop_pdata & ~0x00c00000) | porta;
+ iop->iop_pdatb = (iop->iop_pdatb & ~0x000cc000) | portb;
+ iop->iop_pdatd &= ~0x00001000;
+
+ } else {
+#if 0 /* SEL line won't work correctly */
+ iop->iop_pdatd |= 0x00001000;
+#else
+ iop->iop_pdata &= ~0x00c00000;
+ iop->iop_pdatb &= ~0x000cc000;
+#endif
+ }
+}
+
+static inline int
+cpm_spi_get_irq_cs (void)
+{
+ volatile immap_t *immap = (immap_t *)IMAP_ADDR;
+ volatile iop8260_t *iop = &immap->im_ioport;
+ unsigned long portc;
+ int irq;
+
+ portc = iop->iop_pdatc;
+
+ irq = 0;
+ if (portc & 0x01000000) irq += 64;
+ if (portc & 0x02000000) irq += 32;
+ if (portc & 0x04000000) irq += 16;
+ if (portc & 0x08000000) irq += 8;
+ if (portc & 0x10000000) irq += 4;
+ if (portc & 0x20000000) irq += 2;
+ if (portc & 0x40000000) irq += 1;
+
+ return irq;
+}
+
+#elif defined (CONFIG_ATC)
+
+#define CPM_SPI_MAX_CHIPS 32
+#define CPM_SPI_SWAP_BYTES 0
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+
+ immap->im_ioport.iop_ppard &= ~0x00080000;
+ immap->im_ioport.iop_pdird |= 0x00080000;
+ immap->im_ioport.iop_podrd &= ~0x00080000;
+ immap->im_ioport.iop_pdatd |= 0x00080000;
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+
+ if (select) {
+ immap->im_ioport.iop_pdatd &= ~0x00080000;
+ } else {
+ immap->im_ioport.iop_pdatd |= 0x00080000;
+ }
+}
+
+#elif defined (CONFIG_PRTPPC)
+
+#define NUM_SPI_CHIPSELS 4
+
+#define PB_SPI_CS0 0x00010000 /* PB 15 is Chip Select for the RTC */
+#define PB_SPI_CS1 0x00000001 /* PB 31 is Chip select for the MMC */
+#define PA_SPI_CS2 0x2000 /* PA 2 (PA has 16-bit registers !!) */
+#define PA_SPI_CS3 0x1000 /* PA 3 (PA has 16-bit registers !!) */
+
+#define CPM_SPI_MAX_CHIPS NUM_SPI_CHIPSELS
+#define CPM_SPI_SWAP_BYTES 0
+
+#define CPM_SPI_SPMODE (/* SPMODE_DIV16 | */\
+ SPMODE_CP | \
+ SPMODE_REV | \
+ SPMODE_MSTR | \
+ SPMODE_LEN(8) | \
+ 0x0f )
+
+static inline void
+cpm_spi_init_ports (volatile immap_t *immap)
+{
+ printk("CPM_SPI: Config chipsels\n");
+ /* Set Port-B pin assignment for SPI pins */
+ immap->im_cpm.cp_pbpar |= 0x0000000e; /* Route PB30,29,28 to second function */
+ immap->im_cpm.cp_pbdir |= 0x0000000e; /* Select SPI block for second function */
+
+ /* Set Port-B and Port-A pin assignments for SPI_CS0...CS3 pins */
+ immap->im_cpm.cp_pbpar &= ~(PB_SPI_CS0 | PB_SPI_CS1); /* Route PB15,PB31 to GPIO */
+ immap->im_ioport.iop_papar &= ~(PA_SPI_CS2 | PA_SPI_CS3); /* Route PB15,PB31 to GPIO */
+
+ immap->im_cpm.cp_pbdir |= (PB_SPI_CS0 | PB_SPI_CS1); /* Set PB15,PB31 as outputs */
+ immap->im_ioport.iop_padir |= (PA_SPI_CS2 | PA_SPI_CS3); /* Set PA2,PA3 as outputs */
+
+ immap->im_cpm.cp_pbdat |= (PB_SPI_CS0 | PB_SPI_CS1); /* Clear Chip Selects (active low) */
+ immap->im_ioport.iop_padat |= (PA_SPI_CS2 | PA_SPI_CS3); /* Clear Chip Selects (active low) */
+}
+
+static inline void
+cpm_spi_set_cs (volatile immap_t *immap, int id, int select)
+{
+ /* printk("CPM_SPI: CS%d = %d\n",id,select); */
+ if(select) {
+ switch(id)
+ {
+ case 0:
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS0; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ break;
+ case 1:
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS1; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ break;
+ case 2:
+ immap->im_ioport.iop_padat &= ~PA_SPI_CS2; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS3;
+ break;
+ case 3:
+ immap->im_ioport.iop_padat &= ~PA_SPI_CS3; /* SET */
+ /* Clear all others */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2;
+ break;
+ default:
+ break;
+ }
+ }
+ else {
+ /* Just clear all CS's */
+ /* FIXME: This _can_ go wrong when doing this:
+ Select1
+ Do something on SPI 1
+ Select2
+ Unselect 1
+ Do something on SPI 2 will fail
+ Unselect 2
+ */
+ immap->im_cpm.cp_pbdat &= ~PB_SPI_CS0;
+ immap->im_cpm.cp_pbdat |= PB_SPI_CS1;
+ immap->im_ioport.iop_padat |= PA_SPI_CS2 | PA_SPI_CS3;
+ }
+}
+
+#else
+#error "CPM SPI support is not implemented for your board"
+#endif
+
+#endif
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -68,6 +68,10 @@
#include <platforms/mpc885ads.h>
#endif
+#if defined(CONFIG_PRTPPC)
+#include <platforms/prtppc.h>
+#endif
+
/* Currently, all 8xx boards that support a processor to PCI/ISA bridge
* use the same memory map.
*/
diff --git a/include/asm-ppc/serial.h b/include/asm-ppc/serial.h
--- a/include/asm-ppc/serial.h
+++ b/include/asm-ppc/serial.h
@@ -38,6 +38,8 @@
#include <asm/mpc85xx.h>
#elif defined(CONFIG_RADSTONE_PPC7D)
#include <platforms/radstone_ppc7d.h>
+#elif defined(CONFIG_PRTPPC)
+#include <platforms/prtppc_serial.h>
#else
/*
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: David Jander @ 2005-11-10 7:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051109120450.GB8588@logos.cnet>
On Wednesday 09 November 2005 13:04, Marcelo Tosatti wrote:
>[...]
>
> ** 2.6.14 DataTLBHandler jump direct ("two exceptions"):
>
> first batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> second batch:
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.6.14 vanilla ("three exceptions"):
>
> first batch:
> avg: 288ms
> avg: 285ms
> avg: 287ms
> avg: 287ms
> avg: 288ms
>
> second batch:
> avg: 288ms
> avg: 288ms
> avg: 287ms
> avg: 287ms
> avg: 287ms
>
> ** 2.4.17 (root on RAMDISK):
>
> avg: 309ms
> avg: 313ms
> avg: 312ms
> avg: 311ms
> avg: 310ms
Hmmm. This is a lot in the line of the tests I did with (the more generic
benchmark) nbench. After looking at those results (see my other post in this
thread) I already suspected something like this.
> The v2.6.14's kernel jump-direct is more consistent at 287ms,
> while vanilla 2.6.14 oscillates between 285 and 288ms, but
> no significant difference between the two.
>
> v2.6's fault handling is clearly faster than 2.4's (note that the compiler
> is also different, 2.4 uses gcc 2.95 and 2.6 gcc 3.3).
I don't think the compiler does much difference here though. In my test the
exact same compiler was used for both kernels, and the same rootfs and binary
of nbench. gcc-3.3.3. I did also use oprofile to get an idea of where the
code spent its most cpu time during nbench, and AFAIR flush_dcache_icache()
took quite a chunk of it, so I assume page fault latency is of importance
there too, and might account for the huge difference between 2.4 and 2.6.
Greetings,
--
David Jander
^ permalink raw reply
* about MPC 8XX SPI Driver
From: 徐小威的EMAIL @ 2005-11-10 6:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
Anybody know where can found 'CPM SPI Driver' for MPC852T.I found a
cpm_spi.c at /arch/ppc/8260_io directory in Linux 2.4.25.But I don't
know how to program application to
handle this driver.
Best Regards,
Rober Hsu
^ permalink raw reply
* Re: [PATCH] ppc: add support for new powerbooks
From: Andrew Morton @ 2005-11-10 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17266.58346.798470.79283@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> > And, given the amount of shared infrastructure, I suspect it would have to
> > be a single git tree for both architectures.
> >
> > I'd still sweep up random ppc patches, but those will go into mainline via the
> > originator->mm->git-powerpc->linus route.
> >
> > Possible?
>
> Yes. Good idea, in fact. I'll create a powerpc.git tree once the
> current merge window closes.
OK.
> Do I need to grep the -mm releases for ppc patches or will you mail
> them to me?
If I see a ppc patch I will:
- merge it into -mm, add you guys to the cc on the mm-commits email.
- stage the patch after git-powerpc.patch in the -mm lineup.
- if I see the patch appear in git-powerpc.patch, I just drop it. I sync
with the git trees maybe twice per day.
- time passes
- if it still hasn't been merged into git-powerpc, I start spamming you
with the patch.
So no, you don't need to grep -mm and I won't bypass the git-powerpc tree
and the patch won't get lost. All you need to do is to either merge or
nack the patch at some stage.
Easy as pie ;)
^ 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