* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Mohammad Sadegh Sadri @ 2008-03-17 9:03 UTC (permalink / raw)
To: Stephen Neuendorffer, Koss, Mike (Mission Systems),
linuxppc-embedded
In-Reply-To: <20080316214832.3F77A538046@mail141-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 5247 bytes --]
Ok, thanks for guidance,
by the way it is interesting for me to hear about EDK 10.1 from u steve,
EDK 9.2 has been around just for a little time and you are going to 10.1?
What about future plan of xilinx about Virtex-5 FX? does this tool consider that?
the future plan is really important for our development team. let me give a simple example, our dev team worked on the design of our system based on PLB and OPB buses for some thing near 6 month, just then EDK 9.2.02 released and suddenly we forced to change all of the designs and to define new activities specially focusing on MPMC. we did never consider MPMC before, but the release of EDK 9.2 changed every thing.
Now, that would be nice, if we can know your future plan a little, that would help us to generate correct and real gant charts. and to assign human resources correctly. this is also true for the project budget. We know that Virtex-5 devices are really capable of doing better things than Virtex-4, specially the PCI express option is great and very usable for us, but we have not moved to virtex-5 yet, because there is no FX series or at least we do not know your plan about it. Our managers we seriously asking us if we have to move to Virtex-5 soon, we did not have any reasonable answer for them because we do not have any info from u at all.
thanks
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
Date: Sun, 16 Mar 2008 14:43:33 -0700
From: stephen.neuendorffer@xilinx.com
To: mike.koss@ngc.com; mamsadegh@hotmail.com; linuxppc-embedded@ozlabs.org
RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
Ah, thanks mike... you knocked the answer loose out of my brain...
In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary.
The platform data structure contains entries for both, with the correct ones being ignored. In order to get the code to compile, there are some defines in xparameters.h which have:
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif
after including xparameter_ml403.h
I'm guessing maybe you overwrote the xparameters.h file and got rid of these redefines? You can define it to be whatever you want, since the value will be ignored if you are using SDMA.
In EDK 10.1, the BSP generator will always generate all the defines (even ones which are not sensible in the current configuration), which avoids the above annoyances.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.
thanks
________________________________
Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
_________________________________________________________________
Like solving puzzles? Then you'll love Flexicon! Play now!
http://g.msn.ca/ca55/213
[-- Attachment #2: Type: text/html, Size: 5973 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix PMU + soft interrupt disable bug
From: Benjamin Herrenschmidt @ 2008-03-17 8:51 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080317042709.GA10594@kryten>
On Sun, 2008-03-16 at 23:27 -0500, Anton Blanchard wrote:
> Since the PMU is an NMI now, it can come at any time we are only soft
> disabled. We must hard disable around the two places we allow the kernel
> stack SLB and r1 to go out of sync. Otherwise the PMU exception can
> force a kernel stack SLB into another slot.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> ---
>
> Index: kernel/arch/powerpc/mm/slb.c
> ===================================================================
> --- kernel.orig/arch/powerpc/mm/slb.c 2007-11-05 11:22:03.000000000 -0600
> +++ kernel/arch/powerpc/mm/slb.c 2007-11-05 18:09:45.000000000 -0600
> @@ -113,6 +113,12 @@ void slb_flush_and_rebolt(void)
> slb_shadow_update(get_paca()->kstack, lflags, 2);
> }
>
> + /*
> + * We can't take a PMU exception in the following code, so hard
> + * disable interrupts.
> + */
> + hard_irq_disable();
> +
> /* We need to do this all in asm, so we're sure we don't touch
> * the stack between the slbia and rebolting it. */
> asm volatile("isync\n"
> Index: kernel/arch/powerpc/kernel/process.c
> ===================================================================
> --- kernel.orig/arch/powerpc/kernel/process.c 2007-11-05 18:10:44.000000000 -0600
> +++ kernel/arch/powerpc/kernel/process.c 2007-11-05 18:10:46.000000000 -0600
> @@ -331,6 +331,12 @@ struct task_struct *__switch_to(struct t
> account_process_vtime(current);
> calculate_steal_time();
>
> + /*
> + * We can't take a PMU exception inside _switch() since there is a
> + * window where the kernel stack SLB and the kernel stack are out
> + * of sync. Hard disable here.
> + */
> + hard_irq_disable();
> last = _switch(old_thread, new_thread);
>
> local_irq_restore(flags);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 43, Issue 27
From: Antoine BRUNET @ 2008-03-17 8:02 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: mamsadegh
In-Reply-To: <mailman.1.1205629203.1697.linuxppc-embedded@ozlabs.org>
Hi,
Your problem is simple, you just have to add one interruption in your BSP
EDK.
Regerate the bitstream and xparamters. And compile your kernel with the new
xparameters file.
And it will be ok.
Date: Sat, 15 Mar 2008 08:30:31 +0000
From: Mohammad Sadegh Sadri <mamsadegh@hotmail.com>
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS
LLTEMAC
To: <linuxppc-embedded@ozlabs.org>
Message-ID: <BAY115-W186EA84A950C17657AD8D9B20B0@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components, I generate the software libraries
and copy xparameters file into proper kernel folder. I configure that kernel
and add kernel support for XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h file
but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel compilation,
don't know the correct value for it of course.
thanks
_________________________________________________________________
Create a handy button so your friends can add U to their buddy list. Try it
now!
http://g.msn.ca/ca55/211
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20080315/565821b8
/attachment.html>
------------------------------
^ permalink raw reply
* XUPV2P board opb_emac cannot work with linux-2.6-xlnx
From: Qin Lin @ 2008-03-17 7:35 UTC (permalink / raw)
To: linuxppc-embedded
HI all,
Is anyone have the opb_emac (no DMA) work with the kernel linux-2.6-xlnx
from git.xilinx.com.
the message seams that it does work ,but the command ping return nothing!
Could you kindly suggest me what to do?
ps:
the kernel booting message
[ 0.258674] net_namespace: 64 bytes
[ 0.269780] NET: Registered protocol family 16
[ 0.290415] Registering device xilinx_emac:0
[ 0.381687] NET: Registered protocol family 2
[ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
bytes)
[ 0.399556] TCP established hash table entries: 8192 (order: 4, 65536
bytes)
[ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.405409] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.405489] TCP reno registered
[ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
strategy
[ 0.413189] Call Trace:
[ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184 (unreliable)
[ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
[ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
[ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
[ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
[ 0.414141] [cf41ff70] [c01e4b1c] register_ppc_htab_sysctl+0x18/0x2c
[ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
[ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
[ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0: 0: 0:
0
[ 1.123790] XEmac: using fifo mode.
[ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
0x78e2.
[ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
[ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to 0xD0020000,
irq=2
[ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
[ 1.194661] TCP cubic registered
[ 1.198647] NET: Registered protocol family 1
[ 1.203728] NET: Registered protocol family 17
#ping 192.168.26.1 &
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
inet addr:192.168.26.127 Bcast:192.168.26.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
Interrupt:2 Memory:40c00000-40c0ffff
Regards
Qin Lin
--
View this message in context: http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-tp16089631p16089631.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Kernel stack overflow in process xxxx
From: jay_chen @ 2008-03-17 7:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <017e01c887fe$41395b20$016ffea9@alphajay>
By the way, is there any skill/tool to avoid/detect/check this kind of
problem?
Jay Chen...
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Monday, March 17, 2008 3:12 PM
To: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] Kernel stack overflow in process xxxx (This message
should be blocked: ctfkl59804)
Hello all:
I am using mpc8548 and, kernel 2.6.14.5.
Recently, my system encounter "Kernel stack overflow in process xxxx"
problem.
How to increase the kernel stack size?
I try to modify THREAD_SIZE in thread_info.h, but my system seems couldn't
boot up anymore!
//#define THREAD_SIZE 8192 /* 2 pages */
#define THREAD_SIZE 16384 /* 4 pages */
Thanks in advance for any kind of advice.
Jay Chen...
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Kernel stack overflow in process xxxx
From: jay_chen @ 2008-03-17 7:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello all:
I am using mpc8548 and, kernel 2.6.14.5.
Recently, my system encounter "Kernel stack overflow in process xxxx"
problem.
How to increase the kernel stack size?
I try to modify THREAD_SIZE in thread_info.h, but my system seems couldn't
boot up anymore!
//#define THREAD_SIZE 8192 /* 2 pages */
#define THREAD_SIZE 16384 /* 4 pages */
Thanks in advance for any kind of advice.
Jay Chen...
^ permalink raw reply
* dtc: Cleanup \nnn and \xNN string escape handling
From: David Gibson @ 2008-03-17 6:03 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Several small cleanups to the handling of octal and hex string
escapes:
- Use strncmp() instead dof what were essentially open-coded
versions of the same, with short fixed lengths.
- The call path to get_oct_char() means an empty escape is not
possible. So replace the error message in this case with an
assert.
- Use die() instead of a non-fatal error message if
get_hex_char() is given an empty escape. Change error
message to close match gcc's in the same circumstance.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
data.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2008-03-17 16:37:04.000000000 +1100
+++ dtc/data.c 2008-03-17 16:37:04.000000000 +1100
@@ -75,16 +75,11 @@ static char get_oct_char(const char *s,
long val;
x[3] = '\0';
- x[0] = s[(*i)];
- if (x[0]) {
- x[1] = s[(*i)+1];
- if (x[1])
- x[2] = s[(*i)+2];
- }
+ strncpy(x, s + *i, 3);
val = strtol(x, &endx, 8);
- if ((endx - x) == 0)
- fprintf(stderr, "Empty \\nnn escape\n");
+
+ assert(endx > x);
(*i) += endx - x;
return val;
@@ -97,13 +92,11 @@ static char get_hex_char(const char *s,
long val;
x[2] = '\0';
- x[0] = s[(*i)];
- if (x[0])
- x[1] = s[(*i)+1];
+ strncpy(x, s + *i, 2);
val = strtol(x, &endx, 16);
- if ((endx - x) == 0)
- fprintf(stderr, "Empty \\x escape\n");
+ if (!(endx > x))
+ die("\\x used with no following hex digits\n");
(*i) += endx - x;
return val;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 2.6.26] Update wait_state_cycles in the VPA.
From: Tony Breeds @ 2008-03-17 5:23 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
The hypervisor can look at the value in wait_state_cycles for an estimate of
how busy dedicated processors are. Currently as the kernel never touches this
field so we appear to be 100% busy. Record the duration the kernel is in
powersave and pass that to the HV to provide a reasonable indication of
utilisation.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/setup.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index fdb9b1c..90555a3 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -393,6 +393,7 @@ static void pseries_dedicated_idle_sleep(void)
{
unsigned int cpu = smp_processor_id();
unsigned long start_snooze;
+ unsigned long in_purr, out_purr;
/*
* Indicate to the HV that we are idle. Now would be
@@ -400,6 +401,7 @@ static void pseries_dedicated_idle_sleep(void)
*/
get_lppaca()->idle = 1;
get_lppaca()->donate_dedicated_cpu = 1;
+ in_purr = mfspr(SPRN_PURR);
/*
* We come in with interrupts disabled, and need_resched()
@@ -432,6 +434,8 @@ static void pseries_dedicated_idle_sleep(void)
out:
HMT_medium();
+ out_purr = mfspr(SPRN_PURR);
+ get_lppaca()->wait_state_cycles += out_purr - in_purr;
get_lppaca()->donate_dedicated_cpu = 0;
get_lppaca()->idle = 0;
}
--
1.5.4.3
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply related
* [PATCH] powerpc exec PT_DTRACE
From: Roland McGrath @ 2008-03-17 5:01 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
The PT_DTRACE flag is meaningless and obsolete.
Don't touch it.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/process.c | 5 -----
arch/powerpc/kernel/sys_ppc32.c | 5 -----
2 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 4846bf5..7c8e3da 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -862,11 +862,6 @@ int sys_execve(unsigned long a0, unsigned long a1, unsigned long a2,
flush_spe_to_thread(current);
error = do_execve(filename, (char __user * __user *) a1,
(char __user * __user *) a2, regs);
- if (error == 0) {
- task_lock(current);
- current->ptrace &= ~PT_DTRACE;
- task_unlock(current);
- }
putname(filename);
out:
return error;
diff --git a/arch/powerpc/kernel/sys_ppc32.c b/arch/powerpc/kernel/sys_ppc32.c
index 4a4f5c6..9c3371e 100644
--- a/arch/powerpc/kernel/sys_ppc32.c
+++ b/arch/powerpc/kernel/sys_ppc32.c
@@ -368,11 +368,6 @@ long compat_sys_execve(unsigned long a0, unsigned long a1, unsigned long a2,
error = compat_do_execve(filename, compat_ptr(a1), compat_ptr(a2), regs);
- if (error == 0) {
- task_lock(current);
- current->ptrace &= ~PT_DTRACE;
- task_unlock(current);
- }
putname(filename);
out:
^ permalink raw reply related
* [PATCH] Fix PMU + soft interrupt disable bug
From: Anton Blanchard @ 2008-03-17 4:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Since the PMU is an NMI now, it can come at any time we are only soft
disabled. We must hard disable around the two places we allow the kernel
stack SLB and r1 to go out of sync. Otherwise the PMU exception can
force a kernel stack SLB into another slot.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: kernel/arch/powerpc/mm/slb.c
===================================================================
--- kernel.orig/arch/powerpc/mm/slb.c 2007-11-05 11:22:03.000000000 -0600
+++ kernel/arch/powerpc/mm/slb.c 2007-11-05 18:09:45.000000000 -0600
@@ -113,6 +113,12 @@ void slb_flush_and_rebolt(void)
slb_shadow_update(get_paca()->kstack, lflags, 2);
}
+ /*
+ * We can't take a PMU exception in the following code, so hard
+ * disable interrupts.
+ */
+ hard_irq_disable();
+
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
asm volatile("isync\n"
Index: kernel/arch/powerpc/kernel/process.c
===================================================================
--- kernel.orig/arch/powerpc/kernel/process.c 2007-11-05 18:10:44.000000000 -0600
+++ kernel/arch/powerpc/kernel/process.c 2007-11-05 18:10:46.000000000 -0600
@@ -331,6 +331,12 @@ struct task_struct *__switch_to(struct t
account_process_vtime(current);
calculate_steal_time();
+ /*
+ * We can't take a PMU exception inside _switch() since there is a
+ * window where the kernel stack SLB and the kernel stack are out
+ * of sync. Hard disable here.
+ */
+ hard_irq_disable();
last = _switch(old_thread, new_thread);
local_irq_restore(flags);
^ permalink raw reply
* [PATCH v2] Force 4K pages for IO addresses.
From: Tony Breeds @ 2008-03-17 3:54 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev; +Cc: Stephen Rothwell, Jan-Bernd Themann
In-Reply-To: <20080317034758.GG6887@bakeyournoodle.com>
Currently HEA requires 4K pages for IO resources. Just set the pages size to
IO to 4K.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
* Updated the comment aswell, sorry.
* Paul please consider this for 2.6.25
arch/powerpc/mm/hash_utils_64.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
Fixes the following ooops:
Unable to handle kernel paging request for data at address 0xd00008008006c040
Faulting instruction address: 0xc000000000336b08
Oops: Kernel access of bad area, sig: 7 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c000000000336b08 LR: c000000000336aac CTR: 8000000000138240
REGS: c0000000fcef3190 TRAP: 0300 Not tainted (2.6.25-rc5.20080317-143135)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000442 XER: 00000020
DAR: d00008008006c040, DSISR: 0000000042000000
TASK = c0000000fc979190[2781] 'ifconfig' THREAD: c0000000fcef0000 CPU: 7
GPR00: 8000000000000000 c0000000fcef3410 c0000000009cf350 0000000000000000
GPR04: 0000000000000005 0000000000000000 c0000000fc470e50 0000000000000000
GPR08: c0000000fc11fc00 d00008008006c040 f000ffffffffffff 0000000000000000
GPR12: 0000000000000000 c0000000008aed80 0000000028004422 0000000000000000
GPR16: 0000000010120588 00000000100d0000 00000000100b0000 00000000100d0000
GPR20: 0000000010010474 c0000000fea08000 c0000000fcef3cd0 0000000000008914
GPR24: 0000000000000000 0000000000000000 c0000000fe02e000 0000000000000060
GPR28: 0000000000000060 0000000000000000 c00000000094afa8 c0000000fc470e40
NIP [c000000000336b08] .ehea_create_cq+0x1c4/0x26c
LR [c000000000336aac] .ehea_create_cq+0x168/0x26c
Call Trace:
[c0000000fcef3410] [c000000000336aac] .ehea_create_cq+0x168/0x26c (unreliable)
[c0000000fcef34b0] [c00000000032efc4] .ehea_init_port_res+0xd0/0x4c0
[c0000000fcef3570] [c000000000331ba8] .ehea_up+0x134/0x754
[c0000000fcef3670] [c0000000003323c4] .ehea_open+0x84/0x104
[c0000000fcef3710] [c0000000004d55a0] .dev_open+0xb8/0x128
[c0000000fcef37a0] [c0000000004d53e0] .dev_change_flags+0x110/0x218
[c0000000fcef3840] [c000000000528db0] .devinet_ioctl+0x2d4/0x76c
[c0000000fcef3940] [c0000000005293a8] .inet_ioctl+0xe0/0x130
[c0000000fcef39c0] [c0000000004c4590] .sock_ioctl+0x2c0/0x314
[c0000000fcef3a60] [c0000000000fb970] .vfs_ioctl+0x5c/0xf0
[c0000000fcef3b00] [c0000000000fbe34] .do_vfs_ioctl+0x430/0x460
[c0000000fcef3bb0] [c0000000000fbeb0] .sys_ioctl+0x4c/0x88
[c0000000fcef3c60] [c00000000012c364] .dev_ifsioc+0x138/0x324
[c0000000fcef3d40] [c00000000012fdbc] .compat_sys_ioctl+0x398/0x428
[c0000000fcef3e30] [c000000000008748] syscall_exit+0x0/0x40
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 32f4161..8b2c978 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -340,20 +340,17 @@ static void __init htab_init_page_sizes(void)
/*
* Pick a size for the ordinary pages. Default is 4K, we support
* 64K for user mappings and vmalloc if supported by the processor.
- * We only use 64k for ioremap if the processor
- * (and firmware) support cache-inhibited large pages.
- * If not, we use 4k and set mmu_ci_restrictions so that
- * hash_page knows to switch processes that use cache-inhibited
- * mappings to 4k pages.
+ * We always use 4k for ioremap, however if the processor
+ * (and firmware) support cache-inhibited large pages we set
+ * mmu_ci_restrictions so that hash_page knows to switch processes that
+ * use cache-inhibited mappings to 4k pages.
*/
if (mmu_psize_defs[MMU_PAGE_64K].shift) {
mmu_virtual_psize = MMU_PAGE_64K;
mmu_vmalloc_psize = MMU_PAGE_64K;
if (mmu_linear_psize == MMU_PAGE_4K)
mmu_linear_psize = MMU_PAGE_64K;
- if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
- mmu_io_psize = MMU_PAGE_64K;
- else
+ if (!cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
mmu_ci_restrictions = 1;
}
#endif /* CONFIG_PPC_64K_PAGES */
--
1.5.4.3
^ permalink raw reply related
* [PATCH] Force 4K pages for IO addresses.
From: Tony Breeds @ 2008-03-17 3:47 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev; +Cc: Stephen Rothwell, antonb, Jan-Bernd Themann
Currently HEA requires 4K pages for IO resources. Just set the pages size to
IO to 4K.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Paul, please consider this for 2.6.25
arch/powerpc/mm/hash_utils_64.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
Fixes the following ooops:
Unable to handle kernel paging request for data at address 0xd00008008006c040
Faulting instruction address: 0xc000000000336b08
Oops: Kernel access of bad area, sig: 7 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c000000000336b08 LR: c000000000336aac CTR: 8000000000138240
REGS: c0000000fcef3190 TRAP: 0300 Not tainted (2.6.25-rc5.20080317-143135)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24000442 XER: 00000020
DAR: d00008008006c040, DSISR: 0000000042000000
TASK = c0000000fc979190[2781] 'ifconfig' THREAD: c0000000fcef0000 CPU: 7
GPR00: 8000000000000000 c0000000fcef3410 c0000000009cf350 0000000000000000
GPR04: 0000000000000005 0000000000000000 c0000000fc470e50 0000000000000000
GPR08: c0000000fc11fc00 d00008008006c040 f000ffffffffffff 0000000000000000
GPR12: 0000000000000000 c0000000008aed80 0000000028004422 0000000000000000
GPR16: 0000000010120588 00000000100d0000 00000000100b0000 00000000100d0000
GPR20: 0000000010010474 c0000000fea08000 c0000000fcef3cd0 0000000000008914
GPR24: 0000000000000000 0000000000000000 c0000000fe02e000 0000000000000060
GPR28: 0000000000000060 0000000000000000 c00000000094afa8 c0000000fc470e40
NIP [c000000000336b08] .ehea_create_cq+0x1c4/0x26c
LR [c000000000336aac] .ehea_create_cq+0x168/0x26c
Call Trace:
[c0000000fcef3410] [c000000000336aac] .ehea_create_cq+0x168/0x26c (unreliable)
[c0000000fcef34b0] [c00000000032efc4] .ehea_init_port_res+0xd0/0x4c0
[c0000000fcef3570] [c000000000331ba8] .ehea_up+0x134/0x754
[c0000000fcef3670] [c0000000003323c4] .ehea_open+0x84/0x104
[c0000000fcef3710] [c0000000004d55a0] .dev_open+0xb8/0x128
[c0000000fcef37a0] [c0000000004d53e0] .dev_change_flags+0x110/0x218
[c0000000fcef3840] [c000000000528db0] .devinet_ioctl+0x2d4/0x76c
[c0000000fcef3940] [c0000000005293a8] .inet_ioctl+0xe0/0x130
[c0000000fcef39c0] [c0000000004c4590] .sock_ioctl+0x2c0/0x314
[c0000000fcef3a60] [c0000000000fb970] .vfs_ioctl+0x5c/0xf0
[c0000000fcef3b00] [c0000000000fbe34] .do_vfs_ioctl+0x430/0x460
[c0000000fcef3bb0] [c0000000000fbeb0] .sys_ioctl+0x4c/0x88
[c0000000fcef3c60] [c00000000012c364] .dev_ifsioc+0x138/0x324
[c0000000fcef3d40] [c00000000012fdbc] .compat_sys_ioctl+0x398/0x428
[c0000000fcef3e30] [c000000000008748] syscall_exit+0x0/0x40
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 32f4161..f399b1d 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -351,9 +351,7 @@ static void __init htab_init_page_sizes(void)
mmu_vmalloc_psize = MMU_PAGE_64K;
if (mmu_linear_psize == MMU_PAGE_4K)
mmu_linear_psize = MMU_PAGE_64K;
- if (cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
- mmu_io_psize = MMU_PAGE_64K;
- else
+ if (!cpu_has_feature(CPU_FTR_CI_LARGE_PAGE))
mmu_ci_restrictions = 1;
}
#endif /* CONFIG_PPC_64K_PAGES */
--
1.5.4.3
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply related
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Stephen Neuendorffer @ 2008-03-16 21:43 UTC (permalink / raw)
To: Koss, Mike (Mission Systems), Mohammad Sadegh Sadri,
linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333FA99D2F@XMBIL132.northgrum.com>
[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]
Ah, thanks mike... you knocked the answer loose out of my brain...
In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary.
The platform data structure contains entries for both, with the correct ones being ignored. In order to get the code to compile, there are some defines in xparameters.h which have:
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef
#endif
#ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR
#define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef
#endif
after including xparameter_ml403.h
I'm guessing maybe you overwrote the xparameters.h file and got rid of these redefines? You can define it to be whatever you want, since the value will be ignored if you are using SDMA.
In EDK 10.1, the BSP generator will always generate all the defines (even ones which are not sensible in the current configuration), which avoids the above annoyances.
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Koss, Mike (Mission Systems)
Sent: Sat 3/15/2008 9:12 PM
To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org
Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.
thanks
________________________________
Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
[-- Attachment #2: Type: text/html, Size: 4094 bytes --]
^ permalink raw reply
* [PATCH v2] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Olof Johansson @ 2008-03-16 21:30 UTC (permalink / raw)
To: dan.j.williams, shannon.nelson
Cc: linuxppc-dev, pasemi-linux, linux-kernel, hskinnemoen
In-Reply-To: <20080306233900.GA3969@lixom.net>
pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
DMA copy offload driver for PA Semi PWRficient. It uses the
platform-specific functions to allocate channels, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Changes since last post:
* Add DMA_INTERRUPT support and handling of the interrupt flag
* Fix interrupt handler for above and add tasklet
* Switch to spin_lock_bh() where possible
* Remove empty dependency_added() function since it's no longer
used in the framework.
* Fix bug in "ring full" estimation.
Note that this still needs to go on top of the powerpc.git tree due to the
pasemi_dma.h updates that this driver depends on. I suggest merging this
through pasemi.git->powerpc.git->linus with an Acked-by from the DMA guys.
-Olof
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a703def..e4fd7e5 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -37,6 +37,13 @@ config INTEL_IOP_ADMA
help
Enable support for the Intel(R) IOP Series RAID engines.
+config PASEMI_DMA
+ tristate "PA Semi DMA Engine support"
+ depends on PPC_PASEMI
+ select DMA_ENGINE
+ help
+ Enable support for the DMA Engine on PA Semi PWRficient SoCs
+
config DMA_ENGINE
bool
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index b152cd8..72bf45c 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
ioatdma-objs := ioat.o ioat_dma.o ioat_dca.o
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
+obj-$(CONFIG_PASEMI_DMA) += pasemi_dma.o
diff --git a/drivers/dma/pasemi_dma.c b/drivers/dma/pasemi_dma.c
new file mode 100644
index 0000000..ad6235b
--- /dev/null
+++ b/drivers/dma/pasemi_dma.c
@@ -0,0 +1,532 @@
+/*
+ * Driver for the PA Semi PWRficient DMA Engine (copy parts)
+ * Copyright (c) 2007,2008 Olof Johansson, PA Semi, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/dmaengine.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/pasemi_dma.h>
+
+#define MAX_CH 16
+#define MAX_XFER 0x40000
+#define RING_SZ 8192
+
+struct pasemi_dma_desc {
+ u64 src;
+ u64 dest;
+ dma_addr_t src_dma;
+ dma_addr_t dest_dma;
+ size_t len;
+ struct list_head node;
+ enum dma_prep_flags flags;
+ struct dma_async_tx_descriptor async_tx;
+ struct pasemi_dma_chan *chan;
+};
+
+struct pasemi_dma_chan {
+ struct pasemi_dmachan chan;
+ spinlock_t ring_lock; /* Protects the ring only */
+ spinlock_t desc_lock; /* Protects the descriptor list */
+ struct pasemi_dma *dma_dev;
+ struct pasemi_dma_desc *ring_info[RING_SZ]; /* softc */
+ unsigned int next_to_fill;
+ unsigned int next_to_clean;
+ struct dma_chan common;
+ struct list_head free_desc;
+ int desc_count;
+ int in_use;
+ struct tasklet_struct tasklet;
+};
+
+struct pasemi_dma {
+ struct pci_dev *pdev;
+ struct dma_device common;
+ struct pasemi_dma_chan *chans[MAX_CH];
+};
+
+static unsigned int channels = 4;
+module_param(channels, uint, S_IRUGO);
+MODULE_PARM_DESC(channels, "Number of channels for copy (default: 2)");
+
+#define to_pasemi_dma_chan(chan) container_of(chan, struct pasemi_dma_chan, \
+ common)
+#define to_pasemi_dma_desc(lh) container_of(lh, struct pasemi_dma_desc, node)
+#define tx_to_desc_sw(tx) container_of(tx, struct pasemi_dma_desc, async_tx)
+
+static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
+{
+ int old, new, i;
+ struct pasemi_dma_desc *desc;
+ dma_async_tx_callback callback;
+
+restart:
+ spin_lock_bh(&chan->desc_lock);
+
+ old = chan->next_to_clean;
+
+ new = *chan->chan.status & PAS_STATUS_PCNT_M;
+ new <<= 2;
+ new &= (RING_SZ-1);
+
+ if (old > new)
+ new += RING_SZ;
+
+ for (i = old; i < new; i += 4) {
+ if (unlikely(chan->chan.ring_virt[i & (RING_SZ-1)] & XCT_COPY_O))
+ break;
+ desc = chan->ring_info[i & (RING_SZ-1)];
+
+ callback = desc->async_tx.callback;
+ if (callback) {
+ /* Can't re-lock and just loop, since another cpu
+ * might have came in here while we released the lock.
+ * Instead, start all over again to re-read status words.
+ */
+ chan->next_to_clean = i & (RING_SZ-1);
+ spin_unlock_bh(&chan->desc_lock);
+ callback(desc->async_tx.callback_param);
+ goto restart;
+ }
+
+ list_add_tail(&desc->node, &chan->free_desc);
+ }
+
+ chan->next_to_clean = i & (RING_SZ-1);
+
+ spin_unlock_bh(&chan->desc_lock);
+}
+
+static void pasemi_dma_tasklet(unsigned long data)
+{
+ struct pasemi_dma_chan *chan = (struct pasemi_dma_chan *)data;
+
+ pasemi_dma_clean(chan);
+}
+
+static int pasemi_dma_intr(int irq, void *data)
+{
+ struct pasemi_dma_chan *dma_chan = data;
+ const struct pasemi_dmachan *chan = &dma_chan->chan;
+ u64 status;
+ unsigned int reg;
+
+ status = *chan->status;
+
+ if (!(status & PAS_STATUS_CAUSE_M))
+ return IRQ_NONE;
+
+ reg = PAS_IOB_DMA_TXCH_RESET_PINTC |
+ S_IOB_DMA_RXCH_RESET_PCNT(status & PAS_STATUS_PCNT_M);
+
+ if (status & PAS_STATUS_SOFT)
+ reg |= PAS_IOB_DMA_TXCH_RESET_SINTC;
+ if (status & PAS_STATUS_ERROR)
+ reg |= PAS_IOB_DMA_TXCH_RESET_DINTC;
+
+ tasklet_schedule(&dma_chan->tasklet);
+
+ if (reg)
+ pasemi_write_iob_reg(PAS_IOB_DMA_TXCH_RESET(chan->chno), reg);
+
+ return IRQ_HANDLED;
+}
+
+static int pasemi_dma_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+ u32 val;
+ unsigned int cfg;
+ int ret, chno;
+
+ if (ch->in_use)
+ return RING_SZ;
+
+ spin_lock_init(&ch->ring_lock);
+ spin_lock_init(&ch->desc_lock);
+
+ chno = ch->chan.chno;
+
+ ret = pasemi_dma_alloc_ring(&ch->chan, RING_SZ);
+ if (ret) {
+ printk(KERN_INFO "pasemi_dma: Failed to allocate descriptor ring: %d\n", ret);
+ return ret;
+ }
+
+ ch->in_use = 1;
+
+ /* Set CNTTH to something large since we don't want to use count-based
+ * interrupts, but we still need to take them.
+ */
+ pasemi_write_iob_reg(PAS_IOB_DMA_TXCH_CFG(chno),
+ PAS_IOB_DMA_TXCH_CFG_CNTTH(0xfff));
+
+ pasemi_write_iob_reg(PAS_IOB_DMA_TXCH_RESET(chno), 0x30);
+
+ pasemi_write_dma_reg(PAS_DMA_TXCHAN_BASEL(chno),
+ PAS_DMA_TXCHAN_BASEL_BRBL(ch->chan.ring_dma));
+
+ val = PAS_DMA_TXCHAN_BASEU_BRBH(ch->chan.ring_dma >> 32);
+ val |= PAS_DMA_TXCHAN_BASEU_SIZ(ch->chan.ring_size >> 3);
+
+ pasemi_write_dma_reg(PAS_DMA_TXCHAN_BASEU(chno), val);
+
+ cfg = PAS_DMA_TXCHAN_CFG_TY_COPY |
+ PAS_DMA_TXCHAN_CFG_UP |
+ PAS_DMA_TXCHAN_CFG_LPDQ |
+ PAS_DMA_TXCHAN_CFG_LPSQ |
+ PAS_DMA_TXCHAN_CFG_WT(4);
+
+ pasemi_write_dma_reg(PAS_DMA_TXCHAN_CFG(chno), cfg);
+
+ pasemi_dma_start_chan(&ch->chan, PAS_DMA_TXCHAN_TCMDSTA_SZ |
+ PAS_DMA_TXCHAN_TCMDSTA_DB |
+ PAS_DMA_TXCHAN_TCMDSTA_DE |
+ PAS_DMA_TXCHAN_TCMDSTA_DA);
+
+ ch->next_to_fill = 0;
+ ch->next_to_clean = 0;
+ ch->desc_count = 0;
+
+ return ch->chan.ring_size/4;
+}
+
+static void pasemi_dma_free_chan_resources(struct dma_chan *chan)
+{
+ struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+
+ if (ch->in_use)
+ pasemi_dma_free_ring(&ch->chan);
+
+ ch->in_use = 0;
+
+ return;
+}
+
+static enum dma_status pasemi_dma_is_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ dma_cookie_t *done,
+ dma_cookie_t *used)
+{
+ struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+ dma_cookie_t clean, fill;
+ int tries = 1;
+ enum dma_status ret;
+
+ pasemi_dma_clean(ch);
+
+ do {
+ clean = (ch->next_to_clean - 4) & (RING_SZ-1);
+ fill = (ch->next_to_fill - 1) & (RING_SZ-1) ;
+
+ if (done)
+ *done = clean;
+ if (used)
+ *used = fill;
+
+ ret = dma_async_is_complete(cookie, clean, fill);
+ } while (ret != DMA_SUCCESS && --tries);
+
+ return ret;
+}
+
+
+static void pasemi_dma_issue_pending(struct dma_chan *chan)
+{
+ return;
+}
+
+
+static dma_cookie_t
+pasemi_tx_submit_memcpy(struct dma_async_tx_descriptor *tx)
+{
+ struct pasemi_dma_desc *desc = tx_to_desc_sw(tx);
+ struct pasemi_dma_chan *chan = desc->chan;
+ u64 xct[4], *ring;
+ int idx, len;
+
+ len = desc->len;
+ if (unlikely(!len)) {
+ xct[0] = XCT_COPY_DTY_PREF;
+ len = 1;
+ } else
+ xct[0] = 0;
+
+ /* Check if interrupt was requested */
+ if (desc->flags & DMA_PREP_INTERRUPT)
+ xct[0] |= XCT_COPY_I;
+
+ xct[0] |= XCT_COPY_O | XCT_COPY_LLEN(len);
+ xct[1] = XCT_PTR_LEN(len) | XCT_PTR_ADDR(desc->dest) | XCT_PTR_T;
+ xct[2] = XCT_PTR_LEN(len) | XCT_PTR_ADDR(desc->src);
+ xct[3] = 0;
+
+ spin_lock_bh(&chan->ring_lock);
+
+ idx = chan->next_to_fill;
+
+ ring = chan->chan.ring_virt;
+
+ /* This is where we copy stuff to the ring */
+
+ ring[idx & (RING_SZ-1)] = xct[0];
+ ring[(idx+1) & (RING_SZ-1)] = xct[1];
+ ring[(idx+2) & (RING_SZ-1)] = xct[2];
+ ring[(idx+3) & (RING_SZ-1)] = xct[3];
+
+ chan->next_to_fill = (chan->next_to_fill + 4) & (RING_SZ-1);
+
+ chan->ring_info[idx] = desc;
+
+ pasemi_write_dma_reg(PAS_DMA_TXCHAN_INCR(chan->chan.chno), 2);
+
+ spin_unlock_bh(&chan->ring_lock);
+ return idx;
+}
+
+static struct pasemi_dma_desc *
+pasemi_dma_alloc_descriptor(struct pasemi_dma_chan *ch, gfp_t flags)
+{
+ struct pasemi_dma_desc *desc;
+ int retries;
+
+retry:
+ spin_lock_bh(&ch->desc_lock);
+
+ if (!list_empty(&ch->free_desc)) {
+ desc = list_entry(ch->free_desc.next, struct pasemi_dma_desc,
+ node);
+ list_del(&desc->node);
+ spin_unlock_bh(&ch->desc_lock);
+ return desc;
+ }
+
+ if (ch->desc_count >= (RING_SZ/4)) {
+ spin_unlock_bh(&ch->desc_lock);
+ if (!retries++) {
+ pasemi_dma_clean(ch);
+ goto retry;
+ }
+ return NULL;
+ }
+ ch->desc_count++;
+ spin_unlock_bh(&ch->desc_lock);
+
+ /* try to get another desc */
+ desc = kzalloc(sizeof(*desc), flags);
+ if (unlikely(!desc))
+ return NULL;
+
+ dma_async_tx_descriptor_init(&desc->async_tx, &ch->common);
+ desc->chan = ch;
+ INIT_LIST_HEAD(&desc->async_tx.tx_list);
+
+ /* will this ever happen? */
+ BUG_ON(!desc);
+
+ return desc;
+}
+
+static struct dma_async_tx_descriptor *
+pasemi_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
+ dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+ struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+ struct pasemi_dma_desc *desc;
+
+ if (len >= MAX_XFER) {
+ if (printk_ratelimit())
+ printk(KERN_WARNING "pasemi_dma: Copy request too long (%ld > %d)\n",
+ len, MAX_XFER);
+ return NULL;
+ }
+
+ desc = pasemi_dma_alloc_descriptor(ch, GFP_KERNEL);
+ if (!desc)
+ return NULL;
+
+ desc->async_tx.tx_submit = pasemi_tx_submit_memcpy;
+ desc->len = len;
+ desc->dest = dma_dest;
+ desc->src = dma_src;
+ desc->flags = flags;
+
+ return &desc->async_tx;
+}
+
+/* The DMA API assumes there's a way to create an "interrupt only" descriptor.
+ * Our DMA engine doesn't have that concept, so let's create a dummy 1-byte
+ * prefetch descriptor just like 0-size memcpy, but with the _SE and _I bit set.
+ */
+static struct dma_async_tx_descriptor *
+pasemi_dma_prep_interrupt(struct dma_chan *chan)
+{
+ dma_addr_t dummy = to_pasemi_dma_chan(chan)->chan.ring_dma;
+
+ return pasemi_dma_prep_memcpy(chan, dummy, dummy, 0, DMA_PREP_INTERRUPT);
+}
+
+static int enumerate_dma_channels(struct pasemi_dma *device)
+{
+ int i, ret;
+ struct pasemi_dma_chan *ch;
+
+ device->common.chancnt = channels;
+
+ for (i = 0; i < device->common.chancnt; i++) {
+ ch = pasemi_dma_alloc_chan(TXCHAN, sizeof(*ch),
+ offsetof(struct pasemi_dma_chan,
+ chan));
+ ch->dma_dev = device;
+ ch->common.device = &device->common;
+ tasklet_init(&ch->tasklet, pasemi_dma_tasklet, (unsigned long)ch);
+ ret = request_irq(ch->chan.irq, &pasemi_dma_intr, IRQF_DISABLED,
+ "pasemi_dma", ch);
+ if (ret) {
+ printk(KERN_INFO "pasemi_dma: request of irq %d failed: %d\n",
+ ch->chan.irq, ret);
+ return ret;
+ }
+ INIT_LIST_HEAD(&ch->free_desc);
+ list_add_tail(&ch->common.device_node,
+ &device->common.channels);
+ }
+ return device->common.chancnt;
+}
+
+static int __devinit pasemi_dma_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ int err;
+ struct pasemi_dma *device;
+ struct dma_device *dma_dev;
+
+ err = pci_enable_device(pdev);
+ if (err)
+ goto err_enable_device;
+
+ device = kzalloc(sizeof(*device), GFP_KERNEL);
+ if (!device) {
+ err = -ENOMEM;
+ goto err_kzalloc;
+ }
+
+ device->pdev = pdev;
+ pci_set_drvdata(pdev, device);
+
+ dma_dev = &device->common;
+
+ INIT_LIST_HEAD(&dma_dev->channels);
+ enumerate_dma_channels(device);
+
+ dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
+ dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
+ dma_dev->device_alloc_chan_resources = pasemi_dma_alloc_chan_resources;
+ dma_dev->device_free_chan_resources = pasemi_dma_free_chan_resources;
+ dma_dev->device_prep_dma_memcpy = pasemi_dma_prep_memcpy;
+ dma_dev->device_prep_dma_interrupt = pasemi_dma_prep_interrupt;
+ dma_dev->device_is_tx_complete = pasemi_dma_is_complete;
+ dma_dev->device_issue_pending = pasemi_dma_issue_pending;
+ dma_dev->dev = &pdev->dev;
+
+ printk(KERN_INFO "PA Semi DMA Engine found, using %d channels for copy\n",
+ dma_dev->chancnt);
+
+ err = dma_async_device_register(dma_dev);
+
+ return err;
+
+err_kzalloc:
+ pci_disable_device(pdev);
+err_enable_device:
+
+ printk(KERN_ERR "PA Semi DMA Engine initialization failed\n");
+
+ return err;
+}
+
+static void pasemi_dma_shutdown(struct pci_dev *pdev)
+{
+ struct pasemi_dma *device;
+ device = pci_get_drvdata(pdev);
+
+ dma_async_device_unregister(&device->common);
+}
+
+static void __devexit pasemi_dma_remove(struct pci_dev *pdev)
+{
+ struct pasemi_dma *device;
+ struct dma_chan *chan, *_chan;
+ struct pasemi_dma_chan *pasemi_ch;
+
+ device = pci_get_drvdata(pdev);
+ dma_async_device_unregister(&device->common);
+
+ list_for_each_entry_safe(chan, _chan, &device->common.channels,
+ device_node) {
+ pasemi_ch = to_pasemi_dma_chan(chan);
+ free_irq(pasemi_ch->chan.irq, pasemi_ch);
+ list_del(&chan->device_node);
+ pasemi_dma_free_chan(&pasemi_ch->chan);
+ }
+
+ pci_disable_device(pdev);
+ kfree(device);
+}
+
+static struct pci_device_id pasemi_dma_pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_PASEMI, 0xa007) },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, pasemi_dma_pci_tbl);
+
+static struct pci_driver pasemi_dma_pci_driver = {
+ .name = "pasemi_dma",
+ .id_table = pasemi_dma_pci_tbl,
+ .probe = pasemi_dma_probe,
+ .shutdown = pasemi_dma_shutdown,
+ .remove = __devexit_p(pasemi_dma_remove),
+};
+
+
+static int __init pasemi_dma_init_module(void)
+{
+ int err;
+
+ err = pasemi_dma_init();
+ if (err)
+ return err;
+
+ return pci_register_driver(&pasemi_dma_pci_driver);
+}
+
+module_init(pasemi_dma_init_module);
+
+static void __exit pasemi_dma_exit_module(void)
+{
+ pci_unregister_driver(&pasemi_dma_pci_driver);
+}
+
+module_exit(pasemi_dma_exit_module);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Olof Johansson <olof@lixom.net>");
+MODULE_DESCRIPTION("PA Semi PWRficient DMA Engine driver");
^ permalink raw reply related
* Re: PPC upstream kernel ignored DABR bug
From: Benjamin Herrenschmidt @ 2008-03-16 20:38 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Paul Mackerras, Jan Kratochvil, Arnd Bergmann,
Roland McGrath
In-Reply-To: <50c1640385e5eecc50430869175a70c7@kernel.crashing.org>
On Fri, 2008-03-14 at 09:42 +0100, Segher Boessenkool wrote:
> > I saw no effect from that change. So now we're back to pure
> mystery,
> > I guess.
>
> Hey, we know something now: it's "just" a problem in the kernel :-)
We don't know that for sure. The DABR context switching code is trivial
enough...
Ben.
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Benjamin Herrenschmidt @ 2008-03-16 20:37 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Paul Mackerras, Jan Kratochvil, Arnd Bergmann,
Roland McGrath
In-Reply-To: <2f8f82fe943fcd5103ec4cc39cc1bb26@kernel.crashing.org>
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
Uh... could be the boot code setting it, the setting happening on LSU0
but not LSU1. No ?
Ben.
^ permalink raw reply
* Re: simple MPC5200B system
From: Grant Likely @ 2008-03-16 20:01 UTC (permalink / raw)
To: André Schwarz; +Cc: linux-ppc list
In-Reply-To: <47DD71D0.2010203@matrix-vision.de>
On Sun, Mar 16, 2008 at 1:15 PM, Andr=E9 Schwarz
<Andre.Schwarz@matrix-vision.de> wrote:
> All,
>
> I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+
> ... maybe someone could give me some hints.
> Up to now the systems have been running on 2.6.19 without any problems.
>
> This is what I've done so far :
>
> - get a recent system with 2.6.19 running and keep the toolchain (gcc
> 4.0) including RFS uImage.
> - latest bootloader (u-boot 1.3.2) is running fine with dtb support.
> - Kernel and RFS images are available via bootp/tftp
> - device tree blob seems ok, i.e. u-boot can display the blob and fill
> in all clocks correctly.
> - Kernel gets called with Kernel, RFS and dtb on suitable adresses
> (0x100000, 0x600000, 0x5F0000).
> - nothing more happens. It looks like the console isn't working properly
> - maybe worse ...
Can you either halt the processor or reset the board and access memory
after this point? You should see if you can access __log_buf (Look in
System.map for the address and subtract 0xc0000000 to get the physical
address). __log_buf should give you clues about how far booting
progresses.
> The kernel has been build using the "MPC5200 simple" setup. I've added
> our board identifier "mv,mvbluecougar" to the list of supported boards
> in the "mpc52xx_simple.c" file. This identifier is used in the dtb as
> well of course. This should be enough along with a valid device tree
> blob, isn't it ? Did I miss anything already ?
Yes, this should be enough (on a side note; it should probably be
"matrix-vision,bluecougar" unless of''mv' is your company's stock
ticker symbol).
>
> As far as I did understand by reading the docs it should be possible
> running a general MPC52xx kernel with a custom dtb ? Is this correct ?
That is correct.
> The dts file has already been reduced to a minimum, i.e. only the cpu,
> pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,
> pci, ata or "advanced" features like mtd partitions. All I want to get
> working is the serial console on "/dev/ttyPSC0".
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* simple MPC5200B system
From: André Schwarz @ 2008-03-16 19:15 UTC (permalink / raw)
To: linux-ppc list
All,
I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+=20
... maybe someone could give me some hints.
Up to now the systems have been running on 2.6.19 without any problems.
This is what I've done so far :
- get a recent system with 2.6.19 running and keep the toolchain (gcc=20
4.0) including RFS uImage.
- latest bootloader (u-boot 1.3.2) is running fine with dtb support.
- Kernel and RFS images are available via bootp/tftp
- device tree blob seems ok, i.e. u-boot can display the blob and fill=20
in all clocks correctly.
- Kernel gets called with Kernel, RFS and dtb on suitable adresses=20
(0x100000, 0x600000, 0x5F0000).
- nothing more happens. It looks like the console isn't working properly=20
- maybe worse ...
We're using the latest git version from Wolfgang Denk.
The kernel has been build using the "MPC5200 simple" setup. I've added=20
our board identifier "mv,mvbluecougar" to the list of supported boards=20
in the "mpc52xx_simple.c" file. This identifier is used in the dtb as=20
well of course. This should be enough along with a valid device tree=20
blob, isn't it ? Did I miss anything already ?
As far as I did understand by reading the docs it should be possible=20
running a general MPC52xx kernel with a custom dtb ? Is this correct ?
The dts file has already been reduced to a minimum, i.e. only the cpu,=20
pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm,=20
pci, ata or "advanced" features like mtd partitions. All I want to get=20
working is the serial console on "/dev/ttyPSC0".
Are there any hidden stumbling blocks ?
Sorry for the "simple" questions but obviously there are many questions=20
coming up during move from "ppc" to "powerpc".
Any help is appreciated.
regards,
Andr=E9 Schwarz
Matrix Vision GmbH
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Koss, Mike (Mission Systems) @ 2008-03-16 4:12 UTC (permalink / raw)
To: Mohammad Sadegh Sadri, linuxppc-embedded
In-Reply-To: <BAY115-W186EA84A950C17657AD8D9B20B0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]
That interrupt is defined if you build a xps_ll_temac with the
xps_ll_fifo interface. Since you already stated that you're using the
mpmc, I'm going to assume that you have it connected to a SDMA
controller on the mpmc. As such the driver should be looking for that
definition, and not the FIFO interrupt. I don't have your version of the
virtex_devices.c to have a reference as to how the platform device is
being defined, so hopefully either Stephen N can chime in w/ more
information, or point me to the version of the virtex_devices.c that
you're using and I can try to provide some more assistance.
-- Mike
________________________________
From: Mohammad Sadegh Sadri [mailto:mamsadegh@hotmail.com]
Sent: Saturday, March 15, 2008 4:31 AM
To: linuxppc-embedded@ozlabs.org
Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
All,
that should be a small problem, and i think that its solution should be
simple,
I generate a base system using EDK 9.2.02 , the base system contains
XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper
kernel folder. I configure that kernel and add kernel support for
XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error:
'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a
function)
I think that this definition should be available in xparameters_ml403.h
file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel
compilation, don't know the correct value for it of course.
thanks
________________________________
Access your files from anywhere with Windows Live SkyDrive! Sign up now
and get 5GB of space FREE! <http://g.msn.ca/ca55/209>
[-- Attachment #2: Type: text/html, Size: 2792 bytes --]
^ permalink raw reply
* [PATCH] PPC: Use newer, non-deprecated __SPIN_LOCK_UNLOCKED macro.
From: Robert P. J. Day @ 2008-03-15 17:27 UTC (permalink / raw)
To: Linux PPC Mailing List
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/arch/ppc/syslib/mpc52xx_setup.c b/arch/ppc/syslib/mpc52xx_setup.c
index 9f504fc..ab0cf4c 100644
--- a/arch/ppc/syslib/mpc52xx_setup.c
+++ b/arch/ppc/syslib/mpc52xx_setup.c
@@ -279,7 +279,7 @@ int mpc52xx_match_psc_function(int psc_idx, const char *func)
int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
{
- static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+ static DEFINE_SPINLOCK(lock);
struct mpc52xx_cdm __iomem *cdm;
unsigned long flags;
u16 mclken_div;
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply related
* Re: External interrupt type?
From: Kári Davíðsson @ 2008-03-15 11:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1205521536.28630.4.camel@marel2693>
A quick fix with very limited testing is included....
Someone might want to try this out or at least read it over :)
But as they say.. it works for me...
Index: arch/powerpc/platforms/52xx/mpc52xx_pic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- arch/powerpc/platforms/52xx/mpc52xx_pic.c (revision 172)
+++ arch/powerpc/platforms/52xx/mpc52xx_pic.c (working copy)
@@ -97,11 +97,28 @@
io_be_setbit(&intr->ctrl, 27-l2irq);
}
=20
+static int mpc52xx_extirq_set_type(unsigned int virq, unsigned int
type)
+{
+ int irq;
+ u32 ctrl_reg;
+
+ irq =3D irq_map[virq].hwirq;
+
+ ctrl_reg =3D in_be32(&intr->ctrl);
+ ctrl_reg &=3D ~(0x3 << (22 - irq * 2)); /* Clear the old type */
+ ctrl_reg |=3D (type & 0x3) << (22 -irq * 2);
+
+ out_be32(&intr->ctrl, ctrl_reg);
+
+ return 0;
+}
+
static struct irq_chip mpc52xx_extirq_irqchip =3D {
.typename =3D " MPC52xx IRQ[0-3] ",
.mask =3D mpc52xx_extirq_mask,
.unmask =3D mpc52xx_extirq_unmask,
.ack =3D mpc52xx_extirq_ack,
+ .set_type =3D mpc52xx_extirq_set_type,
};
=20
/*
rg
kd
On Fri, 2008-03-14 at 19:05 +0000, K=C3=A1ri Dav=C3=AD=C3=B0sson wrote:
> Hello,
>=20
> I am dealing with external interrupts on an custom board of the
> mpc5200b. Kernel is 2.6.24 from kernel.org.
>=20
> I can declare the interrupt in the dts for the board and the
> control register is set correctly, i.e. the correct external interrupt
> is enabled.
>=20
> On the other hand the type is ignored and is always level interrupt
> active low.
>=20
> Is this intended behaviour?
> How can I pass in the interrupt type from the dts to the kernel?
>=20
> I need to have the interrupt as edge interrupt, rising edge type?
>=20
> rg
> kd
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
From: Mohammad Sadegh Sadri @ 2008-03-15 8:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
All,
that should be a small problem, and i think that its solution should be simple,
I generate a base system using EDK 9.2.02 , the base system contains XPS_LL_TEMAC , MPMC and other components,
I generate the software libraries and copy xparameters file into proper kernel folder. I configure that kernel and add kernel support for XPS_LL_TEMAC.
while doing make I encounter this error:
arch/ppc/syslib/virtex_devices.c:455: error: 'XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR' undeclared here (not in a function)
I think that this definition should be available in xparameters_ml403.h file but i see that there is no such definition.
I added a dummy definition for myself there to complete kernel compilation, don't know the correct value for it of course.
thanks
_________________________________________________________________
Create a handy button so your friends can add U to their buddy list. Try it now!
http://g.msn.ca/ca55/211
[-- Attachment #2: Type: text/html, Size: 1176 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] Emerson ATCA-C125 bootwrapper
From: David Gibson @ 2008-03-15 0:10 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080314142703.GB8228@ru.mvista.com>
On Fri, Mar 14, 2008 at 05:27:03PM +0300, Alexandr Smirnov wrote:
>
> Bootwraper for Emerson ATCA-C125 board. This board has
> four ethernet ports, so it has to use this code instead
> of generic.
[snip]
> + /* Unfortunately, the specific model number is encoded in the
> + * soc node name in existing dts files -- once that is fixed,
> + * this can do a simple path lookup.
> + */
Since this is a new board, couldn't you name the soc node /soc and
dispense with this more complicated way of doing things? Or would
that break other versions of u-boot that are in use?
> + soc = find_node_by_devtype(NULL, "soc");
> + if (soc) {
> + void *serial = NULL;
> +
> + setprop(soc, "bus-frequency", &bd.bi_busfreq,
> + sizeof(bd.bi_busfreq));
> +
> + while ((serial = find_node_by_devtype(serial, "serial"))) {
> + if (get_parent(serial) != soc)
> + continue;
> +
> + setprop(serial, "clock-frequency", &bd.bi_busfreq,
> + sizeof(bd.bi_busfreq));
> + }
> + }
> +}
> +
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7)
> +{
> + CUBOOT_INIT();
> + fdt_init(_dtb_start);
> + serial_console_init();
> + platform_ops.fixups = platform_fixups;
> +}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
From: Stephen Rothwell @ 2008-03-14 23:25 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev
In-Reply-To: <47DA444E.9050507@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Hi Heiko,
On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher <hs@denx.de> wrote:
>
> This add support of the mgsuvd board from keymile to
> arch/powerpc. Supported SMC1 (serial console),
> SCC3 Ethernet (10Mbps hdx)
Paul would probably like some description of the board here.
> +++ b/arch/powerpc/platforms/8xx/mgsuvd.c
>
> +extern void cpm_reset(void);
This declaration is in asm/cpm1.h
> +struct cpm_pin {
> + int port, pin, flags;
> +};
I wish someone would consolidate all these definitions of cpm_pin.
> +static void __init init_ioports(void)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(mgsuvd_pins); i++) {
> + struct cpm_pin *pin = &mgsuvd_pins[i];
> + cpm1_set_pin(pin->port, pin->pin, pin->flags);
> + }
And the code that uses them ...
> +static void __init mgsuvd_setup_arch(void)
> +{
> + struct device_node *cpu;
> +
> + cpu = of_find_node_by_type(NULL, "cpu");
> + if (cpu != 0) {
"cpu" is a pointer, so "cpu != NULL" or just "cpu"
> + const unsigned int *fp;
> +
> + fp = of_get_property(cpu, "clock-frequency", NULL);
> + if (fp != 0)
Ditto for "fp" test
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
From: Sebastian Siewior @ 2008-03-14 23:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <60A35F8F-FA66-4ADD-B192-6AC6A301DBA0@kernel.crashing.org>
This is a modified entry I found in the documentation for the 8544.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 41 ++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 +++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 688af9d..131ffaa 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -116,6 +116,47 @@
};
};
+ dma@21300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8544-dma", "fsl,eloplus-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,mpc8544-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0 80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,mpc8544-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <80 80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,mpc8544-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <100 80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,mpc8544-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <180 80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
+
enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index bdb3d0b..b9a3094 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -19,6 +19,7 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/interrupt.h>
+#include <linux/of_platform.h>
#include <asm/system.h>
#include <asm/time.h>
@@ -183,6 +184,18 @@ static int __init mpc8544_ds_probe(void)
}
}
+static struct of_device_id mpc85xxds_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xxds_publish_devices(void)
+{
+ return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
+}
+machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+
/*
* Called very early, device-tree isn't unflattened
*/
--
1.5.4.3
^ permalink raw reply related
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