* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:15 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linuxppc-dev list, Yang Xin-Xin-r48390,
linux-kernel, linux-ide, Paul Mackerras, Mark Lord, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
On Fri, May 26, 2006 at 06:01:56PM +0200, Sven Luther wrote:
> > Can you access the disk? Eg. hexdump -C /dev/sda
>
> Trying to partition the disk with parted yielded the last set of debug
> messages, and a :
Interesting. Using dd, i am able to write some stuff to disk :
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yields only 0s.
dd if=/dev/random of=/dev/sda count=4 (count = 4, because /dev/random outputs blocks of 128 bytes)
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yield random non-0 content
Trying to write past the first block, seems to freeze the disk or someting, at
least dd doesn't come back without me ctr-c'ing it.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 16:21 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
Sven Luther wrote:
> On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
>
>> Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
>> box here, and sata_mv seems to be behaving for me (thus far).
>
> Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering, which
> we don't have with a G3, so this may be the cause.
MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
The driver is a complete unknown (for me, at least) on 64-bit systems,
as I don't have one (of any processor type) here yet.
> Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> normal PC card, which is thus uninitialized ?
The board claims to be "mac" compatible, so it probably has an OF bios on it,
but I have not verified this yet.
Cheers
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:25 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <44772B10.7040300@rtr.ca>
On Fri, May 26, 2006 at 12:21:36PM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
> >
> >>Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
> >>box here, and sata_mv seems to be behaving for me (thus far).
> >
> >Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering,
> >which
> >we don't have with a G3, so this may be the cause.
>
> MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
Ah, no, the G4 is a 32bit processor.
> The driver is a complete unknown (for me, at least) on 64-bit systems,
> as I don't have one (of any processor type) here yet.
I have an Xserve G5, which is a 64bit powerpc machine, and i could try it in
it. I need to get the fans to a usable level first though, as it sounds like
an airplan, and is sitting right beside my desk.
> >Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> >normal PC card, which is thus uninitialized ?
>
> The board claims to be "mac" compatible, so it probably has an OF bios on
> it, but I have not verified this yet.
Yes, probably. This could mean that the board gets initialized for you, but
not for me.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Andrew Morton @ 2006-05-26 16:49 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060526151214.GA5190@skynet.ie>
mel@csn.ul.ie (Mel Gorman) wrote:
>
> (Resending with Andrew's email address correct this time)
>
> For the last few -mm releases, kernels built for an old RS6000 failed to
> compile with the message;
>
> arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> make: *** [.tmp_vmlinux1] Error 1
A function with a name like that doesn't _deserve_ to compile.
But actually vrsqrtefp() doesn't call __udivdi3 - the error lies somewhere
else in the kernel and the toolchain gets it wrong, so we don't know where.
The way I usually hunt this problem down is to build the .s files (make
arch/powerpc/kernel/foo.s) and then grep around, find the offending C
function.
If the problem is specific to powerpc then a
diffstat 2.6.17.rc4-mm3 | grep powerpc
will narrow down the number of files to be searched by rather a lot.
> 2.6.17-rc5 is not affected but I didn't search for the culprit patch in
> -mm. The following patch adds an implementation of __udivdi3 for plain old
> ppc32. This may not be the correct fix as Google tells me that __udivdi3
> has been replaced by calls to do_div() in a number of cases. There was no
> obvious way to do that for vrsqrtefp, hence this workaround. The patch should
> be acked, rejected or replaced by a ppc expert.
Yes, we've traditionally avoided adding the 64-bit divide library functions.
^ permalink raw reply
* Re: [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: John W. Linville @ 2006-05-26 19:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, linuxppc-dev
In-Reply-To: <200605231549.43430.toralf.foerster@gmx.de>
On Tue, May 23, 2006 at 03:49:40PM +0200, Toralf Förster wrote:
> Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Yeah, known 'bug', we have that code there but never use it. Feel free
> to submit a patch (to John Linville, CC netdev and softmac-dev) to
> remove it.
>
> Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
This patch is whitespace-damaged. Please teach your mailer not to
convert tabs to spaces and resubmit.
Thanks!
John
> --- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
> +++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
> @@ -456,31 +456,3 @@
> return IEEE80211_2ADDR_LEN;
> }
>
> -
> -/* Sends a control packet */
> -static int
> -ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
> - struct ieee80211softmac_network *net, u32 type, u32 arg)
> -{
> - void *pkt = NULL;
> - u32 pkt_size = 0;
<snip>
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [openib-general] [PATCH 06/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-26 20:06 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4468BD63.6070509@de.ibm.com>
> + for_each_online_cpu(cpu) {
> + task = create_comp_task(pool, cpu);
> + if (task) {
> + kthread_bind(task, cpu);
> + wake_up_process(task);
> + }
> + }
How does this creation of a thread pool work with respect to CPU
hotplug? What happens if a CPU goes away? How about if only one CPU
is running when the driver is loaded, and then 15 more are hot-added?
> + for (i = 0; i < NR_CPUS; i++) {
> + if (cpu_online(i))
> + destroy_comp_task(pool, i);
> + }
And it seems in the destroy function, you will possibly leak threads
or try to kill a non-existent thread if the set of online CPUs has
changed since the driver started...
- R.
^ permalink raw reply
* 440gx dma transfer with no data change at dest
From: John Lange @ 2006-05-26 20:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi Kevin
I saw a posting from March where you were asking about problems doing
memory to memory DMA transfers with the ppc4xx_dma module of Linux. I'm
curious if you figured out that issue. Would you be kind enough to
share how you fixed the issue you were having? I would sure appreciate
a snippet of working example code if it's not proprietary.
Best regards,
John
[-- Attachment #2: Type: text/html, Size: 2267 bytes --]
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Benjamin Herrenschmidt @ 2006-05-26 21:41 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, Johannes Berg, debian-powerpc
In-Reply-To: <60381eeb0605260902p4420757ai3669aba711122014@mail.gmail.com>
On Fri, 2006-05-26 at 19:02 +0300, Eddy Petrişor wrote:
> On 5/25/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> > Hey,
>
> Hi,
>
> > [1] to find your layout-id, execute the following:
> >
> > find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
> >
> > If you get no output, you have no layout-id property. If you do get
>
> What are the plans for machines without layout-id, like the 5,2 model?
> Will there be any alsa/aoa support at some point?
There will be, but let's get the ones with layout-id first since
snd-powermac should work on the older ones.
Ben.
^ permalink raw reply
* Re: [RFC] snd-aoa and interrupts (headphone detection etc)
From: Benjamin Herrenschmidt @ 2006-05-26 21:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1148055359.6228.20.camel@johannes.berg>
> The problematic part is things that the codec must control. Say we want
> line-in detection to automatically switch to line-in if microphone is
> selected (does anyone ever want this?). Then the problem is that the
> interrupt arrives at the GPIO layer, and I can easily make it seen in
> the fabric too. However, then propagating it to the codec is a bit
> harder. Or we don't have it in the fabric but have the codec register
> for that interrupt (through our GPIO layer). This is the first option.
No. I don't think the codecs should mess with the GPIOs directly. The
policy should be implemented in the fabric. If in some case you need to
change some codec settings, then the codec shall provide an accessor for
doing so.
> The second option is changing the whole in-/output control code that we
> have and moving it from the codec to the fabric layer. The fabric
> already knows what in- and outputs a codec has (in order to know what is
> connected), hence if we added a codec driver function to turn on/off any
> in- or output we could have the fabric control this. But then we'd also
> have to make known to the codec which of those are mutually exclusive,
> and generally make it more complicated.
We don't have to make known to the codec, we just turn on/off the right
ones.
> I currently favour the first option, the codec driver can know when it
> makes sense to try registering the interrupt (if it isn't present it
> fails anyway) and then do the appropriate stuff (possibly giving the
> user a choice).
I disagree :) But then, it's your code :)
Ben.
^ permalink raw reply
* Howto allocate non-cacheable memory
From: Muneeswaran P - TLS, Chennai @ 2006-05-27 5:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
How to allocate non-cacheable kernel memory ?
Pls help me.
I am writing device driver (kernel 2.6 ) for PCI-X card.
Pls clarify the following doubts:
1. DPRAM is memory mapped to PCI-X card.
2. I have to transfer data from main memory to DPRAM using bus
master concept and vice-versa.
3. How to make this memory area as non-cacheable one ?=20
4. Whether DMA mapping (pci_map_single() call ) should be done for
both DPRAM and main memory ?
4.a) I will get the physical address of DPRAM memory (memory
mapped to PCI-X card) from BAR-0 register. Can i use this physical =
addres
directly for data transer using bus master (without pci_map_single() =
call.)
?
4.b) How to make main memory area as non-cacheable one ?
Regards,
Munees.
DISCLAIMER=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20
named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20
affiliates. Any views or opinions presented in this email are solely =
those of the author and=20
may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20
dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20
message without the prior written consent of the author of this e-mail =
is strictly=20
prohibited. If you have received this email in error please delete it =
and notify the sender=20
immediately. Before opening any mail and attachments please check them =
for viruses and=20
defect.
^ permalink raw reply
* [PATCH, 2.6.17-rc5-git3] ieee80211softmac_io.c: fix warning "defined but not used"
From: Toralf Förster @ 2006-05-27 9:04 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
Got this compiler warning and Johannes Berg <johannes@sipsolutions.net> wrote:
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
--- src/net/ieee80211/softmac/ieee80211softmac_io.c_orig 2006-05-27 10:50:56.000000000 +0200
+++ src/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-27 10:51:45.000000000 +0200
@@ -440,47 +440,3 @@
return 0;
}
-
-/* Create an rts/cts frame */
-static u32
-ieee80211softmac_rts_cts(struct ieee80211_hdr_2addr **pkt,
- struct ieee80211softmac_device *mac, struct ieee80211softmac_network *net,
- u32 type)
-{
- /* Allocate Packet */
- (*pkt) = kmalloc(IEEE80211_2ADDR_LEN, GFP_ATOMIC);
- memset(*pkt, 0, IEEE80211_2ADDR_LEN);
- if((*pkt) == NULL)
- return 0;
- ieee80211softmac_hdr_2addr(mac, (*pkt), type, net->bssid);
- return IEEE80211_2ADDR_LEN;
-}
-
-
-/* Sends a control packet */
-static int
-ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
- struct ieee80211softmac_network *net, u32 type, u32 arg)
-{
- void *pkt = NULL;
- u32 pkt_size = 0;
-
- switch(type) {
- case IEEE80211_STYPE_RTS:
- case IEEE80211_STYPE_CTS:
- pkt_size = ieee80211softmac_rts_cts((struct ieee80211_hdr_2addr **)(&pkt), mac, net, type);
- break;
- default:
- printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n", type);
- return -EINVAL;
- }
-
- if(pkt_size == 0)
- return -ENOMEM;
-
- /* Send the packet to the ieee80211 layer for tx */
- ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
-
- kfree(pkt);
- return 0;
-}
--
MfG/Sincerely
Toralf Förster
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-27 11:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.59069.781220.922878@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> > decremeter_common, but its not fatal anymore because the cpu is now in
> > 64bit mode and the stack is forced to PACAKSAVE(r13).
> >
> > subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> > beq- 1f; \
> > ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> > -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> > +1: \
> > + cmpdi cr1,r29,0x42; \
>
> Ummm, what's r29 supposed to have in it here?
>
> > + bne cr1,2f; \
> > + li r29,2f@l; \
>
> And why are we setting it?
>
> Does it look like the SRR0 and SRR1 values are correct when we get
> this problem occurring? Is it just the MSR that is bogus?
I looked into this again, my debug patch was wrong. I cant rely on the
hello32, r29 has to be set in the system_reset path. This is the
register dump. It shows that the cpus are in 32bit mode, and that
system_reset_fwnmi calls system_reset_common correctly.
0:mon> r
R00 = 000000001000036c R16 = 0000000000000042
R01 = 00000000ffe96ad0 R17 = 0000000000000042
R02 = 000000001009b470 R18 = 0000000000000042
R03 = 0000000000000009 R19 = 0000000000000042
R04 = 000000001002228c R20 = 0000000000000042
R05 = 0000000040042082 R21 = 0000000000000042
R06 = 0000000000004000 R22 = 0000000000000042
R07 = 0000000010008af0 R23 = 0000000000000042
R08 = 0000000000000000 R24 = 0000000000000042
R09 = 0000000000000000 R25 = 0000000000000042
R10 = 8000000000001032 R26 = 0000000000000042
R11 = 00000000ffe96a50 R27 = 0000000000000042
R12 = 0000000020000082 R28 = 0000000000000042
R13 = 000000001009a410 R29 = 0000000000003220
R14 = 0000000000000042 R30 = 0000000000001002
R15 = 0000000000000042 R31 = a000000000001032
pc = 00000000100003b4
lr = 000000001000036c
msr = 000000000000d032 cr = 20000082
ctr = 0000000000032ddc xer = 00000000000fffff trap = 100
0:mon> c1
1:mon> r
R00 = 000000001000036c R16 = 0000000000000042
R01 = 00000000ffe96ad0 R17 = 0000000000000042
R02 = 000000001009b470 R18 = 0000000000000042
R03 = 0000000000000007 R19 = 0000000000000042
R04 = 000000001002228c R20 = 0000000000000042
R05 = 0000000040022082 R21 = 0000000000000042
R06 = 0000000000004000 R22 = 0000000000000042
R07 = 0000000010008af0 R23 = 0000000000000042
R08 = 0000000000000000 R24 = 0000000000000042
R09 = 0000000000000000 R25 = 0000000000000042
R10 = 8000000000001032 R26 = 0000000000000042
R11 = 00000000ffe96a50 R27 = 0000000000000042
R12 = 0000000020000082 R28 = 0000000000000042
R13 = 000000001009a410 R29 = 0000000000003220
R14 = 0000000000000042 R30 = 0000000000001002
R15 = 0000000000000042 R31 = a000000000001032
pc = 00000000100003b4
lr = 000000001000036c
msr = 000000000000d032 cr = 20000082
ctr = 0000000000032ddc xer = 00000000000fffff trap = 100
Index: linux-2.6/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6/arch/powerpc/kernel/head_64.S
@@ -211,6 +211,31 @@ exception_marker:
ori reg,reg,(label)@l; /* virt addr of handler ... */
#endif
+#define EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(area, label) \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,area+EX_R9(r13); /* save r9 - r12 */ \
+ std r10,area+EX_R10(r13); \
+ std r11,area+EX_R11(r13); \
+ std r12,area+EX_R12(r13); \
+ mfspr r9,SPRN_SPRG1; \
+ std r9,area+EX_R13(r13); \
+ mfcr r9; \
+ clrrdi r12,r13,32; /* get high part of &label */ \
+ mfmsr r10; \
+ mr r30,r10; \
+ li r11,5; /* MSR_SF_LG|MSR_ISF_LG */ \
+ rldicr r11,r11,61,2; /* (5 << 61) */ \
+ or r10,r10,r11; \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label) \
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mr r31,r10; \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
#define EXCEPTION_PROLOG_PSERIES(area, label) \
mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
std r9,area+EX_R9(r13); /* save r9 - r12 */ \
@@ -269,7 +294,12 @@ exception_marker:
subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
beq- 1f; \
ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
-1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
+1: \
+ cmpdi cr1,r29,0x42; \
+ bne cr1,2f; \
+ li r29,2f@l; \
+2: ; \
+ cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
bge- cr1,bad_stack; /* abort if it is */ \
std r9,_CCR(r1); /* save CR in stackframe */ \
std r11,_NIP(r1); /* save SRR0 in stackframe */ \
@@ -600,14 +630,15 @@ slb_miss_user_pseries:
system_reset_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common)
+ li r29,0x42
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXGEN, system_reset_common)
.globl machine_check_fwnmi
.align 7
machine_check_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common)
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXMC, machine_check_common)
#ifdef CONFIG_PPC_ISERIES
/*** ISeries-LPAR interrupt handlers ***/
^ permalink raw reply
* please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-05-27 13:17 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
There are 3 commits there: an update to MAINTAINERS, a fix for the
"Maple" PPC970FX evaluation boards, and a fix for the Freescale
embedded 8272 processor that is apparently needed for the console to
work on those chips. These fixes won't affect any other platforms and
are safe to go in for 2.6.17 IMO.
Thanks,
Paul.
MAINTAINERS | 4 +--
arch/powerpc/kernel/prom_init.c | 48 +++++++++++++++++++++++++++++--
arch/ppc/platforms/mpc8272ads_setup.c | 10 +++---
arch/ppc/syslib/pq2_devices.c | 16 +++++-----
arch/ppc/syslib/pq2_sys.c | 8 +++--
drivers/serial/cpm_uart/cpm_uart_core.c | 8 +++--
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +
7 files changed, 70 insertions(+), 26 deletions(-)
commit 54f4ee183aea859eb09f141dad3fc3c6f4fe0446
Author: Hollis Blanchard <hollisb@us.ibm.com>
Date: Thu May 25 16:36:53 2006 -0500
[PATCH] powerpc: fix RTC/NVRAM accesses on Maple
Due to a firmware device tree bug, RTC and NVRAM accesses (including
halt/reboot) on Maple have been broken since January, when an untested
build fix went in. This code patches the device tree in Linux.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 8e30a9a299ca30b6c4072c2182238d5f5dd1590d
Author: Vitaly Bordug <vbordug@ru.mvista.com>
Date: Wed May 24 21:40:18 2006 +0400
[PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 6d923f98fe0f31c174ace92f8b680d0d153663aa
Author: Arthur Othieno <apgo@patchbomb.org>
Date: Fri May 19 06:22:23 2006 -0400
[PATCH] powerpc: linuxppc64.org no more
http://linuxppc64.org has long been a redirect to the canonical
http://penguinppc.org/ppc64/ -- update all instances accordingly,
as ACKed by Hollis:
On Wed, Jan 18, 2006 at 09:48:08AM -0600, Hollis Blanchard wrote:
> On Wed, 2006-01-18 at 13:07 +0100, Olaf Hering wrote:
> > On Wed, Jan 18, Arthur Othieno wrote:
> > >
> > > What about the s/linuxppc64\.org/penguinppc\.org/g case? Or is
> > > penguinppc64.org preferable? Or am I just taking it too far? ;)
> >
> > They are redirected on DNS or HTTP level.
>
> HTTP level, but that doesn't answer his question.
>
> As the maintainer of that site, I would prefer to remove the
> linuxppc64.org reference.
Signed-off-by: Arthur Othieno <apgo@patchbomb.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Pavel Machek @ 2006-05-26 17:39 UTC (permalink / raw)
To: Stelian Pop
Cc: Andrew Morton, linuxppc-dev list, Johannes Berg,
Linux Kernel list
In-Reply-To: <1148465069.6723.26.camel@localhost.localdomain>
Hi!
> From: Stelian Pop <stelian@popies.net>
>
> This driver provides support for the Apple Motion Sensor (ams),
> which provides an accelerometer and other misc. data.
> Some Apple PowerBooks (the series the PowerBook5,6 falls into,
> later ones have a slightly different one the driver doesn't handle)
> are supported. The accelerometer data is readable via sysfs.
>
> This driver also provides an absolute input class device, allowing
> the laptop to act as a pinball machine-esque joystick.
Is it useful to have /sysfs interface when we already have same data
available as joystick?
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-27 20:06 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Linux Kernel list, linuxppc-dev list
In-Reply-To: <20060526173908.GA3357@ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Fri, 2006-05-26 at 17:39 +0000, Pavel Machek wrote:
> > This driver also provides an absolute input class device, allowing
> > the laptop to act as a pinball machine-esque joystick.
>
> Is it useful to have /sysfs interface when we already have same data
> available as joystick?
Might be useful if you need to turn off the "joystick" because X gets
confused with it. Other than that, no.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Stelian Pop @ 2006-05-27 20:31 UTC (permalink / raw)
To: Johannes Berg
Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list, Pavel Machek
In-Reply-To: <1148760414.16989.59.camel@johannes.berg>
Le samedi 27 mai 2006 à 22:06 +0200, Johannes Berg a écrit :
> On Fri, 2006-05-26 at 17:39 +0000, Pavel Machek wrote:
>
> > > This driver also provides an absolute input class device, allowing
> > > the laptop to act as a pinball machine-esque joystick.
> >
> > Is it useful to have /sysfs interface when we already have same data
> > available as joystick?
>
> Might be useful if you need to turn off the "joystick" because X gets
> confused with it. Other than that, no.
/sysfs interface also exports the 'z' coordinate, the input interface
does not.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: [RFC] snd-aoa and interrupts (headphone detection etc)
From: Johannes Berg @ 2006-05-27 20:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1148679918.8089.166.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On Sat, 2006-05-27 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > The problematic part is things that the codec must control. Say we want
> > line-in detection to automatically switch to line-in if microphone is
> > selected (does anyone ever want this?). Then the problem is that the
> > interrupt arrives at the GPIO layer, and I can easily make it seen in
> > the fabric too. However, then propagating it to the codec is a bit
> > harder. Or we don't have it in the fabric but have the codec register
> > for that interrupt (through our GPIO layer). This is the first option.
>
> No. I don't think the codecs should mess with the GPIOs directly. The
> policy should be implemented in the fabric. If in some case you need to
> change some codec settings, then the codec shall provide an accessor for
> doing so.
Yeah. That was my second option mostly.
> > The second option is changing the whole in-/output control code that we
> > have and moving it from the codec to the fabric layer. The fabric
> > already knows what in- and outputs a codec has (in order to know what is
> > connected), hence if we added a codec driver function to turn on/off any
> > in- or output we could have the fabric control this. But then we'd also
> > have to make known to the codec which of those are mutually exclusive,
> > and generally make it more complicated.
>
> We don't have to make known to the codec, we just turn on/off the right
> ones.
Hmm, ok, good point, then we don't even need the complication of telling
the codec what is connected to it. Maybe that simplifies the code in
total... But the codecs will still need hardcoded numbers for the
various in- and outputs that the fabric needs to know.
I'll think about this a bit more, maybe experiment with the code a
bit :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Pavel Machek @ 2006-05-27 20:34 UTC (permalink / raw)
To: Stelian Pop
Cc: Andrew Morton, linuxppc-dev list, Johannes Berg,
Linux Kernel list
In-Reply-To: <1148761919.3132.1.camel@deep-space-9.dsnet>
On So 27-05-06 22:31:58, Stelian Pop wrote:
> Le samedi 27 mai 2006 ? 22:06 +0200, Johannes Berg a écrit :
> > On Fri, 2006-05-26 at 17:39 +0000, Pavel Machek wrote:
> >
> > > > This driver also provides an absolute input class device, allowing
> > > > the laptop to act as a pinball machine-esque joystick.
> > >
> > > Is it useful to have /sysfs interface when we already have same data
> > > available as joystick?
> >
> > Might be useful if you need to turn off the "joystick" because X gets
> > confused with it. Other than that, no.
>
> /sysfs interface also exports the 'z' coordinate, the input interface
> does not.
Can that be fixed? z coordinate should be useful for input, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Tutorial on PPC exception
From: jeanwelly @ 2006-05-28 3:18 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
SGkgQWxsLA0KRG9lcyBhbnlib2R5IGtub3cgaG93IHRvIGdldCB0aGUgZnVsbCBleGNlcHRpb25z
IG9mIHRoZSBQUEM/IFdoaWNoIHR1dG9yaWFsIGNvdWxkIGJlIGZldGNoZWQgYXMgYSByZWZlcmVu
Y2U/DQoNCkkgZ290IGFuIGV4Y2VwdGlvbiBmcm9tIHRoZSBoYXJkd2FyZSwgYnV0IEkgZG9uJ3Qg
a25vdyB0aGUgZGV0YWlsZWQgbWVhbmluZ3MsIGJlY3Vhc2UgaXQgd2FzIHRha2VuIGFzIGFuICJ1
bmtub3duIGV4cGVjdGlvbiIgYnkgbXkgc3lzdGVtLiBQZXJzb25hbGx5LCBJIHRoaW5rIGFuIGV4
Y2VwdGlvbiBpcyBhbiBodyBiZWhhcmlvdXIsIHNvIEkgZ3Vlc3MgdGhlcmUgc2hvdWxkIGJlIGFu
IHRoaXMga2luZCBvZiBkb2N1bWVudC4NCg0KVGhhbmsgeW91ISAJCQkJDQoNCqGhoaGhoaGhoaGh
oaGhoaFqZWFud2VsbHkNCqGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHlAMTI2LmNvbQ0KoaGhoaGh
oaGhoaGhoaGhoaGhoaEyMDA2LTA1LTI4DQo=
^ permalink raw reply
* [PATCH] powerpc: add dmesg command to xmon
From: Olaf Hering @ 2006-05-28 10:46 UTC (permalink / raw)
To: linuxppc-dev
Based on work by Linas Vepstas:
dump dmesg buffer in xmon, with a new 'D' command.
Use kallsyms to lookup the symbols to avoid touching generic code in printk.c
Signed-off-by: Olaf Hering <olh@suse.de>
---
arch/powerpc/xmon/xmon.c | 112 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
Index: linux-2.6/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6/arch/powerpc/xmon/xmon.c
@@ -143,6 +143,7 @@ void dump_segments(void);
static void symbol_lookup(void);
static void xmon_print_symbol(unsigned long address, const char *mid,
const char *after);
+static void xmon_show_dmesg(void);
static const char *getvecname(unsigned long vec);
extern int print_insn_powerpc(unsigned long, unsigned long, int);
@@ -192,6 +193,7 @@ Commands:\n\
df dump float values\n\
dd dump double values\n\
dr dump stream of raw bytes\n\
+ D show dmesg (printk) buffer\n\
e print exception information\n\
f flush cache\n\
la lookup symbol+offset of specified address\n\
@@ -781,6 +783,9 @@ cmds(struct pt_regs *excp)
case 'd':
dump();
break;
+ case 'D':
+ xmon_show_dmesg();
+ break;
case 'l':
symbol_lookup();
break;
@@ -2488,6 +2493,113 @@ static void xmon_print_symbol(unsigned l
printf("%s", after);
}
+#ifdef CONFIG_KALLSYMS
+static const char *xmon_log_buf;
+static int xmon_log_buf_len;
+static unsigned long xmon_log_end, xmon_logged_chars;
+
+static int xmon_init_dmesg(void)
+{
+ const char **p;
+ const int *i;
+ const unsigned long *l;
+
+ if (!xmon_log_buf && setjmp(bus_error_jmp) == 0) {
+ catch_memory_errors = 1;
+ sync();
+
+ p = (const char **)kallsyms_lookup_name("log_buf");
+ if (p) {
+ xmon_log_buf = *p;
+ sync();
+ __delay(200);
+ }
+
+ i = (const int *)kallsyms_lookup_name("log_buf_len");
+ if (i) {
+ xmon_log_buf_len = *i;
+ sync();
+ __delay(200);
+ }
+
+ l = (const unsigned long *)kallsyms_lookup_name("log_end");
+ if (l) {
+ xmon_log_end = *l;
+ sync();
+ __delay(200);
+ }
+
+ l = (const unsigned long *)kallsyms_lookup_name("logged_chars");
+ if (l) {
+ xmon_logged_chars = *l;
+ sync();
+ __delay(200);
+ }
+
+ }
+ catch_memory_errors = 0;
+ return !!xmon_log_buf;
+}
+#else
+static inline int xmon_init_dmesg(void)
+{
+ return 0;
+}
+#endif
+
+static void xmon_show_dmesg(void)
+{
+ if (xmon_init_dmesg()) {
+ const char *p_start, *p_end, *l_start, *l_end, *start, *end;
+ char c;
+
+ p_start = xmon_log_buf;
+ p_end = p_start + xmon_log_buf_len;
+ l_start = p_start + xmon_log_end - (xmon_logged_chars < xmon_log_buf_len ? xmon_logged_chars : xmon_log_buf_len);
+ l_end = p_start + xmon_log_end;
+ if (l_start == l_end)
+ return;
+ start = p_start + (l_start - p_start) % xmon_log_buf_len;
+ end = p_start + (l_end - p_start) % xmon_log_buf_len;
+ c = '\0';
+ while (1) {
+ const char *p;
+ int chars = 0;
+ if (!*start) {
+ while (!*start) {
+ start++;
+ if (start < p_start)
+ start = p_end - 1;
+ else if (start >= p_end)
+ start = p_start;
+ if (start == end)
+ break;
+ }
+ if (start == end)
+ break;
+ }
+ p = start;
+ while (*start && chars < 200) {
+ c = *start;
+ chars++;
+ start++;
+ if (start < p_start)
+ start = p_end - 1;
+ else if (start >= p_end)
+ start = p_start;
+ if (start == end)
+ break;
+ }
+ if (chars)
+ printf("%.*s", chars, p);
+ if (start == end)
+ break;
+ }
+ if (c != '\n')
+ printf("\n");
+ }
+}
+
#ifdef CONFIG_PPC64
static void dump_slb(void)
{
^ permalink raw reply
* Re: [PATCH] powerpc: add dmesg command to xmon
From: Arnd Bergmann @ 2006-05-28 12:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olaf Hering
In-Reply-To: <20060528104621.GA7126@suse.de>
T24gU3VuZGF5IDI4IE1heSAyMDA2IDEyOjQ2LCBPbGFmIEhlcmluZyB3cm90ZToKPiArc3RhdGlj
IGludCB4bW9uX2luaXRfZG1lc2codm9pZCkKPiArewo+ICugoKCgoKCgY29uc3QgY2hhciAqKnA7
Cj4gK6CgoKCgoKBjb25zdCBpbnQgKmk7Cj4gK6CgoKCgoKBjb25zdCB1bnNpZ25lZCBsb25nICps
Owo+ICsKPiAroKCgoKCgoGlmICgheG1vbl9sb2dfYnVmICYmIHNldGptcChidXNfZXJyb3Jfam1w
KSA9PSAwKSB7Cj4gK6CgoKCgoKCgoKCgoKCgoGNhdGNoX21lbW9yeV9lcnJvcnMgPSAxOwo+ICug
oKCgoKCgoKCgoKCgoKBzeW5jKCk7Cj4gKwo+ICugoKCgoKCgoKCgoKCgoKBwID0gKGNvbnN0IGNo
YXIgKiopa2FsbHN5bXNfbG9va3VwX25hbWUoImxvZ19idWYiKTsKPiAroKCgoKCgoKCgoKCgoKCg
aWYgKHApIHsKPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKB4bW9uX2xvZ19idWYgPSAqcDsKPiAr
oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBzeW5jKCk7Cj4gK6CgoKCgoKCgoKCgoKCgoKCgoKCgoKCg
X19kZWxheSgyMDApOwo+ICugoKCgoKCgoKCgoKCgoKB9Cj4gKwo+ICugoKCgoKCgoKCgoKCgoKBp
ID0gKGNvbnN0IGludCAqKWthbGxzeW1zX2xvb2t1cF9uYW1lKCJsb2dfYnVmX2xlbiIpOwo+ICug
oKCgoKCgoKCgoKCgoKBpZiAoaSkgewo+ICugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHhtb25fbG9n
X2J1Zl9sZW4gPSAqaTsKPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBzeW5jKCk7Cj4gK6CgoKCg
oKCgoKCgoKCgoKCgoKCgoKCgX19kZWxheSgyMDApOwo+ICugoKCgoKCgoKCgoKCgoKB9Cj4gKwo+
ICugoKCgoKCgoKCgoKCgoKBsID0gKGNvbnN0IHVuc2lnbmVkIGxvbmcgKilrYWxsc3ltc19sb29r
dXBfbmFtZSgibG9nX2VuZCIpOwo+ICugoKCgoKCgoKCgoKCgoKBpZiAobCkgewo+ICugoKCgoKCg
oKCgoKCgoKCgoKCgoKCgoHhtb25fbG9nX2VuZCA9ICpsOwo+ICugoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoHN5bmMoKTsKPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKBfX2RlbGF5KDIwMCk7Cj4gK6Cg
oKCgoKCgoKCgoKCgoH0KPiArCj4gK6CgoKCgoKCgoKCgoKCgoGwgPSAoY29uc3QgdW5zaWduZWQg
bG9uZyAqKWthbGxzeW1zX2xvb2t1cF9uYW1lKCJsb2dnZWRfY2hhcnMiKTsKPiAroKCgoKCgoKCg
oKCgoKCgaWYgKGwpIHsKPiAroKCgoKCgoKCgoKCgoKCgoKCgoKCgoKB4bW9uX2xvZ2dlZF9jaGFy
cyA9ICpsOwo+ICugoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHN5bmMoKTsKPiAroKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKBfX2RlbGF5KDIwMCk7Cj4gK6CgoKCgoKCgoKCgoKCgoH0KPiArCj4gK6CgoKCg
oKB9Cj4gK6CgoKCgoKBjYXRjaF9tZW1vcnlfZXJyb3JzID0gMDsKPiAroKCgoKCgoHJldHVybiAh
IXhtb25fbG9nX2J1ZjsKClRoaXMgd2hvbGUgZnVuY3Rpb24gbG9va3MgZmlzaHkgdG8gbWUuIEl0
IHNlZW1zIHVubmVjZXNzYXJpbHkgcnVkZSB0byBtZSB0bwp1c2Uga2FsbHN5bXNfbG9va3VwX25h
bWUgaW4gb3JkZXIgdG8gZ2V0IGF0IGEgc3RhdGljIHZhcmlhYmxlIGZyb20gYW5vdGhlcgpmaWxl
LiBDYW4ndCB5b3UgaW5zdGVhZCBhZGQgYSBnbG9iYWwgZnVuY3Rpb24gdG8ga2VybmVsL3ByaW50
ay5jIHRvIHJldHVybgp0aGUgYnVmZmVyPwoKQWxzbywgd2hhdCdzIHRoZSBwdXJwb3NlIG9mIHRo
ZSBzeW5jL19fZGVsYXkgY29kZSBpbiBoZXJlPyBJZiB5b3UgdXNlIHRoYXQKdG8gY2hlY2sgZm9y
IGEgcG9zc2libGUgbWFjaGluZSBjaGVjayB0aGF0IG1heSBoYXZlIGhhcHBlbmVkLCB3aHkgbm90
IGluCnRoZSBjYXNlIHdoZXJlIHRoZSBsb29rdXAgZmFpbHM/CgoJQXJuZCA8PjwK
^ permalink raw reply
* Re: [PATCH] powerpc: add dmesg command to xmon
From: Olaf Hering @ 2006-05-28 12:07 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200605281404.26070.arnd@arndb.de>
On Sun, May 28, Arnd Bergmann wrote:
> This whole function looks fishy to me. It seems unnecessarily rude to me to
> use kallsyms_lookup_name in order to get at a static variable from another
> file. Can't you instead add a global function to kernel/printk.c to return
> the buffer?
Its possible, but it wont end up in Linus tree.
> Also, what's the purpose of the sync/__delay code in here? If you use that
> to check for a possible machine check that may have happened, why not in
> the case where the lookup fails?
I just copied the other usages. Accessing the dmesg buffer itself may
need similar checks.
^ permalink raw reply
* Re: Howto allocate non-cacheable memory
From: Arnd Bergmann @ 2006-05-28 15:36 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Muneeswaran P - TLS, Chennai
In-Reply-To: <012301731C23DE4DBFE035647C68F1CC0331C84F@sindhu.ctd.hcltech.com>
On Saturday 27 May 2006 07:38, Muneeswaran P - TLS, Chennai wrote:
> =A0=A0=A0=A0=A0=A0=A0=A0Pls clarify the following doubts:
> =A0=A0=A0=A0=A0=A0=A0=A01. DPRAM is memory mapped to PCI-X card.
> =A0=A0=A0=A0=A0=A0=A0=A02. I have to transfer data from main memory to DP=
RAM using bus
> master concept and vice-versa.
> =A0=A0=A0=A0=A0=A0=A0=A03. How to make this memory area as non-cacheable =
one ?=20
> =A0=A0=A0=A0=A0=A0=A0=A04. Whether DMA mapping (pci_map_single() call ) s=
hould be done for
> both DPRAM and main memory ?
> =A0=A0=A0=A0=A0=A0=A0=A0 =A0 4.a) I will get the physical address of DPRA=
M memory (memory
> mapped to PCI-X card) from BAR-0 register. Can i use this physical addres
> directly for data transer using bus master (without pci_map_single() call=
=2E)
> ?
> =A0=A0=A0=A0=A0=A0=A0=A0 =A0 4.b) =A0How to make main memory area as non-=
cacheable one ?
You need pci_map_single() for all bus-master accesses from the PCI-X card
and ioremap() to map the card's registers and/or memory into your kernel
address space as cache-inhibited.
Depending on what your adapter does, you might want to map memory areas
on the card with __ioremap(addr, size, _PAGE_NO_CACHE) instead of
ioremap(addr, size) in order to get a non-guarded mapping.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: add dmesg command to xmon
From: Arnd Bergmann @ 2006-05-28 16:12 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060528120748.GA7608@suse.de>
On Sunday 28 May 2006 14:07, Olaf Hering wrote:
> > This whole function looks fishy to me. It seems unnecessarily rude to me to
> > use kallsyms_lookup_name in order to get at a static variable from another
> > file. Can't you instead add a global function to kernel/printk.c to return
> > the buffer?
>
> Its possible, but it wont end up in Linus tree.
Hmm, so the idea is that because Linus doesn't like kernel debuggers, we just
obfuscate the code for any improvements to xmon and hope he doesn't notice?
Don't get me wrong, I think having dmesg in xmon is a good idea, but this is
probably not the best strategy of getting it in there.
Arnd <><
^ permalink raw reply
* Re: Tutorial on PPC exception
From: Mark Chambers @ 2006-05-28 18:15 UTC (permalink / raw)
To: jeanwelly, linuxppc-embedded
In-Reply-To: <200605281118066622530@126.com>
> Hi All,
> Does anybody know how to get the full exceptions of the PPC? Which
> tutorial could be fetched as a reference?
>
Freescale has complete documentation for their processors available at
www.freescale.com
Mark C.
^ 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