* How does the Montavisa previewkit?
From: likun @ 2005-03-30 1:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi everbody:
i downloaded a Montavisa previewkit-mvl3.0.0_db1500-encrypt.img
yesterday ,it's a free kit.i want to use it as my hard hat linux .i work
on muti channels MPEG4 video process ,need OS strong real time,i kown the
vxworks being very good,but it's very expencive.so i had to use Embed
linux on mips-au1500 cpu.what i want to know is how does the real time of
Montavisa previewkit
,anybody know?
for example, i want to deal with 16-24 channel MPEG4 codec
using MPEG4 ASIC chip .enviroment is Red hat 7.2 kenel 2.4.20.
can the Montavisa response real time?
thank all
jordon
[-- Attachment #2: Type: text/html, Size: 1135 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array
From: Dan Malek @ 2005-03-30 1:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, shall, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503291627130.16284@blarg.somerset.sps.mot.com>
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote:
> Cleaned up irq_to_siubit array so we no longer need to do 1 <<
> (31-bit),
> just 1 << bit.
Will you please put a comment in here that indicates this array now
has this computation done? When I wrote it, these bit numbers
matched the registers and the documentation, so I didn't take
the time to explain. :-)
Thanks.
-- Dan
^ permalink raw reply
* ptrace and ORIG_EAX on ppc
From: ashwin tanugula @ 2005-03-30 1:01 UTC (permalink / raw)
To: linuxppc-dev
Hi!
Can somebody tell me how to set references to ORIG_EAX in ppc kernel.
We know ORIG_EAX is defined in unistd.h of i386. How do i make the
following program print two same pids in ppc?
#include <stdio.h>
#include <signal.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <asm/ptrace.h>
#include <asm/unistd.h>
static char stack[65536];
int child(void *arg)
{
if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){
perror("ptrace");
exit(1);
}
kill(getpid(), SIGSTOP);
while(1){
printf("getpid() returned %d\n", getpid());
sleep(3);
}
return(0);
}
int main(int argc, char **argv)
{
int pid, status, syscall;
printf("Parent pid = %d\n", getpid());
if((pid = clone(child, &stack[65532], SIGCHLD, NULL)) < 0){
perror("clone");
exit(1);
}
if((pid = waitpid(pid, &status, WUNTRACED)) < 0){
perror("Waiting for stop");
exit(1);
}
if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0){
perror("continuing");
exit(1);
}
while(1){
if((pid = waitpid(-1, &status, WUNTRACED)) <= 0){
perror("wait");
exit(1);
}
if(WIFSTOPPED(status) && (WSTOPSIG(status) == SIGTRAP)){
syscall = ptrace(PTRACE_PEEKUSER, pid, 4 * ORIG_EAX, 0);
if(syscall == __NR_getpid){
if(ptrace(PTRACE_POKEUSER, pid, 4 * ORIG_EAX, __NR_getppid) < 0){
perror("ptrace");
exit(1);
}
}
if(ptrace(PTRACE_SYSCALL, pid, 0, 0) < 0){
perror("continuing");
exit(1);
}
}
else printf("wait failed - pid = %d, status = %d\n", pid, status);
}
}
Note: References to ORIG_EAX have to be set here.
Thanks,
Ashwin.
^ permalink raw reply
* Re: how to get a embbed linux for MPC8240 which core is 603e
From: Wolfgang Denk @ 2005-03-30 0:17 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: inuxppc-embedded
In-Reply-To: <424970CD.3030006@smiths-aerospace.com>
In message <424970CD.3030006@smiths-aerospace.com> Jerry Van Baren wrote:
>
> Wolfgang Denk has a very good turn-key system "Embedded Linux
> Development Kit" (ELDK). Download it and install it -- it is a very
> painless way to get started with a cross (or native) development system.
Thanks, Jerry. But credit where credit is due - actually it's DENX
Software Engineering who does all this stuff and services; I just
happen to be part of a team of excellent engineers. My role is more
or less just the mailing list interface, so they can focus on doing
the real work ;-)
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
panic: kernel trap (ignored)
^ permalink raw reply
* Re: how to get a embbed linux for MPC8240 which core is 603e
From: Wolfgang Denk @ 2005-03-30 0:12 UTC (permalink / raw)
To: Anchor; +Cc: inuxppc-embedded
In-Reply-To: <4249EC0F.1010302@centecnetworks.com>
In message <4249EC0F.1010302@centecnetworks.com> you wrote:
>
> thank you very much! but the ELDK only support PPC8XX, PPC6XX, PPC85XX,
This is not correct. Please see
http://www.denx.de/twiki/bin/view/DULG/ELDKSupportedTargetArchitectures
for the full list of supported target architectures.
> perhaps I need PPC6XX, I want to know, this number is cpu type identify
> or core type Identify?
For the MPC82xx you will use the ppc_82xx packages of the ELDK, which
happens to be just a symbolic link to ppc_6xx.
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
Never call a man a fool. Borrow from him.
^ permalink raw reply
* Re: how to get a embbed linux for MPC8240 which core is 603e
From: Anchor @ 2005-03-30 0:00 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: inuxppc-embedded
In-Reply-To: <424970CD.3030006@smiths-aerospace.com>
Jerry Van Baren wrote:
> Anchor wrote:
>
>> Hi everbody:
>>
>> I am a new guy, I want get a ready embedded linux for Motorala
>> ppc8245, give me a hand.
>>
>> Thank you very much!
>>
>> anchor xie
>
>
> CLAP CLap Clap clap
>
> Wolfgang Denk has a very good turn-key system "Embedded Linux
> Development Kit" (ELDK). Download it and install it -- it is a very
> painless way to get started with a cross (or native) development system.
> <http://denx.de/e/index1.php>
>
> Read the documentation on his site!
> <http://denx.de/e/index1.php?head=docs-head&main=docs&subnav=docs-subnav&logo=logo-se&mainnav=docsnav&bottom=bottom-se>
>
>
> ...especially the very useful " DENX Guide to U-Boot and Embedded Linux"
> <http://www.denx.de/twiki/bin/view/DULG/Manual>
>
> READ the FAQ! Re-read the FAQ!
> <http://www.denx.de/twiki/bin/view/DULG/Faq>
>
> If you need a boot loader, u-boot is a very good way to go.
> <http://sourceforge.net/projects/u-boot>
> (Wolfgang is the maintainer).
>
> gvb
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
Jerry:
thank you very much! but the ELDK only support PPC8XX, PPC6XX, PPC85XX,
perhaps I need PPC6XX, I want to know, this number is cpu type identify
or core type Identify?
anchor xie
^ permalink raw reply
* Re: [PATCH] Fix sleep/wakeup problems on iBook G3
From: Graham Wilson @ 2005-03-29 22:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1112133877.6577.35.camel@gaston>
On Wed, Mar 30, 2005 at 08:04:37AM +1000, Benjamin Herrenschmidt wrote:
> > I've been having various trouble with my iBook lately, including random
> > freezes, not waking up after going to sleep sometimes, and sometimes not
> > going to sleep. Since applying the patch you posted, everything seems
> > fine, though I may be speaking too soon.
>
> Can you also check my other patch which fixes cpufreq as well ? And test
> if it's reliable wether you sleep at low or high speed ?
I haven't had any trouble with cpufreq (and I use powernowd with the
userspace governor), but I will apply your other patch this evening and
see what happens.
--
gram
^ permalink raw reply
* [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array
From: Kumar Gala @ 2005-03-29 22:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, shall, linuxppc-embedded
In-Reply-To: <20050329201209.GB30850@gate.ebshome.net>
Andrew,
Cleaned up irq_to_siubit array so we no longer need to do 1 << (31-bit),
just 1 << bit.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
--- a/arch/ppc/syslib/cpm2_pic.c 2005-03-29 16:25:34 -06:00
+++ b/arch/ppc/syslib/cpm2_pic.c 2005-03-29 16:25:34 -06:00
@@ -33,14 +33,14 @@
};
static u_char irq_to_siubit[] = {
- 31, 16, 17, 18, 19, 20, 21, 22,
- 23, 24, 25, 26, 27, 28, 29, 30,
- 29, 30, 16, 17, 18, 19, 20, 21,
- 22, 23, 24, 25, 26, 27, 28, 31,
- 0, 1, 2, 3, 4, 5, 6, 7,
- 8, 9, 10, 11, 12, 13, 14, 15,
- 15, 14, 13, 12, 11, 10, 9, 8,
- 7, 6, 5, 4, 3, 2, 1, 0
+ 0, 15, 14, 13, 12, 11, 10, 9,
+ 8, 7, 6, 5, 4, 3, 2, 1,
+ 2, 1, 15, 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,
+ 16, 17, 18, 19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
};
static void cpm2_mask_irq(unsigned int irq_nr)
@@ -54,7 +54,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
+ ppc_cached_irq_mask[word] &= ~(1 << bit);
simr[word] = ppc_cached_irq_mask[word];
}
@@ -69,7 +69,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] |= (1 << (31 - bit));
+ ppc_cached_irq_mask[word] |= 1 << bit;
simr[word] = ppc_cached_irq_mask[word];
}
@@ -85,9 +85,9 @@
simr = &(cpm2_immr->im_intctl.ic_simrh);
sipnr = &(cpm2_immr->im_intctl.ic_sipnrh);
- ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
+ ppc_cached_irq_mask[word] &= ~(1 << bit);
simr[word] = ppc_cached_irq_mask[word];
- sipnr[word] = 1 << (31 - bit);
+ sipnr[word] = 1 << bit;
}
static void cpm2_end_irq(unsigned int irq_nr)
@@ -103,7 +103,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] |= (1 << (31 - bit));
+ ppc_cached_irq_mask[word] |= 1 << bit;
simr[word] = ppc_cached_irq_mask[word];
}
}
^ permalink raw reply
* Re: [PATCH] Fix sleep/wakeup problems on iBook G3
From: Benjamin Herrenschmidt @ 2005-03-29 22:04 UTC (permalink / raw)
To: Graham Wilson; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20050329190703.GA15755@mknod.org>
> I've been having various trouble with my iBook lately, including random
> freezes, not waking up after going to sleep sometimes, and sometimes not
> going to sleep. Since applying the patch you posted, everything seems
> fine, though I may be speaking too soon.
>
> My /proc/cpuinfo for reference:
> processor : 0
> cpu : 750FX
> temperature : 0-3 C (uncalibrated)
> clock : 400MHz
> revision : 2.3 (pvr 7000 0203)
> bogomips : 793.71
> machine : PowerBook4,3
> motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
> detected as : 257 (iBook 2 rev. 2)
> pmac flags : 0000001b
> L2 cache : 512K unified
> memory : 256MB
> pmac-generation : NewWorld
>
> Note that the maximum CPU speed is 900 MHz.
Can you also check my other patch which fixes cpufreq as well ? And test
if it's reliable wether you sleep at low or high speed ?
Thanks,
Ben.
^ permalink raw reply
* Re: [PATCH] sleep & cpufreq problems
From: David Woodhouse @ 2005-03-29 21:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: fedora-ppc, linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1112071689.6809.19.camel@gaston>
On Tue, 2005-03-29 at 14:48 +1000, Benjamin Herrenschmidt wrote:
>
> > http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
> > http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
>
> I just updated the second patch, so if you got it since my last email,
> please d/l it again.
I still have no cpufreq on my PowerBook5,3.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] ppc32: CPM2 PIC cleanup
From: Eugene Surovegin @ 2005-03-29 20:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, shall, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503291039180.15390@blarg.somerset.sps.mot.com>
On Tue, Mar 29, 2005 at 10:42:29AM -0600, Kumar Gala wrote:
> Andrew,
>
> Cleaned up the CPM2 interrupt controller code:
> * Added the ability to offset the IRQs
> * Refactored common PIC init code out of platform files
> * Fixed IRQ offsets on MPC85xx so it can handle properly handled multiple
> interrupt controllers (i8259, CPM2 PIC, and OpenPIC)
>
> Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
[snip]
Guys, while you are at it, could we renumber irq_to_siubit[] array in
cpm2_pic.c so we can get rid of "1 << (31 - bit)" expressions and
simply use "1 << bit"? I know, it's a minor thing, but you are
cleaning this stuff anyway, why not make it super clean :).
--
Eugene
^ permalink raw reply
* Re: Overcommit (OOM) problem on embedded device (PPChameleon)
From: Eugene Surovegin @ 2005-03-29 19:46 UTC (permalink / raw)
To: Martin Egholm Nielsen; +Cc: linuxppc-embedded
In-Reply-To: <4249ACF1.60305@egholm-nielsen.dk>
On Tue, Mar 29, 2005 at 09:30:57PM +0200, Martin Egholm Nielsen wrote:
[snip]
> Specs:
> I'm having an embedded Linux system running on a PPC405EP (PPChameleon)
> with 64 megs of RAM, some flash, but (ofcourse) no swap space. It runs a
> 2.4.20 kernel patched with drivers for my device.
>
> Problem:
> I have an application that is killed by the OOM (I guess) when it tries
> to "use" more memory than present on the system.
> Bolied down, memory is allocated with "sbrk" and then touch'ed (see
> test-application below).
[snip]
> However, both my desktop Linux (RH 7.3)/2.4.18-10/i386 and Linux
> (FC2)/2.6.5/i386 did what I expected:
Well, the only way to get the same results is to use the _same_ linux
kernel version and have the _same_ hw configuration (e.g. memory
configuration).
There were quite a few changes to VM during 2.4 lifetime; 2.6 is
different from 2.4 in the memory management area. RH kernel is
probably patched as hell, so who knows what VM it has.
--
Eugene
^ permalink raw reply
* Overcommit (OOM) problem on embedded device (PPChameleon)
From: Martin Egholm Nielsen @ 2005-03-29 19:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
I hope this is the place to go...
I have a some problems figuring out the OOM-killer and configuring the
overcommit_memory parameter. Hope someone here can guide me in the right
directions...
Specs:
I'm having an embedded Linux system running on a PPC405EP (PPChameleon)
with 64 megs of RAM, some flash, but (ofcourse) no swap space. It runs a
2.4.20 kernel patched with drivers for my device.
Problem:
I have an application that is killed by the OOM (I guess) when it tries
to "use" more memory than present on the system.
Bolied down, memory is allocated with "sbrk" and then touch'ed (see
test-application below).
With "/proc/sys/vm/overcommit_memory" set to 2, I expected that "sbrk"
would return "-1L" (0xFFFFFFFF), but it doesn't, hence is
terminated/killed by the kernel.
However, both my desktop Linux (RH 7.3)/2.4.18-10/i386 and Linux
(FC2)/2.6.5/i386 did what I expected:
# ./exhaust_mem
...
ffffffff
Out of memory
# #Yeaaaah!
Having searched the web, I see that this may be related with the fact
that there is no swap enabled on the embedded device.
However, I tried disabling the swap (commented in fstab), but the
desktop linux still behaves "correct".
Can I do anything in order to get it the way I expected?
Best regards,
Martin Egholm
=== exhaust_mem.c ===
#include <unistd.h>
#include <stdio.h>
#define SIZE 1000000
int main( int i )
{
while ( 1 ) {
char *v = sbrk( SIZE );
char *p;
printf( "%x\n\n", v );
if ((long)v < 0) {
fprintf(stderr, "Out of memory\n");
exit(1);
} // if
for (p = v; p < v + SIZE; ++p) {
*p = 42;
} // for
} // while
} // main
^ permalink raw reply
* Re: [PATCH] Fix sleep/wakeup problems on iBook G3
From: Graham Wilson @ 2005-03-29 19:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1111964111.6099.19.camel@gaston>
On Mon, Mar 28, 2005 at 08:55:11AM +1000, Benjamin Herrenschmidt wrote:
> There have been various reports lately of sleep beeing broken on iBook
> G3. Frank (no name provided here) found a typo in my code that cleans
> the L1 cache on these CPU models. This patch fixes it, I'd appreciate
> some feedback about wether that fixes the problem or not.
I've been having various trouble with my iBook lately, including random
freezes, not waking up after going to sleep sometimes, and sometimes not
going to sleep. Since applying the patch you posted, everything seems
fine, though I may be speaking too soon.
My /proc/cpuinfo for reference:
processor : 0
cpu : 750FX
temperature : 0-3 C (uncalibrated)
clock : 400MHz
revision : 2.3 (pvr 7000 0203)
bogomips : 793.71
machine : PowerBook4,3
motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2 rev. 2)
pmac flags : 0000001b
L2 cache : 512K unified
memory : 256MB
pmac-generation : NewWorld
Note that the maximum CPU speed is 900 MHz.
--
gram
^ permalink raw reply
* Re: [PATCH] sleep & cpufreq problems
From: Sebastien NOEL @ 2005-03-29 16:34 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev list
In-Reply-To: <1112066934.6809.4.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Tue, 29 Mar 2005 13:28:54 +1000 , Benjamin Herrenschmidt wrote:
> Hi !
>
> Here are a couple of patches against current linus bk (one was already
> posted to this list) that should fix a number issues related to sleep
> and wakeup, especially in conjunction with cpufreq transitions.
>
> Please test and let me know if it fixes a problem you had, it adds a new
> problem, or it has no effect, stuff still doesn't work (if it used to
> work and still work, no need to bug me).
>
> Thanks !
>
> Patches are at:
>
> http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
> http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
>
> Thanks,
> Ben.
>
Hi Ben !
I apply your 3 patches on 2.6.12-rc1 and my ibook g4 doesn't crash anymore
after wakeup when i change the cpu speed.
My gratitude is far bigger than my english vocabulary, thank you very much!
Sebastien
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ppc32: CPM2 PIC cleanup
From: Kumar Gala @ 2005-03-29 16:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded, linux-kernel, shall
Andrew,
Cleaned up the CPM2 interrupt controller code:
* Added the ability to offset the IRQs
* Refactored common PIC init code out of platform files
* Fixed IRQ offsets on MPC85xx so it can handle properly handled multiple
interrupt controllers (i8259, CPM2 PIC, and OpenPIC)
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/platforms/85xx/mpc8560_ads.c b/arch/ppc/platforms/85xx/mpc8560_ads.c
--- a/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8560_ads.c 2005-03-29 10:36:16 -06:00
@@ -135,25 +135,11 @@
static void __init
mpc8560_ads_init_IRQ(void)
{
- int i;
- volatile cpm2_map_t *immap = cpm2_immr;
-
/* Setup OpenPIC */
mpc85xx_ads_init_IRQ();
- /* disable all CPM interupts */
- immap->im_intctl.ic_simrh = 0x0;
- immap->im_intctl.ic_simrl = 0x0;
-
- for (i = CPM_IRQ_OFFSET; i < (NR_CPM_INTS + CPM_IRQ_OFFSET); i++)
- irq_desc[i].handler = &cpm2_pic;
-
- /* Initialize the default interrupt mapping priorities,
- * in case the boot rom changed something on us.
- */
- immap->im_intctl.ic_sicr = 0;
- immap->im_intctl.ic_scprrh = 0x05309770;
- immap->im_intctl.ic_scprrl = 0x05309770;
+ /* Setup CPM2 PIC */
+ cpm2_init_IRQ();
setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-03-29 10:36:16 -06:00
@@ -181,10 +181,6 @@
mpc85xx_cds_init_IRQ(void)
{
bd_t *binfo = (bd_t *) __res;
-#ifdef CONFIG_CPM2
- volatile cpm2_map_t *immap = cpm2_immr;
- int i;
-#endif
/* Determine the Physical Address of the OpenPIC regs */
phys_addr_t OpenPIC_PAddr = binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
@@ -203,19 +199,8 @@
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
#ifdef CONFIG_CPM2
- /* disable all CPM interupts */
- immap->im_intctl.ic_simrh = 0x0;
- immap->im_intctl.ic_simrl = 0x0;
-
- for (i = CPM_IRQ_OFFSET; i < (NR_CPM_INTS + CPM_IRQ_OFFSET); i++)
- irq_desc[i].handler = &cpm2_pic;
-
- /* Initialize the default interrupt mapping priorities,
- * in case the boot rom changed something on us.
- */
- immap->im_intctl.ic_sicr = 0;
- immap->im_intctl.ic_scprrh = 0x05309770;
- immap->im_intctl.ic_scprrl = 0x05309770;
+ /* Setup CPM2 PIC */
+ cpm2_init_IRQ();
setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);
#endif
diff -Nru a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c
--- a/arch/ppc/platforms/85xx/stx_gp3.c 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/platforms/85xx/stx_gp3.c 2005-03-29 10:36:16 -06:00
@@ -201,7 +201,6 @@
gp3_init_IRQ(void)
{
int i;
- volatile cpm2_map_t *immap = cpm2_immr;
bd_t *binfo = (bd_t *) __res;
/*
@@ -227,24 +226,8 @@
*/
openpic_init(MPC85xx_OPENPIC_IRQ_OFFSET);
- /*
- * Setup CPM2 PIC
- */
-
- /* disable all CPM interupts */
- immap->im_intctl.ic_simrh = 0x0;
- immap->im_intctl.ic_simrl = 0x0;
-
- for (i = CPM_IRQ_OFFSET; i < (NR_CPM_INTS + CPM_IRQ_OFFSET); i++)
- irq_desc[i].handler = &cpm2_pic;
-
- /*
- * Initialize the default interrupt mapping priorities,
- * in case the boot rom changed something on us.
- */
- immap->im_intctl.ic_sicr = 0;
- immap->im_intctl.ic_scprrh = 0x05309770;
- immap->im_intctl.ic_scprrl = 0x05309770;
+ /* Setup CPM2 PIC */
+ cpm2_init_IRQ();
setup_irq(MPC85xx_IRQ_CPM, &cpm2_irqaction);
diff -Nru a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
--- a/arch/ppc/syslib/cpm2_pic.c 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/syslib/cpm2_pic.c 2005-03-29 10:36:16 -06:00
@@ -48,6 +48,8 @@
int bit, word;
volatile uint *simr;
+ irq_nr -= CPM_IRQ_OFFSET;
+
bit = irq_to_siubit[irq_nr];
word = irq_to_siureg[irq_nr];
@@ -61,6 +63,8 @@
int bit, word;
volatile uint *simr;
+ irq_nr -= CPM_IRQ_OFFSET;
+
bit = irq_to_siubit[irq_nr];
word = irq_to_siureg[irq_nr];
@@ -74,6 +78,8 @@
int bit, word;
volatile uint *simr, *sipnr;
+ irq_nr -= CPM_IRQ_OFFSET;
+
bit = irq_to_siubit[irq_nr];
word = irq_to_siureg[irq_nr];
@@ -92,6 +98,7 @@
if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))
&& irq_desc[irq_nr].action) {
+ irq_nr -= CPM_IRQ_OFFSET;
bit = irq_to_siubit[irq_nr];
word = irq_to_siureg[irq_nr];
@@ -101,20 +108,15 @@
}
}
-struct hw_interrupt_type cpm2_pic = {
- " CPM2 SIU ",
- NULL,
- NULL,
- cpm2_unmask_irq,
- cpm2_mask_irq,
- cpm2_mask_and_ack,
- cpm2_end_irq,
- 0
+static struct hw_interrupt_type cpm2_pic = {
+ .typename = " CPM2 SIU ",
+ .enable = cpm2_unmask_irq,
+ .disable = cpm2_mask_irq,
+ .ack = cpm2_mask_and_ack,
+ .end = cpm2_end_irq,
};
-
-int
-cpm2_get_irq(struct pt_regs *regs)
+int cpm2_get_irq(struct pt_regs *regs)
{
int irq;
unsigned long bits;
@@ -126,5 +128,43 @@
if (irq == 0)
return(-1);
- return irq;
+ return irq+CPM_IRQ_OFFSET;
+}
+
+void cpm2_init_IRQ(void)
+{
+ int i;
+
+ /* Clear the CPM IRQ controller, in case it has any bits set
+ * from the bootloader
+ */
+
+ /* Mask out everything */
+ cpm2_immr->im_intctl.ic_simrh = 0x00000000;
+ cpm2_immr->im_intctl.ic_simrl = 0x00000000;
+ wmb();
+
+ /* Ack everything */
+ cpm2_immr->im_intctl.ic_sipnrh = 0xffffffff;
+ cpm2_immr->im_intctl.ic_sipnrl = 0xffffffff;
+ wmb();
+
+ /* Dummy read of the vector */
+ i = cpm2_immr->im_intctl.ic_sivec;
+ rmb();
+
+ /* Initialize the default interrupt mapping priorities,
+ * in case the boot rom changed something on us.
+ */
+ cpm2_immr->im_intctl.ic_sicr = 0;
+ cpm2_immr->im_intctl.ic_scprrh = 0x05309770;
+ cpm2_immr->im_intctl.ic_scprrl = 0x05309770;
+
+
+ /* Enable chaining to OpenPIC, and make everything level
+ */
+ for (i = 0; i < NR_CPM_INTS; i++) {
+ irq_desc[i+CPM_IRQ_OFFSET].handler = &cpm2_pic;
+ irq_desc[i+CPM_IRQ_OFFSET].status |= IRQ_LEVEL;
+ }
}
diff -Nru a/arch/ppc/syslib/cpm2_pic.h b/arch/ppc/syslib/cpm2_pic.h
--- a/arch/ppc/syslib/cpm2_pic.h 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/syslib/cpm2_pic.h 2005-03-29 10:36:16 -06:00
@@ -1,7 +1,8 @@
#ifndef _PPC_KERNEL_CPM2_H
#define _PPC_KERNEL_CPM2_H
-extern struct hw_interrupt_type cpm2_pic;
extern int cpm2_get_irq(struct pt_regs *regs);
+
+extern void cpm2_init_IRQ(void);
#endif /* _PPC_KERNEL_CPM2_H */
diff -Nru a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c
--- a/arch/ppc/syslib/m8260_setup.c 2005-03-29 10:36:16 -06:00
+++ b/arch/ppc/syslib/m8260_setup.c 2005-03-29 10:36:16 -06:00
@@ -167,18 +167,12 @@
static void __init
m8260_init_IRQ(void)
{
- int i;
-
- for ( i = 0 ; i < NR_SIU_INTS ; i++ )
- irq_desc[i].handler = &cpm2_pic;
+ cpm2_init_IRQ();
/* Initialize the default interrupt mapping priorities,
* in case the boot rom changed something on us.
*/
- cpm2_immr->im_intctl.ic_sicr = 0;
cpm2_immr->im_intctl.ic_siprr = 0x05309770;
- cpm2_immr->im_intctl.ic_scprrh = 0x05309770;
- cpm2_immr->im_intctl.ic_scprrl = 0x05309770;
}
/*
diff -Nru a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h 2005-03-29 10:36:16 -06:00
+++ b/include/asm-ppc/irq.h 2005-03-29 10:36:16 -06:00
@@ -171,7 +171,7 @@
#define NR_IRQS (NR_IPIC_INTS)
-#elif defined(CONFIG_CPM2) && defined(CONFIG_85xx)
+#elif defined(CONFIG_85xx)
/* Now include the board configuration specific associations.
*/
#include <asm/mpc85xx.h>
@@ -186,7 +186,7 @@
#define NR_CPM_INTS 64
#define NR_EPIC_INTS 44
#ifndef NR_8259_INTS
-#define NR_8259_INTS 0
+#define NR_8259_INTS 0
#endif
#define NUM_8259_INTERRUPTS NR_8259_INTS
@@ -196,13 +196,59 @@
#define NR_IRQS (NR_EPIC_INTS + NR_CPM_INTS + NR_8259_INTS)
-/* These values must be zero-based and map 1:1 with the EPIC configuration.
- * They are used throughout the 8560 I/O subsystem to generate
- * interrupt masks, flags, and other control patterns. This is why the
- * current kernel assumption of the 8259 as the base controller is such
- * a pain in the butt.
- */
+/* Internal IRQs on MPC85xx OpenPIC */
+
+#ifndef MPC85xx_OPENPIC_IRQ_OFFSET
+#ifdef CONFIG_CPM2
+#define MPC85xx_OPENPIC_IRQ_OFFSET (CPM_IRQ_OFFSET + NR_CPM_INTS)
+#else
+#define MPC85xx_OPENPIC_IRQ_OFFSET 0
+#endif
+#endif
+
+/* Not all of these exist on all MPC85xx implementations */
+#define MPC85xx_IRQ_L2CACHE ( 0 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_ECM ( 1 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DDR ( 2 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_LBIU ( 3 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DMA0 ( 4 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DMA1 ( 5 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DMA2 ( 6 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DMA3 ( 7 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_PCI1 ( 8 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_PCI2 ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_RIO_ERROR ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_RIO_BELL (10 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_RIO_TX (11 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_RIO_RX (12 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC1_TX (13 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC1_RX (14 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC1_ERROR (18 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC2_TX (19 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC2_RX (20 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_TSEC2_ERROR (24 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_FEC (25 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_DUART (26 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_IIC1 (27 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_PERFMON (28 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_SEC2 (29 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_CPM (30 + MPC85xx_OPENPIC_IRQ_OFFSET)
+
+/* The 12 external interrupt lines */
+#define MPC85xx_IRQ_EXT0 (32 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT1 (33 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT2 (34 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT3 (35 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT4 (36 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT5 (37 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT6 (38 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT7 (39 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT8 (40 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT9 (41 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT10 (42 + MPC85xx_OPENPIC_IRQ_OFFSET)
+#define MPC85xx_IRQ_EXT11 (43 + MPC85xx_OPENPIC_IRQ_OFFSET)
+/* CPM related interrupts */
#define SIU_INT_ERROR ((uint)0x00+CPM_IRQ_OFFSET)
#define SIU_INT_I2C ((uint)0x01+CPM_IRQ_OFFSET)
#define SIU_INT_SPI ((uint)0x02+CPM_IRQ_OFFSET)
@@ -267,57 +313,62 @@
* (Document errata updates have fixed this...make sure you have up to
* date processor documentation -- Dan).
*/
-#define NR_SIU_INTS 64
-#define SIU_INT_ERROR ((uint)0x00)
-#define SIU_INT_I2C ((uint)0x01)
-#define SIU_INT_SPI ((uint)0x02)
-#define SIU_INT_RISC ((uint)0x03)
-#define SIU_INT_SMC1 ((uint)0x04)
-#define SIU_INT_SMC2 ((uint)0x05)
-#define SIU_INT_IDMA1 ((uint)0x06)
-#define SIU_INT_IDMA2 ((uint)0x07)
-#define SIU_INT_IDMA3 ((uint)0x08)
-#define SIU_INT_IDMA4 ((uint)0x09)
-#define SIU_INT_SDMA ((uint)0x0a)
-#define SIU_INT_TIMER1 ((uint)0x0c)
-#define SIU_INT_TIMER2 ((uint)0x0d)
-#define SIU_INT_TIMER3 ((uint)0x0e)
-#define SIU_INT_TIMER4 ((uint)0x0f)
-#define SIU_INT_TMCNT ((uint)0x10)
-#define SIU_INT_PIT ((uint)0x11)
-#define SIU_INT_IRQ1 ((uint)0x13)
-#define SIU_INT_IRQ2 ((uint)0x14)
-#define SIU_INT_IRQ3 ((uint)0x15)
-#define SIU_INT_IRQ4 ((uint)0x16)
-#define SIU_INT_IRQ5 ((uint)0x17)
-#define SIU_INT_IRQ6 ((uint)0x18)
-#define SIU_INT_IRQ7 ((uint)0x19)
-#define SIU_INT_FCC1 ((uint)0x20)
-#define SIU_INT_FCC2 ((uint)0x21)
-#define SIU_INT_FCC3 ((uint)0x22)
-#define SIU_INT_MCC1 ((uint)0x24)
-#define SIU_INT_MCC2 ((uint)0x25)
-#define SIU_INT_SCC1 ((uint)0x28)
-#define SIU_INT_SCC2 ((uint)0x29)
-#define SIU_INT_SCC3 ((uint)0x2a)
-#define SIU_INT_SCC4 ((uint)0x2b)
-#define SIU_INT_PC15 ((uint)0x30)
-#define SIU_INT_PC14 ((uint)0x31)
-#define SIU_INT_PC13 ((uint)0x32)
-#define SIU_INT_PC12 ((uint)0x33)
-#define SIU_INT_PC11 ((uint)0x34)
-#define SIU_INT_PC10 ((uint)0x35)
-#define SIU_INT_PC9 ((uint)0x36)
-#define SIU_INT_PC8 ((uint)0x37)
-#define SIU_INT_PC7 ((uint)0x38)
-#define SIU_INT_PC6 ((uint)0x39)
-#define SIU_INT_PC5 ((uint)0x3a)
-#define SIU_INT_PC4 ((uint)0x3b)
-#define SIU_INT_PC3 ((uint)0x3c)
-#define SIU_INT_PC2 ((uint)0x3d)
-#define SIU_INT_PC1 ((uint)0x3e)
-#define SIU_INT_PC0 ((uint)0x3f)
+#ifndef CPM_IRQ_OFFSET
+#define CPM_IRQ_OFFSET 0
+#endif
+
+#define NR_CPM_INTS 64
+
+#define SIU_INT_ERROR ((uint)0x00 + CPM_IRQ_OFFSET)
+#define SIU_INT_I2C ((uint)0x01 + CPM_IRQ_OFFSET)
+#define SIU_INT_SPI ((uint)0x02 + CPM_IRQ_OFFSET)
+#define SIU_INT_RISC ((uint)0x03 + CPM_IRQ_OFFSET)
+#define SIU_INT_SMC1 ((uint)0x04 + CPM_IRQ_OFFSET)
+#define SIU_INT_SMC2 ((uint)0x05 + CPM_IRQ_OFFSET)
+#define SIU_INT_IDMA1 ((uint)0x06 + CPM_IRQ_OFFSET)
+#define SIU_INT_IDMA2 ((uint)0x07 + CPM_IRQ_OFFSET)
+#define SIU_INT_IDMA3 ((uint)0x08 + CPM_IRQ_OFFSET)
+#define SIU_INT_IDMA4 ((uint)0x09 + CPM_IRQ_OFFSET)
+#define SIU_INT_SDMA ((uint)0x0a + CPM_IRQ_OFFSET)
+#define SIU_INT_TIMER1 ((uint)0x0c + CPM_IRQ_OFFSET)
+#define SIU_INT_TIMER2 ((uint)0x0d + CPM_IRQ_OFFSET)
+#define SIU_INT_TIMER3 ((uint)0x0e + CPM_IRQ_OFFSET)
+#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_IRQ1 ((uint)0x13 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ2 ((uint)0x14 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ3 ((uint)0x15 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ4 ((uint)0x16 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ5 ((uint)0x17 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ6 ((uint)0x18 + CPM_IRQ_OFFSET)
+#define SIU_INT_IRQ7 ((uint)0x19 + CPM_IRQ_OFFSET)
+#define SIU_INT_FCC1 ((uint)0x20 + CPM_IRQ_OFFSET)
+#define SIU_INT_FCC2 ((uint)0x21 + CPM_IRQ_OFFSET)
+#define SIU_INT_FCC3 ((uint)0x22 + CPM_IRQ_OFFSET)
+#define SIU_INT_MCC1 ((uint)0x24 + CPM_IRQ_OFFSET)
+#define SIU_INT_MCC2 ((uint)0x25 + CPM_IRQ_OFFSET)
+#define SIU_INT_SCC1 ((uint)0x28 + CPM_IRQ_OFFSET)
+#define SIU_INT_SCC2 ((uint)0x29 + CPM_IRQ_OFFSET)
+#define SIU_INT_SCC3 ((uint)0x2a + CPM_IRQ_OFFSET)
+#define SIU_INT_SCC4 ((uint)0x2b + CPM_IRQ_OFFSET)
+#define SIU_INT_PC15 ((uint)0x30 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC14 ((uint)0x31 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC13 ((uint)0x32 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC12 ((uint)0x33 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC11 ((uint)0x34 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC10 ((uint)0x35 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC9 ((uint)0x36 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC8 ((uint)0x37 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC7 ((uint)0x38 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC6 ((uint)0x39 + CPM_IRQ_OFFSET)
+#define SIU_INT_PC5 ((uint)0x3a + CPM_IRQ_OFFSET)
+#define SIU_INT_PC4 ((uint)0x3b + CPM_IRQ_OFFSET)
+#define SIU_INT_PC3 ((uint)0x3c + CPM_IRQ_OFFSET)
+#define SIU_INT_PC2 ((uint)0x3d + CPM_IRQ_OFFSET)
+#define SIU_INT_PC1 ((uint)0x3e + CPM_IRQ_OFFSET)
+#define SIU_INT_PC0 ((uint)0x3f + CPM_IRQ_OFFSET)
#endif /* CONFIG_8260 */
diff -Nru a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h 2005-03-29 10:36:16 -06:00
+++ b/include/asm-ppc/mpc85xx.h 2005-03-29 10:36:16 -06:00
@@ -52,55 +52,6 @@
*/
extern unsigned char __res[];
-/* Internal IRQs on MPC85xx OpenPIC */
-/* Not all of these exist on all MPC85xx implementations */
-
-#ifndef MPC85xx_OPENPIC_IRQ_OFFSET
-#define MPC85xx_OPENPIC_IRQ_OFFSET 64
-#endif
-
-/* The 32 internal sources */
-#define MPC85xx_IRQ_L2CACHE ( 0 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_ECM ( 1 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DDR ( 2 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_LBIU ( 3 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA0 ( 4 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA1 ( 5 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA2 ( 6 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DMA3 ( 7 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PCI1 ( 8 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PCI2 ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_ERROR ( 9 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_BELL (10 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_TX (11 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_RIO_RX (12 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_TX (13 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_RX (14 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC1_ERROR (18 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_TX (19 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_RX (20 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_TSEC2_ERROR (24 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_FEC (25 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_DUART (26 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_IIC1 (27 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_PERFMON (28 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_SEC2 (29 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_CPM (30 + MPC85xx_OPENPIC_IRQ_OFFSET)
-
-/* The 12 external interrupt lines */
-#define MPC85xx_IRQ_EXT0 (32 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT1 (33 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT2 (34 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT3 (35 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT4 (36 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT5 (37 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT6 (38 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT7 (39 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT8 (40 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT9 (41 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT10 (42 + MPC85xx_OPENPIC_IRQ_OFFSET)
-#define MPC85xx_IRQ_EXT11 (43 + MPC85xx_OPENPIC_IRQ_OFFSET)
-
/* Offset from CCSRBAR */
#define MPC85xx_CPM_OFFSET (0x80000)
#define MPC85xx_CPM_SIZE (0x40000)
^ permalink raw reply
* Re: PCI support under 2.6.11.4 on MPC8272ADS ???
From: Andrei Konovalov @ 2005-03-29 16:41 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: linuxppc-embedded
In-Reply-To: <1112112084.26645.27.camel@excalibur.timesys.com>
Walter L. Wimer III wrote:
> Thanks to all who offered suggestions regarding PCI on the MPC8272ADS.
> I too suspected that the PCI bus frequency may have been the problem,
> and even spent some time looking at the clock configuration in the
> Freescale documentation before I posted my message. The documentation
> seemed very confusing, so I decided to pursue a few different avenues in
> parallel, including posting to the list.
>
> Since Andrei and Vitaly further implicated the bus frequency, I went
> back and took a closer look at it. After much staring at the
> documentation, dumping registers, trying a 66MHz-capable card, etc. I
> can report that this was indeed the problem. A 66MHz-capable Promise
> IDE controller card does seem to work.
>
> I'd like to change the bus speed to <= 33MHz, but this still looks non-
> trivial. If I understand things properly, it looks like my best bet is
> to modify the Hard Reset Configuration Word in flash to set the
> PCI_MODCK bit to "low range" (25 to 50 MHz, instead of 50 to 66 MHz).
>
> Can anyone confirm my understanding?
Yes, we've used HRCW of 0x0c72361a.
BTW, I guess it sould be rather simple to modify the CPLD
to set the PCI_MODCK to "low range" if at least one of the PCI
cards inserted is not 66MHz capable.
Something like
CfgByte3 = [0,0,0,!BCSR4.M66EN,ModckH0,ModckH1,ModckH2,ModckH3];
(this is not the correct code for the CPLD, but illustrates the idea).
Thanks,
Andrei
> Thanks again!
>
> Walt
>
>
>
> On Fri, 2005-03-25 at 17:07 +0300, Vitaly Bordug wrote:
>
>>Hi Walt,
>>
>>Well, the incorrect VendorID almost clearly points to the incompatible
>>PCI bus frequency - try to set it to 33Mhz.
>>AFAIR, I saw my network card as video adapter in the lspci output.
>>
>>The 2.4 stuff was tested rather thoroughly. The current 2.6.11 support
>>is examined with HPT370 and PDC20268 PCI IDE.
>>
>>You may also try my latest patch to the stock linux 2.5.
>>
>>Wimer, Walt wrote:
>>
>>>Using Vitaly's 2.4-based patch below as a starting point, I've been
>>>adding PCI support to 2.6.11.4 for the MPC8272ADS board.
>>>
>>>The good news is that I think I have PCI interrupts pretty well sorted
>>>out, and I see *something* half-way reasonable from "lspci".
>>>
>>>The bad news is that neither of the ethernet cards that I'm trying will
>>>actually work, and I see some very weird behavior with PCI configuration
>>>space:
>>>
>>> Card 1: Some Realtek RTL8139D-based card
>>> Card 2: NETGEAR FA311 (National Semi DP83815 chip)
>>>
>>>With either card installed alone, both U-Boot and my kernel identify the
>>>cards correctly in PCI configuration space.
>>>
>>>With *both* cards installed, both U-Boot and my kernel see the Realtek-
>>>based card correctly, but the NETGEAR card has a corrupted Vendor ID
>>>(e.g. 0x1000 or 0x1003 instead of the correct 0x100b). This happens
>>>regardless of which PCI slots I use for the cards (I've tried virtually
>>>every combination). This smells of a power problem or something to me.
>>>
>>>And again, even with either card alone, the drivers have serious
>>>problems talking to the cards. I get various error messages from
>>>the drivers and I see badly mangled packets on the wire. It's also
>>>not uncommon for the whole system to freeze...
>>>
>>>Has anyone else seen similar behavior?
>>>
>>>Has anyone had success with PCI on this board (under any kernel
>>>version)?
>>>
>>>
>>>Any ideas / data points are appreciated.
>>>
>>>
>>>Thanks!!!
>>>
>>>Walt Wimer
>>>
>>>
>>>
>>>
>>>
>>>>This patch adds PCI bridge support for MPC8272 and PQ2FADS to the
>>>>current linuxppc-2.4 tree. Actually it has been tested with 8272, but
>>>>PQ2 _should_ also work, though it will complain that host bridge ID is
>>>>unrecognized.
>>>>
>>>>Signed-off-by: Vitaly Bordug <vbordug at ru.mvista.com>
>>>>
>>>>--
>>>>Sincerely, Vitaly
>>>>
>>>>-------------- next part --------------
>>>>A non-text attachment was scrubbed...
>>>>Name: pq2-pci.patch
>>>>Type: text/x-patch
>>>>Size: 20111 bytes
>>>>Desc: not available
>>>>Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050218/12060ce8/pq2-pci.bin
>>>>
>>>
>>>
>>>
>>
>>--
>>Sincerely,
>>Vitaly
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] ppc32: Fix MPC8555 & MPC8555E device lists
From: Kumar Gala @ 2005-03-29 16:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Andrew,
Removed the FCC3 device from the lists of devices on MPC8555 & MPC8555E
since it does not exist on these processors.
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/mpc85xx_sys.c b/arch/ppc/syslib/mpc85xx_sys.c
--- a/arch/ppc/syslib/mpc85xx_sys.c 2005-03-29 10:26:41 -06:00
+++ b/arch/ppc/syslib/mpc85xx_sys.c 2005-03-29 10:26:41 -06:00
@@ -88,7 +88,7 @@
MPC85xx_PERFMON, MPC85xx_DUART,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
- MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
},
@@ -105,7 +105,7 @@
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
- MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
},
^ permalink raw reply
* Re: PCI support under 2.6.11.4 on MPC8272ADS ???
From: Walter L. Wimer III @ 2005-03-29 16:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <42441B13.7080703@ru.mvista.com>
Thanks to all who offered suggestions regarding PCI on the MPC8272ADS.
I too suspected that the PCI bus frequency may have been the problem,
and even spent some time looking at the clock configuration in the
Freescale documentation before I posted my message. The documentation
seemed very confusing, so I decided to pursue a few different avenues in
parallel, including posting to the list.
Since Andrei and Vitaly further implicated the bus frequency, I went
back and took a closer look at it. After much staring at the
documentation, dumping registers, trying a 66MHz-capable card, etc. I
can report that this was indeed the problem. A 66MHz-capable Promise
IDE controller card does seem to work.
I'd like to change the bus speed to <= 33MHz, but this still looks non-
trivial. If I understand things properly, it looks like my best bet is
to modify the Hard Reset Configuration Word in flash to set the
PCI_MODCK bit to "low range" (25 to 50 MHz, instead of 50 to 66 MHz).
Can anyone confirm my understanding?
Thanks again!
Walt
On Fri, 2005-03-25 at 17:07 +0300, Vitaly Bordug wrote:
> Hi Walt,
>
> Well, the incorrect VendorID almost clearly points to the incompatible
> PCI bus frequency - try to set it to 33Mhz.
> AFAIR, I saw my network card as video adapter in the lspci output.
>
> The 2.4 stuff was tested rather thoroughly. The current 2.6.11 support
> is examined with HPT370 and PDC20268 PCI IDE.
>
> You may also try my latest patch to the stock linux 2.5.
>
> Wimer, Walt wrote:
> > Using Vitaly's 2.4-based patch below as a starting point, I've been
> > adding PCI support to 2.6.11.4 for the MPC8272ADS board.
> >
> > The good news is that I think I have PCI interrupts pretty well sorted
> > out, and I see *something* half-way reasonable from "lspci".
> >
> > The bad news is that neither of the ethernet cards that I'm trying will
> > actually work, and I see some very weird behavior with PCI configuration
> > space:
> >
> > Card 1: Some Realtek RTL8139D-based card
> > Card 2: NETGEAR FA311 (National Semi DP83815 chip)
> >
> > With either card installed alone, both U-Boot and my kernel identify the
> > cards correctly in PCI configuration space.
> >
> > With *both* cards installed, both U-Boot and my kernel see the Realtek-
> > based card correctly, but the NETGEAR card has a corrupted Vendor ID
> > (e.g. 0x1000 or 0x1003 instead of the correct 0x100b). This happens
> > regardless of which PCI slots I use for the cards (I've tried virtually
> > every combination). This smells of a power problem or something to me.
> >
> > And again, even with either card alone, the drivers have serious
> > problems talking to the cards. I get various error messages from
> > the drivers and I see badly mangled packets on the wire. It's also
> > not uncommon for the whole system to freeze...
> >
> > Has anyone else seen similar behavior?
> >
> > Has anyone had success with PCI on this board (under any kernel
> > version)?
> >
> >
> > Any ideas / data points are appreciated.
> >
> >
> > Thanks!!!
> >
> > Walt Wimer
> >
> >
> >
> >
> > > This patch adds PCI bridge support for MPC8272 and PQ2FADS to the
> > > current linuxppc-2.4 tree. Actually it has been tested with 8272, but
> > > PQ2 _should_ also work, though it will complain that host bridge ID is
> > > unrecognized.
> > >
> > > Signed-off-by: Vitaly Bordug <vbordug at ru.mvista.com>
> > >
> > > --
> > > Sincerely, Vitaly
> > >
> > > -------------- next part --------------
> > > A non-text attachment was scrubbed...
> > > Name: pq2-pci.patch
> > > Type: text/x-patch
> > > Size: 20111 bytes
> > > Desc: not available
> > > Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050218/12060ce8/pq2-pci.bin
> > >
> >
> >
> >
>
> --
> Sincerely,
> Vitaly
^ permalink raw reply
* RE: Problem running Linux 2.6.11 on MPC8272ADS
From: Walter L. Wimer III @ 2005-03-29 15:44 UTC (permalink / raw)
To: Bastos Fernandez Alexandre; +Cc: linuxppc-embedded
In-Reply-To: <51DB8827D393D411BB69003048003F4601B1C1CE@tvesntr>
Thanks for the data points, Alex.
I'm using U-Boot 1.1.1 and vanilla kernel.org 2.6.11.4 (actually now
2.6.11.5). My BCSR_ADDR looks the same as what you've listed below, so
I'd guess the difference is with U-Boot... (Another engineer here
installed U-Boot on my board, from, I believe, a binary copy he got from
a Freescale(?) CD... I didn't build U-Boot from source... That's
something I'll need to take a look at...)
Mike, have you discovered anything further about your problem?
Walt
On Tue, 2005-03-29 at 08:29 +0200, Bastos Fernandez Alexandre wrote:
> Hi,
>
> >From "linux/arch/ppc/platforms/pq2ads.h"
> #define BCSR_ADDR ((uint) 0xf4500000)
> >From "u-boot/include/configs/MPC8260ADS.h"
> #define CFG_BCSR 0xF4500000
> So ...
> Which version of u-boot and/or linux tree are you using?
> With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
> Maybe Mike's problem is other. Maybe not. :-)
>
> Best regards,
> Alex
>
> > -----Original Message-----
> > From: Walter L. Wimer III [SMTP:walt.wimer@timesys.com]
> > Sent: Monday, March 28, 2005 6:07 PM
> > To: Mike Rapoport
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
> >
> >
> > Hi Mike,
> >
> > I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> > contains the following function:
> >
> > void __init
> > m82xx_board_setup(void)
> > {
> > /* Enable the 2nd UART port */
> > *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> > }
> >
> >
> > I had to ifdef-out the assignment statement above. It appears that the
> > definition for BCSR_ADDR in the kernel code differs from what U-Boot is
> > using, and that area of memory isn't properly mapped into the kernel
> > address space this early in the boot sequence. As a result, I was
> > getting an Oops() before the console was even enabled (I could see the
> > Oops message by examining the kernel's printk log buffer using a
> > BDI-2000 hardware debugger).
> >
> >
> >
> > Good luck,
> >
> > Walt Wimer
> > TimeSys Corporation
> >
> >
> >
> >
> > On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > > Hi,
> > > I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> > > hang up at the very beginning.
> > > I use ads8272_defconfig and then enable console on SCC:
> > >
> > > CONFIG_SERIAL_CPM=y
> > > CONFIG_SERIAL_CPM_CONSOLE=y
> > > CONFIG_SERIAL_CPM_SCC1=y
> > >
> > >
> > > when I boot the kernel from the u-boot the system hangs up right after
> > > the kernel decompression.
> > >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: how to get a embbed linux for MPC8240 which core is 603e
From: Jerry Van Baren @ 2005-03-29 15:14 UTC (permalink / raw)
To: inuxppc-embedded
In-Reply-To: <42496C68.60603@centecnetworks.com>
Anchor wrote:
> Hi everbody:
>
> I am a new guy, I want get a ready embedded linux for Motorala
> ppc8245, give me a hand.
>
> Thank you very much!
>
> anchor xie
CLAP CLap Clap clap
Wolfgang Denk has a very good turn-key system "Embedded Linux
Development Kit" (ELDK). Download it and install it -- it is a very
painless way to get started with a cross (or native) development system.
<http://denx.de/e/index1.php>
Read the documentation on his site!
<http://denx.de/e/index1.php?head=docs-head&main=docs&subnav=docs-subnav&logo=logo-se&mainnav=docsnav&bottom=bottom-se>
...especially the very useful " DENX Guide to U-Boot and Embedded Linux"
<http://www.denx.de/twiki/bin/view/DULG/Manual>
READ the FAQ! Re-read the FAQ!
<http://www.denx.de/twiki/bin/view/DULG/Faq>
If you need a boot loader, u-boot is a very good way to go.
<http://sourceforge.net/projects/u-boot>
(Wolfgang is the maintainer).
gvb
^ permalink raw reply
* when to do ioremap?
From: Garcia Jérémie @ 2005-03-29 15:10 UTC (permalink / raw)
To: linuxppc-dev
Ladies and Gentlemen,
Even if I am a Linux kernel newbie, I'm in charge of adapting a =
Montavista LSP (designed for the IBM 405EP evaluation board) to our =
propietary hardware which uses a 405EP too.
So, I created both files /arch/ppc/platforms/myBoard.c and myBoard.h =
first copying the LSP files and then modifying them.=20
However, you guess that our mapping is very different from the one used =
by the IBM eval board. The fact is that I'm not at all familiar with =
memory management (I'm a part time student/worker) and I try to =
understand the board_setup_arch function provided by the LSP (cf. =
below). I understand that the ioremap allows us to build new page tables =
mapping physical addresses on a range of contiguous (linear) virtual =
addresses. But why are we doing that at that early boot time and not in =
a driver at a wanted time? In the IBM eval board case, only 2 fpga =
registers are used but on my board, we are using up to 4K for our I/O =
space (segmented in 4 different part -> ex: =
engineer_purpose_regs,appli_regs, asic_regs,..). Then we have a software =
that must play with those registers from the user-space.
So could you explain me the original file to help me coding the new one. =
I definitely don't understand what are the consequences of that (the =
function return is void,nothing is done with the returns of ioremap =
calls except test). Does it allow us to do something later? Couldn't we =
do all of that in a driver or is there a serious reason to do it here?
void __init
board_setup_arch(void)
{
#define EVB405EP_FPGA_BASE 0xF0300000
void *fpga_reg0;
void *fpga_reg1;
evb405ep_early_serial_map();
fpga_reg0 =3D ioremap(EVB405EP_FPGA_BASE, 8);
if (!fpga_reg0) {
printk(KERN_CRIT
"evb405ep_setup_arch() fpga_reg0 ioremap =
failed\n");
return;
}
fpga_reg1 =3D fpga_reg0 + 1;
}
Hoping that the question is not too stupid : tks a lot everyone for =
helping a student lost in the linux kernel sources... :-)=20
^ permalink raw reply
* how to get a embbed linux for MPC8240 which core is 603e
From: Anchor @ 2005-03-29 14:55 UTC (permalink / raw)
To: inuxppc-embedded
Hi everbody:
I am a new guy, I want get a ready embedded linux for Motorala
ppc8245, give me a hand.
Thank you very much!
anchor xie
03-29-2005
^ permalink raw reply
* [PATCH 4/91] get rid of pci_find_{device,subsys} arch/ppc
From: Amit Gud @ 2005-03-29 12:22 UTC (permalink / raw)
To: greg; +Cc: linuxppc-dev, paulus, gud
Replace pci_find_{device,subsys} with pci_get_{device,subsys}.
Signed-off-by: Amit Gud <gud@eth.net>
---
diff -upr orig-2.6.12-rc1/arch/ppc/kernel/pci.c work-2.6.12-rc1/arch/ppc/kernel/pci.c
--- orig-2.6.12-rc1/arch/ppc/kernel/pci.c 2005-03-22 12:53:17.000000000 +0530
+++ work-2.6.12-rc1/arch/ppc/kernel/pci.c 2005-03-24 15:39:21.107111456 +0530
@@ -503,7 +503,7 @@ pcibios_allocate_resources(int pass)
u16 command;
struct resource *r;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
pci_read_config_word(dev, PCI_COMMAND, &command);
for (idx = 0; idx < 6; idx++) {
r = &dev->resource[idx];
@@ -519,7 +519,7 @@ pcibios_allocate_resources(int pass)
alloc_resource(dev, idx);
}
if (pass)
- continue;
+ goto dev_put;
r = &dev->resource[PCI_ROM_RESOURCE];
if (r->flags & PCI_ROM_ADDRESS_ENABLE) {
/* Turn the ROM off, leave the resource region, but keep it unregistered. */
@@ -530,6 +530,8 @@ pcibios_allocate_resources(int pass)
pci_write_config_dword(dev, dev->rom_base_reg,
reg & ~PCI_ROM_ADDRESS_ENABLE);
}
+ dev_put:
+ pci_dev_put(dev);
}
}
@@ -540,12 +542,12 @@ pcibios_assign_resources(void)
int idx;
struct resource *r;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
int class = dev->class >> 8;
/* Don't touch classless devices and host bridges */
if (!class || class == PCI_CLASS_BRIDGE_HOST)
- continue;
+ goto dev_put;
for (idx = 0; idx < 6; idx++) {
r = &dev->resource[idx];
@@ -571,6 +573,8 @@ pcibios_assign_resources(void)
if (r->end)
pci_assign_resource(dev, PCI_ROM_RESOURCE);
#endif
+ dev_put:
+ pci_dev_put(dev);
}
}
@@ -866,13 +870,18 @@ pci_device_from_OF_node(struct device_no
*/
if (!pci_to_OF_bus_map)
return 0;
- while ((dev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
+ while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
if (pci_to_OF_bus_map[dev->bus->number] != *bus)
- continue;
+ goto dev_put;
if (dev->devfn != *devfn)
- continue;
+ goto dev_put;
+
*bus = dev->bus->number;
+ pci_dev_put(dev);
return 0;
+
+ dev_put:
+ pci_dev_put(dev);
}
return -ENODEV;
}
^ permalink raw reply
* Re: MPC885 CryptoApi support.
From: Eran Mann @ 2005-03-29 10:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: bdonadt, 'linuxppc-embedded '
In-Reply-To: <20050329104340.70E0EC108D@atlas.denx.de>
Wolfgang Denk wrote:
> In message <42492C93.2060906@eircom.net> you wrote:
>
>>If it is the case that you have provided a GPL-Arabella-Linux-Kernel, to
>>a customer and all the code is GPL compliant, then that customer, is
>>*free* to fork and/or redistribute that code, which seems like a bit of
>>an oxymoron, for a commercial offering !
>
>
> Maybe we should start a collect to buy one "license" and put it on a
> FTP server :-)
>
> Best regards,
>
> Wolfgang Denk
>
Sure, and while we're at it, why not do the same for MontaVista kernel,
Metrowerks kernel, etc...
--
Eran Mann
MRV International
www.mrv.com
^ 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