Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Monday 25 August 2008, Paul Mackerras wrote: > > > Since rc4 is out now, I understand if you feel more comfortable with > > putting the patch into -next instead of -merge. > > Linus has been getting stricter about only putting in fixes for > regressions and serious bugs (see his recent email to Dave Airlie on > LKML for instance). I assume that the corruption is just in the data > that is supplied to userspace and doesn't extend to any kernel data > structures. That's right, please queue it for -next then. > > Note that the second patch is trivial and fixes an oopsable condition > > of the kernel, so at least that should still go into 2.6.27. > > OK, I'll cherry-pick that one for my next batch for Linus. Thanks, Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boot cuImage on an old u-boot
On Thu, Aug 21, 2008 at 11:15:05AM -0500, Scott Wood wrote: > On Wed, Aug 20, 2008 at 05:09:58PM +0200, Sebastian Siewior wrote: > > I have here a mpc8540ads board and a u-boot 1.0.0. I've build the > > defconfig for the board and I tried to boot the genarated > > cuImage.mpc8540ads image. After the bootm command I see just > > > > |8540> bootm 100 > > |## Booting image at 0100 ... > > | Image Name: Linux-2.6.26 > > | Image Type: PowerPC Linux Kernel Image (gzip compressed) > > | Data Size:1232711 Bytes = 1.2 MB > > | Load Address: 0040 > > | Entry Point: 004005ac > > | Verifying Checksum ... OK > > | Uncompressing Kernel Image ... OK > > | > > > > I don't see the device tree fixups printfs, so crash happend quite > > early. Anyone an idea what I could have done wrong? > > Make sure the device tree contains /chosen/linux,stdout-path. No paths to properties, remember! Make sure the device tree contains a linux,stdout-path property in /chosen. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] A a cpufreq driver for the IBM PowerPC 750GX
This patch set adds a cpufreq driver for the IBM PowerPC 750GX processor. It "should" also work for the 750FX. The patches are: 1) Add low level PLL config register interface module 2) Add cpufreq driver for the 750GX 3) Other PowerPC kernel changes necessary to support the above 4) Add kernel doc for the completion feature, fix split-man.pl in kernel-doc-nano-HOWTO.txt These changes are against 2.6.26. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Efficient memcpy()/memmove() for G2/G3 cores...
Hello,
I was wondering if there is a good replacement for GLibc memcpy() functions,
that doesn't have horrendous performance on embedded PowerPC processors (such
as Glibc has).
I did some simple benchmarks with this implementation on our custom MPC5121
based board (Freescale e300 core, something like a PPC603e, G2, without VMX):
...
unsigned long int a,b,c,d;
unsigned long int a1,b1,c1,d1;
...
while (len >= 32)
{
a = plSrc[0];
b = plSrc[1];
c = plSrc[2];
d = plSrc[3];
a1 = plSrc[4];
b1 = plSrc[5];
c1 = plSrc[6];
d1 = plSrc[7];
plSrc += 8;
plDst[0] = a;
plDst[1] = b;
plDst[2] = c;
plDst[3] = d;
plDst[4] = a1;
plDst[5] = b1;
plDst[6] = c1;
plDst[7] = d1;
plDst += 8;
len -= 32;
}
...
And the results are more than telling by linking this with LD_PRELOAD,
some programs get an enourmous performance boost.
For example a small test program that copies frames into video memory (just
RAM) improved throughput from 13.2 MiB/s to 69.5 MiB/s.
I have googled for this issue, but most optimized versions of memcpy() and
friends seem to focus on AltiVec/VMX, which this processor does not have.
Now I am certain that most of the G2/G3 users on this list _must_ have a
better solution for this. Any suggestions?
Btw, the tests are done on Ubuntu/PowerPC 7.10, don't know if that matters
though...
Best regards,
--
David Jander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] Add low level PLL config register interface module
This adds a small module to handle the low level details of dealing with the
PLL config register (HID1) found in the IBM 750GX. It provides 2 possible
interfaces, both selectable via kernel config options. One is a sysfs attribute
and the other is a normal function API. It is called pll_if.
The determination of the bus frequency is what worked on a PowerMac 8600. Any
suggestions on a more general solution are welcome.
WARNING - I used some #ifdefs - Let the fur fly!
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs <[EMAIL PROTECTED]>
Index: Documentation/cpu-freq/pll.pl
===
--- /dev/null 2004-08-10 18:55:00.0 -0700
+++ Documentation/cpu-freq/pll.pl 2008-08-15 13:42:09.0 -0700
@@ -0,0 +1,762 @@
+#!/usr/bin/perl -w
+
+=head1 NAME
+
+pll.pl - Provide user friendly interface to sysfs attribute for the 750GX PLL.
+This uses the pll_if module.
+
+=head1 SYSNOPSIS
+
+ pll.pl [ -bdhtv ] [ -f { clk | ratio }]
+ b:print bus frequency
+ d:dump current pll configuration
+ h:print simple usage information
+ f:set frequency to specified clk (MHz) or ratio (r suffix)
+ t:toggle selected pll. Use with -f to cause a switch to the newly
+ modified PLL on lock.
+ v:enable verbose
+
+=head1 DESCRIPTION
+
+This utility provides a user friendly interface to the sysfs attribute that is
+provided by the pll_if module to control the PLL configuration register (HID1)
+in the IBM PowerPC 750FX and 750GX processors.
+
+=over 4
+
+=item -b
+
+print the bus frequency which is used along with the ratios to compute the
+processor clock frequency.
+
+=pod
+
+The method used to get the bus frequency is to use the value of the
+clock-frequency property from the root of the OF tree.
+
+=item -d
+
+prints the current value of the PLL configuration register in a human readable
+form (well ... more or less).
+
+=item -h
+
+print a simple help message.
+
+=item -t
+
+Toggles the selected PLL that is driving the cpu clock. When used with -f
causes
+a switch to the new PLL upon lock (when the lock timeout expires).
+
+=item -v
+
+Enable verbose mode. Mostly just prints the file paths that stuff is pulled
+from.
+
+=item -f
+
+Sets the INACTIVE PLL to the selected clock frequency in MHz. If the value has
+an "r" suffix, it is taken as a ratio. This also recognizes the special value
+"off" (-foff) to turn off the INACTIVE PLL.
+
+=back
+
+=head1 AUTHOR
+
+kevin diggs
+
+=cut
+
+use warnings;
+use Getopt::Std;
+
+#
+# The layout of the PLL register (HID1) is:
+#
+# 0 4|5 6|7|8| 9 11|12 13|14| 15 |16 20|21 22|23|24 28|29 30| 31
+# PCE |PRE|v|v| Res | Res |v | PS | PC0 | PR0 |v | PC1 | PR1 |Res
+#| | | |
+# PSTAT1 -| | | |
+#ECLK -| | |
+#PI0 | |
+# Res |
+#
+# PCE PLL0 read-only external config
+# PRE PLL0 read-only external range
+# PSTAT1 PLL status (0 -> PLL0, 1 -> PLL1)
+# ECLK1 -> enable clkout pin
+# PI0 PLL0 control: 0 -> external
+# PS PLL select: 0 -> PLL0, 1 -> PLL1
+# PC0 PLL0 configuration
+# PR0 PLL0 range
+# PC1 PLL1 configuration
+# PR1 PLL1 range
+#
+# PLL_CFG bus ratio PLL_CFG bus ratio
+# 0 off 1 8
+# 1 off 10001 8.5
+# 00010 bypass 10010 9
+# 00011 bypass 10011 9.5
+# 00100 210100 10
+# 00101 2.5 10101 11
+# 00110 310110 12
+# 00111 3.5 10111 13
+# 01000 411000 14
+# 01001 4.5 11001 15
+# 01010 511010 16
+# 01011 5.5 11011 17
+# 01100 611100 18
+# 01101 6.5 11101 19
+# 01110 70 20
+# 0 7.5 1 off
+#
+# PLL_RNG range
+#00600 - 900
+#01900 - 1000
+#10500 - 600
+#
+# IBM bit numbering:
+# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
+# 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
+#
+# 26 27 28 29 30 31
+# 5 4 3 2 1 0
+#
+*pllcBusFreqFile=\"/proc/device-tree/clock-frequency";
+#*pllcCPUPVR=\"/proc/device-tree/PowerPC,*/cpu-vers
[PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
This adds the actual cpufreq driver for the 750GX. It supports all integer ratios that are valid for the processor model and bus frequency. It has two modes of operation. Normal mode uses all valid frequencies. In minmaxmode, only the minimum and maximum are used. This provides the ability for very low latency frequency switches. There is also a sysfs attribute to have it switch off the unused PLL for additional power savings. This does NOT support SMP. My name is Kevin Diggs and I approve this patch. Signed-off-by: Kevin Diggs <[EMAIL PROTECTED]> Index: Documentation/DocBook/cf750gx.tmpl === --- /dev/null 2004-08-10 18:55:00.0 -0700 +++ Documentation/DocBook/cf750gx.tmpl 2008-08-20 10:00:14.0 -0700 @@ -0,0 +1,441 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + PowerPC 750GX (and FX?) cpufreq driver guide + + + +Kevin +Diggs + + + + + + 1.0 + August 12, 2008 + Initial revision posted to linuxppc-dev + + + + + 2008 + Kevin Diggs + + + + +This documentation is free software; you can redistribute +it and/or modify it under the terms of the GNU General Public +License as published by the Free Software Foundation; either +version 2 of the License, or (at your option) any later +version. + + + +This program is distributed in the hope that 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., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + + + +For more details see the file COPYING in the source +distribution of Linux. + + + + + This is the first release of this document coincident with submission of the + driver for inclusion in the kernel. + + + + + + + + Introduction + + This guide documents the cpufreq driver for the IBM PowerPC 750GX processor. + It "should" also work with the 750FX but has not been tested. + + + The driver is split into two main parts. The first provides the low level + interface to the PLL configuration register (HID1 - SPR 1009). It is called + pll_if. The second is the actual cpufreq driver, called cf750gx. The pll_if + component handles the details of dealing with the PLL like PLL lock delay + requirements and preventing illegal operations. The cf750gx driver provides + the interface to the cpufreq subsystem. Under control of the specified + governor it will generate the required commands to switch the processor + frequency as requested and send them to pll_if to carry them out. + + + + + Major Components + + + The IBM 750GX (and FX) processor has a pair of PLLs that can be programmed to + operate at a number of different frequencies. The frequencies are specified + as ratios to the system bus and range from 2 to 20. From 2 to 10 it also + supports half ratios (i.e. 2.5, 3.5) though they are not supported in the + cpufreq driver due to a limitation of not being able to switch from one half + ratio directly to another. It takes 100 usec for a PLL to relock to a + new frequency before it can be used [750GX_ds2-17-05.pdf, Table 3-7, + page 18]. It takes 3 bus clocks for the cpu to switch from one PLL to + another [750GX_ds2-17-05.pdf, paragraph 3, page 44]. + + + + The cpufreq driver consists of two main parts: + + + + + + cf750gx - the cpufreq driver module + + + + + + pll_if - a low level interface that encapsulates the details of dealing + with the PLL register + + + + + + cf750gx - The CPUFreq 750GX driver + + +cf750gx provides the standard entry points required of a cpufreq driver. They +are: + + + + + cf750gx_verify - verify + + + + + + cf750gx_target - target + + + + + + cf750gx_cpu_init - cpu init + + + + + + cf750gx_cpu_exit - cpu exit + + + + +These routines perform functions as required by the cpufreq subsystem. + + + +The driver functions in one of 2 modes: normal and minmax. In normal mode +it switches between the available frequencies as requested by the current +cpufreq subsystem governor. In minmax mode, it switches between the minimum +and maximum frequencies only. + + + Normal Mode + + In normal mode the driver switches between all valid frequencies under + control of the selected governor. The list of valid frequencies is + determined at startup based on the cpu model (FX or GX) and the determined + bus frequency. The cpu model deter
gdb problems with threads on mpc512x
I encountered several problem debugging multithreated software with gdb on mpc512x, remotely (gdbserver) and locally. I built gdb 6.8 from scratch, but it's crashing when I stop execution into a thread. Did anyone get it to work correctly? Thanks, Daniele -- Daniele Bosi DIGITEK S.p.A. Via L. Romagnoli 24, 41033 Concordia sulla Secchia Modena (MO), Italy Tel: +39-(0)53556942 Fax. +39-(0)53554550 Web: http://www.digitek.it Mail to: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Efficient memcpy()/memmove() for G2/G3 cores...
Hi David,
The focus has definitely been on VMX but that's not to say lower power
processors were forgotten :)
Gunnar von Boehn did some benchmarking with an assembly optimized routine,
for Cell, 603e and so on (basically the whole gamut from embedded up to
sever class IBM chips) and got some pretty good results;
http://www.powerdeveloper.org/forums/viewtopic.php?t=1426
It is definitely something that needs fixing. The generic routine in glibc
just copies words with no benefit of knowing the cache line size or any
cache block buffers in the chip, and certainly no use of cache control or
data streaming on higher end chips.
With knowledge of the right way to unroll the loops, how many copies to
do at once to try and get a burst, reducing cache usage etc. you can get
very impressive performance (as you can see, 50MB up to 78MB at the
smallest size, the basic improvement is 2x performance).
I hope that helps you a little bit. Gunnar posted code to this list not
long after. I have a copy of the "e300 optimized" routine but I thought
best he should post it here, than myself.
There is a lot of scope I think for optimizing several points (glibc,
kernel, some applications) for embedded processors which nobody is
really taking on. But, not many people want to do this kind of work..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
David Jander wrote:
Hello,
I was wondering if there is a good replacement for GLibc memcpy() functions,
that doesn't have horrendous performance on embedded PowerPC processors (such
as Glibc has).
I did some simple benchmarks with this implementation on our custom MPC5121
based board (Freescale e300 core, something like a PPC603e, G2, without VMX):
...
unsigned long int a,b,c,d;
unsigned long int a1,b1,c1,d1;
...
while (len >= 32)
{
a = plSrc[0];
b = plSrc[1];
c = plSrc[2];
d = plSrc[3];
a1 = plSrc[4];
b1 = plSrc[5];
c1 = plSrc[6];
d1 = plSrc[7];
plSrc += 8;
plDst[0] = a;
plDst[1] = b;
plDst[2] = c;
plDst[3] = d;
plDst[4] = a1;
plDst[5] = b1;
plDst[6] = c1;
plDst[7] = d1;
plDst += 8;
len -= 32;
}
...
And the results are more than telling by linking this with LD_PRELOAD,
some programs get an enourmous performance boost.
For example a small test program that copies frames into video memory (just
RAM) improved throughput from 13.2 MiB/s to 69.5 MiB/s.
I have googled for this issue, but most optimized versions of memcpy() and
friends seem to focus on AltiVec/VMX, which this processor does not have.
Now I am certain that most of the G2/G3 users on this list _must_ have a
better solution for this. Any suggestions?
Btw, the tests are done on Ubuntu/PowerPC 7.10, don't know if that matters
though...
Best regards,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] Various arch/powerpc changes to support the 750GX cpufreq driver
This patch includes various changes necessary to support the cpufreq driver for
the PowerPC 750GX. Highlights include adding entries to recognize the 750GX to
the cputable (This includes the ... unfortunate pvr that the 750GX used in the
PowerLogix PowerForce 750GX => 0x0008 0203). The PLL switch in idle_6xx.S
during sleep (or nap) was also removed (I tried to add ability to disable this
but the result would not boot?).
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs <[EMAIL PROTECTED]>
Index: arch/powerpc/kernel/Makefile
===
--- arch/powerpc/kernel/Makefile.orig 2008-08-13 02:19:18.0 -0700
+++ arch/powerpc/kernel/Makefile2008-08-14 02:50:18.0 -0700
@@ -17,6 +17,7 @@ obj-y := cputable.o ptrace.o syscalls
init_task.o process.o systbl.o idle.o \
signal.o
obj-y += vdso32/
+obj-y += cpu/
obj-$(CONFIG_PPC64)+= setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
Index: arch/powerpc/kernel/cputable.c
===
--- arch/powerpc/kernel/cputable.c.orig 2008-08-13 02:19:19.0 -0700
+++ arch/powerpc/kernel/cputable.c 2008-08-14 03:00:51.0 -0700
@@ -42,9 +42,11 @@ extern void __setup_cpu_604(unsigned lon
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750cx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750fx(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_750gx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7400(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_7410(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_745x(unsigned long offset, struct cpu_spec* spec);
+
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
@@ -660,7 +662,7 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_generic,
.platform = "ppc750",
},
- { /* 750GX */
+ { /* 750GX rev 1.x */
.pvr_mask = 0x,
.pvr_value = 0x7002,
.cpu_name = "750GX",
@@ -669,7 +671,33 @@ static struct cpu_spec __initdata cpu_sp
.icache_bsize = 32,
.dcache_bsize = 32,
.num_pmcs = 4,
- .cpu_setup = __setup_cpu_750fx,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = "ppc750",
+ },
+ { /* 750GX (rev 2.3, as used on PowerLogix 750GX upgrade card */
+ .pvr_mask = 0x,
+ .pvr_value = 0x00080203,
+ .cpu_name = "750GX",
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
+ .machine_check = machine_check_generic,
+ .platform = "ppc750",
+ },
+ { /* 750GX (All revs >= 2.0) */
+ .pvr_mask = 0xff00,
+ .pvr_value = 0x70020200,
+ .cpu_name = "750GX",
+ .cpu_features = CPU_FTRS_750GX,
+ .cpu_user_features = COMMON_USER | PPC_FEATURE_PPC_LE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750gx,
.machine_check = machine_check_generic,
.platform = "ppc750",
},
Index: arch/powerpc/kernel/cpu_setup_6xx.S
===
--- arch/powerpc/kernel/cpu_setup_6xx.S.orig2008-08-13 02:19:19.0
-0700
+++ arch/powerpc/kernel/cpu_setup_6xx.S 2008-08-14 02:44:30.0 -0700
@@ -53,6 +53,14 @@ _GLOBAL(__setup_cpu_750fx)
bl setup_750fx
mtlrr4
blr
+_GLOBAL(__setup_cpu_750gx)
+ mflrr4
+ bl __init_fpu_registers
+ bl setup_common_caches
+ bl setup_750_7400_hid0
+ bl se
[PATCH 4/4] Add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txt
This patch adds kernel doc for the completion feature. It is in kernel/sched.c
and include/linux/completion.h.
An error in the split-man.pl PERL snippet in kernel-doc-nano-HOWTO.txt is
also fixed.
My name is Kevin Diggs and I approve this patch.
Signed-off-by: Kevin Diggs <[EMAIL PROTECTED]>
Index: Documentation/kernel-doc-nano-HOWTO.txt
===
--- Documentation/kernel-doc-nano-HOWTO.txt.orig2008-08-13
02:18:53.0 -0700
+++ Documentation/kernel-doc-nano-HOWTO.txt 2008-08-19 14:21:43.0
-0700
@@ -168,10 +168,10 @@ if ($#ARGV < 0) {
mkdir $ARGV[0],0777;
$state = 0;
while () {
-if (/^\.TH \"[^\"]*\" 4 \"([^\"]*)\"/) {
+if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
if ($state == 1) { close OUT }
$state = 1;
- $fn = "$ARGV[0]/$1.4";
+ $fn = "$ARGV[0]/$1.9";
print STDERR "Creating $fn\n";
open OUT, ">$fn" or die "can't open $fn: $!\n";
print OUT $_;
Index: include/linux/completion.h
===
--- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
+++ include/linux/completion.h 2008-08-20 01:47:21.0 -0700
@@ -10,6 +10,18 @@
#include
+/**
+ * struct completion - structure used to maintain state for a "completion"
+ *
+ * This is the opaque structure used to maintain the state for a "completion".
+ * Completions currently use a FIFO to queue threads that have to wait for
+ * the "completion" event.
+ *
+ * See also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable), init_completion(),
+ * and macros DECLARE_COMPLETION(), DECLARE_COMPLETION_ONSTACK(), and
+ * INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -21,6 +33,14 @@ struct completion {
#define COMPLETION_INITIALIZER_ONSTACK(work) \
({ init_completion(&work); work; })
+/**
+ * DECLARE_COMPLETION: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure. Generally used
+ * for static declarations. You should use the _ONSTACK variant for automatic
+ * variables.
+ */
#define DECLARE_COMPLETION(work) \
struct completion work = COMPLETION_INITIALIZER(work)
@@ -29,6 +49,13 @@ struct completion {
* completions - so we use the _ONSTACK() variant for those that
* are on the kernel stack:
*/
+/**
+ * DECLARE_COMPLETION_ONSTACK: - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure on the kernel
+ * stack.
+ */
#ifdef CONFIG_LOCKDEP
# define DECLARE_COMPLETION_ONSTACK(work) \
struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
@@ -36,6 +63,13 @@ struct completion {
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x->done = 0;
@@ -53,6 +87,13 @@ extern unsigned long wait_for_completion
extern void complete(struct completion *);
extern void complete_all(struct completion *);
+/**
+ * INIT_COMPLETION: - reinitialize a completion structure
+ * @x: completion structure to be reinitialized
+ *
+ * This macro should be used to reinitialize a completion structure so it can
+ * be reused. This is especially important after complete_all() is used.
+ */
#define INIT_COMPLETION(x) ((x).done = 0)
#endif
Index: kernel/sched.c
===
--- kernel/sched.c.orig 2008-08-13 02:22:42.0 -0700
+++ kernel/sched.c 2008-08-20 12:36:01.0 -0700
@@ -4363,6 +4363,15 @@ __wake_up_sync(wait_queue_head_t *q, uns
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. Threads will
be
+ * awakened in the same order in which they were queued.
+ *
+ * See also complete_all(), wait_for_completion() and related routines.
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4383,12 @@ void complete(struct completion *x)
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@
Re: [PATCH 1/4] Add low level PLL config register interface module
On Aug 25, 2008, at 5:41 AM, Kevin Diggs wrote: This adds a small module to handle the low level details of dealing with the PLL config register (HID1) found in the IBM 750GX. It provides 2 possible interfaces, both selectable via kernel config options. One is a sysfs attribute and the other is a normal function API. It is called pll_if. The determination of the bus frequency is what worked on a PowerMac 8600. Any suggestions on a more general solution are welcome. WARNING - I used some #ifdefs - Let the fur fly! My name is Kevin Diggs and I approve this patch. This really should be split into two patches. One for the perl script and one for the actual kernel code. Scanning the actual kernel code you have a lot of #ifdef's that should be cleaned up: Can't #ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS just be #ifdef CONFIG_SYSFS and the same for CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER & CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ? #ifdef CONFIG_PPC_OF seems unnecessary as all PPC always has this set. What's up with #define MULFIRST and the #if 0? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
On Monday 25 August 2008, Kevin Diggs wrote:
> + * cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
Thanks for posting this driver and for your attention for detail
and for documentation in particular. Few people bother to write
documentation at this level.
I don't understand enough of cpufreq or your hardware to comment
on that, but please let me give you a few hints on coding style.
> + * Copyright (C) 2008 kevin Diggs
Most people list their email address here as well
> +#define cf750gxmChangingPll(0x8000)
> +#define cf750gxmChangingPllBit (31)
> +#define cf750gxmTurningIdlePllOff (0x4000)
> +#define cf750gxmTurningIdlePllOffBit (30)
constants should be ALL_CAPS, not sIllYCaPS.
> +struct pll_750fgx_t {
> + unsigned short min_ratio; /* min bus ratio */
> + unsigned short max_ratio; /* max bus ratio */
> + unsigned int min_core; /* min core frequency per spec (KHz)
> */
> + unsigned int max_core; /* max core frequency per spec (KHz)
> */
> +};
please drop the _t at the end of the identifier.
> +MODULE_AUTHOR("Kevin Diggs");
> +MODULE_DESCRIPTION("750GX Dual PLL cpufreq driver");
> +MODULE_LICENSE("GPL");
Move this to the end.
> +struct cf750gx_t_call_data {
> + struct cpufreq_freqs freqs;
> + unsigned long current_pll;
> + int idle_pll_off;
> +};
drop the _t here, or make explicit what is meant by it.
> +static const struct pll_750fgx_t __initdata pll_750fx = {
> + .min_ratio = 2,
> + .max_ratio = 20,
> + .min_core = 40,
> + .max_core = 80,
> +};
> +
> +static const struct pll_750fgx_t __initdata pll_750gx = {
> + .min_ratio = 2,
> + .max_ratio = 20,
> + .min_core = 50,
> + .max_core = 100,
> +};
Are these correct on any board? If they can be different
depending on the board design, it would be better to get
this data from the device tree.
> +static DECLARE_COMPLETION(cf750gx_v_exit_completion);
> +
> +static unsigned int override_min_core = 0;
> +static unsigned int override_max_core = 0;
> +static unsigned int minmaxmode = 0;
> +
> +static unsigned int cf750gx_v_min_core = 0;
> +static unsigned int cf750gx_v_max_core = 0;
> +static int cf750gx_v_idle_pll_off = 0;
> +static int cf750gx_v_min_max_mode = 0;
> +static unsigned long cf750gx_v_state_bits = 0;
Is 0 a meaningful value for these? If it just means 'uninitialized',
then better don't initialize them in the first place, for clarity.
> +static struct cpufreq_frequency_table *cf750gx_v_f_table;
> +static struct cpufreq_frequency_table *cf750gx_v_freq_table;
> +static struct cpufreq_frequency_table *cf750gx_v_min_max_freq_table;
> +
> +static struct cf750gx_t_call_data cf750gx_v_switch_call_data;
> +static struct cf750gx_t_call_data cf750gx_v_lock_call_data;
> +static struct notifier_block cf750gx_v_pll_switch_nb;
> +static struct notifier_block cf750gx_v_pll_lock_nb;
Also, in general, try to avoid global variables here, even
in file scope (static), but rather put all device specific
data into a per-device data structure.
> +static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
> + action, void *data)
> +{
> +struct cf750gx_t_call_data *cd;
> +unsigned int idle_pll;
> +unsigned int pll_off_cmd;
> +unsigned int new_pll;
The whitespace appears damaged here.
> + cd = (struct cf750gx_t_call_data *)data;
data is a void pointer, so you don't need the cast, and shouldn't
have it therefore.
> +static int cf750gx_pll_lock_cb(struct notifier_block *nb, unsigned long
> action,
> + void *data)
> +{
> +struct cf750gx_t_call_data *cd;
> +
> + cd = (struct cf750gx_t_call_data *)data;
same here.
> +static int cf750gx_target(struct cpufreq_policy *policy,
> + unsigned int target_freq, unsigned int
> relation)
> +{
> +unsigned int next_index = 0; /* Index into freq_table */
> +unsigned int next_freq = 0;/* next frequency from perf table */
> +unsigned int next_perf_state = 0; /* Index from perf table */
> +int result = 0;
Don't initialize local variables in the declaration, as that will prevent
the compiler from warning about uninitialized use.
> +unsigned int pll;
> +unsigned int new_pll;
> +unsigned int active_pll;
> +struct cpufreq_freqs freqs;
> +struct cpufreq_frequency_table *ft = cf750gx_v_f_table;
more whitespace damage. Maybe there is something wrong with your
text editor.
> + dprintk(__FILE__">%s(, %u KHz, relation %u)-%d: on cpu %d\n",
> + __func__, target_freq, relation, __LINE__, policy->cpu);
> +
> + if (test_and_set_bit(cf750gxmChangingPllBit, &cf750gx_v_state_bits))
> + return -EAGAIN;
> +
> + INIT_COMPLETION(cf750gx_v_exit_completion);
> +
> + result = cpufreq_frequency_table_target(policy,
> + ft,
> +
Re: [PATCH 4/4] Add kernel doc for the completion, fix kernel-doc-nano-HOWTO.txt
* Kevin Diggs <[EMAIL PROTECTED]> wrote: > This patch adds kernel doc for the completion feature. It is in > kernel/sched.c and include/linux/completion.h. this patch is whitespace damaged. Could you resend it as attachment, or set up your email client as per Documentation/email-clients.txt? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [RFC] Fix level IRQ handling on Xilinx INTC with ARCH=powerpc
This fixes the missing acknowledge at the end of handle_level_irq().
It adds a field flags to struct irq_chip. If IRQ_CHIP_UNMASK_ACK is set in
this field, acknowledge is performed before unmasking.
diff -r 6b0915754563 arch/powerpc/sysdev/xilinx_intc.c
--- a/arch/powerpc/sysdev/xilinx_intc.c Mon Jul 28 19:59:22 2008 +0400
+++ b/arch/powerpc/sysdev/xilinx_intc.c Fri Aug 08 13:13:52 2008 +0400
@@ -73,6 +73,7 @@
.mask = xilinx_intc_mask,
.unmask = xilinx_intc_unmask,
.ack = xilinx_intc_ack,
+ .flags = IRQ_CHIP_UNMASK_ACK,
};
/*
@@ -107,8 +108,8 @@
}
regs = ioremap(res.start, 32);
- printk(KERN_INFO "Xilinx intc at 0x%08LX mapped to 0x%p\n",
- res.start, regs);
+ printk(KERN_INFO "Xilinx intc at 0x%p mapped to 0x%p\n",
+ (void *)res.start, regs);
/* Setup interrupt controller */
out_be32(regs + XINTC_IER, 0); /* disable all irqs */
diff -r 6b0915754563 include/linux/irq.h
--- a/include/linux/irq.h Mon Jul 28 19:59:22 2008 +0400
+++ b/include/linux/irq.h Fri Aug 08 13:13:52 2008 +0400
@@ -114,6 +114,9 @@
int (*retrigger)(unsigned int irq);
int (*set_type)(unsigned int irq, unsigned int flow_type);
int (*set_wake)(unsigned int irq, unsigned int on);
+
+ unsigned int flags;
+#define IRQ_CHIP_UNMASK_ACK 0x0001
/* Currently used only by UML, might disappear one day.*/
#ifdef CONFIG_IRQ_RELEASE_METHOD
diff -r 6b0915754563 kernel/irq/chip.c
--- a/kernel/irq/chip.c Mon Jul 28 19:59:22 2008 +0400
+++ b/kernel/irq/chip.c Fri Aug 08 13:13:52 2008 +0400
@@ -377,8 +377,12 @@
spin_lock(&desc->lock);
desc->status &= ~IRQ_INPROGRESS;
- if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
- desc->chip->unmask(irq);
+ if (!(desc->status & IRQ_DISABLED)) {
+ if (desc->chip->flags & IRQ_CHIP_UNMASK_ACK)
+ desc->chip->ack(irq);
+ if (desc->chip->unmask)
+ desc->chip->unmask(irq);
+ }
out_unlock:
spin_unlock(&desc->lock);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
initramfs vs initrd
Hello, What is the difference between initramfs and initrd ? Sébastien Chrétien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Efficient memcpy()/memmove() for G2/G3 cores...
Hi Matt,
On Monday 25 August 2008 13:00:10 Matt Sealey wrote:
> The focus has definitely been on VMX but that's not to say lower power
> processors were forgotten :)
lower-power (pun intended) is coming strong these days, as energy-efficiency
is getteing more important every day. And the MPC5121 is a brand-new embedded
processor, that will pop-up in quite a lot devices around you most
probably ;-)
> Gunnar von Boehn did some benchmarking with an assembly optimized routine,
> for Cell, 603e and so on (basically the whole gamut from embedded up to
> sever class IBM chips) and got some pretty good results;
>
> http://www.powerdeveloper.org/forums/viewtopic.php?t=1426
>
> It is definitely something that needs fixing. The generic routine in glibc
> just copies words with no benefit of knowing the cache line size or any
> cache block buffers in the chip, and certainly no use of cache control or
> data streaming on higher end chips.
>
> With knowledge of the right way to unroll the loops, how many copies to
> do at once to try and get a burst, reducing cache usage etc. you can get
> very impressive performance (as you can see, 50MB up to 78MB at the
> smallest size, the basic improvement is 2x performance).
>
> I hope that helps you a little bit. Gunnar posted code to this list not
> long after. I have a copy of the "e300 optimized" routine but I thought
> best he should post it here, than myself.
Ok, I think I found it on the thread. The only problem is, that AFAICS it can
be much better... at least on my platform (e300 core), and I don't know why!
Can you explain this?
I did this:
I took Gunnars code (copy-paste from the forum), renamed the function from
memcpy_e300 to memcpy and put it in a file called "memcpy_e300.S". Then I
did:
$ gcc -O2 -Wall -shared -o libmemcpye300.so memcpy_e300.S
I tried the performance with the small program in the attachment:
$ gcc -O2 -Wall -o pruvmem pruvmem.c
$ LD_PRELOAD=/libmemcpye300.so ./pruvmem
Data rate: 45.9 MiB/s
Now I did the same thing with my own memcpy written in C (see attached file
mymemcpy.c):
$ LD_PRELOAD=/libmymemcpy.so ./pruvmem
Data rate: 72.9 MiB/s
Now, can someone please explain this?
As a reference, here's glibc's performance:
$ ./pruvmem
Data rate: 14.8 MiB/s
> There is a lot of scope I think for optimizing several points (glibc,
> kernel, some applications) for embedded processors which nobody is
> really taking on. But, not many people want to do this kind of work..
They should! It makes a HUGE difference. I surely will of course.
Greetings,
--
David Jander
#include
#include
#include
#include
#include
#include
#include
#include
int main(void)
{
int f;
unsigned long int *mem,*src,*dst;
int t;
long int usecs;
unsigned long int secs, count;
double rate;
struct timeval tv, tv0, tv1;
printf("Opening fb0\n");
f = open("/dev/fb0", O_RDWR);
if(f<0) {
perror("opening fb0");
return 1;
}
printf("mmapping fb0\n");
mem = mmap(NULL, 0x0030, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED,f,0);
printf("mmap returned: %08x\n",(unsigned int)mem);
perror("mmap");
if(mem==-1)
return 1;
gettimeofday(&tv, NULL);
for(t=0; t<0x000c; t++)
mem[t] = (tv.tv_usec ^ tv.tv_sec) ^ t;
count = 0;
gettimeofday(&tv0, NULL);
for(t=0; t<10; t++) {
src = mem;
dst = mem+0x0004;
memcpy(dst, src, 0x0010);
count += 0x0010;
}
gettimeofday(&tv1, NULL);
secs = tv1.tv_sec-tv0.tv_sec;
usecs = tv1.tv_usec-tv0.tv_usec;
if(usecs<0) {
usecs += 100;
secs -= 1;
}
printf("Time elapsed: %ld secs, %ld usecs data transferred: %ld bytes\n",secs, usecs, count);
rate = (double)count/((double)secs + (double)usecs/100.0);
printf("Data rate: %5.3g MiB/s\n", rate/(1024.0*1024.0));
return 0;
}
#include
void * memcpy(void * dst, void const * src, size_t len)
{
unsigned long int a,b,c,d;
unsigned long int a1,b1,c1,d1;
unsigned long int a2,b2,c2,d2;
unsigned long int a3,b3,c3,d3;
long * plDst = (long *) dst;
long const * plSrc = (long const *) src;
//if (!((unsigned long)src & 0xFFFC) && !((unsigned long)dst & 0xFFFC))
//{
while (len >= 64)
{
a = plSrc[0];
b = plSrc[1];
c = plSrc[2];
d = plSrc[3];
a1 = plSrc[4];
b1 = plSrc[5];
c1 = plSrc[6];
d1 = plSrc[7];
a2 = plSrc[8];
b2 = plSrc[9];
c2 = plSrc[10];
Re: initramfs vs initrd
On Mon, Aug 25, 2008 at 02:57:14PM +0200, =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: >Hello, > >What is the difference between initramfs and initrd ? You could poke around in the Documentation directory of the kernel. That should answer your question. Briefly, initramfs is a gzipped cpio archive. initrd is typically a compressed ext2 filesystem and requires a ramdisk to be unpacked to. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ttyS0
Hello, I must create a ttyS0 console for my ppc board. Can someone advice an example ? Thanks Sébastien Chrétien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Fix level IRQ handling on Xilinx INTC with ARCH=powerpc
On Mon, Aug 25, 2008 at 6:55 AM, Sergey Temerkhanov <[EMAIL PROTECTED]> wrote: > This fixes the missing acknowledge at the end of handle_level_irq(). > > It adds a field flags to struct irq_chip. If IRQ_CHIP_UNMASK_ACK is set in > this field, acknowledge is performed before unmasking. Can this fix be handled in the XINTC controller driver itself? This patch unconditionally adds what is essentially a device specific fixup to *every* Linux platform. I cannot see that flying very far. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: initramfs vs initrd
ok thank you 2008/8/25, Josh Boyer <[EMAIL PROTECTED]>: > > On Mon, Aug 25, 2008 at 02:57:14PM +0200, > =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: > >Hello, > > > >What is the difference between initramfs and initrd ? > > > You could poke around in the Documentation directory of the kernel. That > should answer your question. > > Briefly, initramfs is a gzipped cpio archive. initrd is typically a > compressed ext2 filesystem and requires a ramdisk to be unpacked to. > > josh > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Fix level IRQ handling on Xilinx INTC with ARCH=powerpc
On Monday 25 August 2008 18:26:54 Grant Likely wrote: >This > patch unconditionally adds what is essentially a device specific fixup > to *every* Linux platform. I cannot see that flying very far. > I know that. But without IRQ_CHIP_UNMASK_ACK set this fixup won'be applied so setups that are not affected should work as before. This problem was already discussed before: http://www.nabble.com/Level-IRQ-handling-on-Xilinx-INTC-with-ARCH%3Dpowerpc-td18711173.html Of course, I can just modify xilinx_intc_unmask() routine to perform acknowledge as I did before, but it seems a hack to me. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH 1/2] powerpc: add driver for simple GPIO banks
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may
be found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks. Support for other widths
may be implemented when/if needed.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
This is evolution of the `PIXIS FPGA' GPIO controller:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056731.html
Since for MPC8360E-MDS I need the same driver, I though it
would be great to do something generic.
arch/powerpc/sysdev/Kconfig |8 ++
arch/powerpc/sysdev/Makefile |2 +
arch/powerpc/sysdev/of_simple_gpio.c | 154 ++
3 files changed, 164 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/of_simple_gpio.c
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..33c8a15 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,11 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI && 4xx
default n
+
+config OF_SIMPLE_GPIO
+ bool
+ depends on PPC
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Support for simple, memory-mapped GPIO controllers.
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..239d7e8 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -36,6 +36,8 @@ ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
+obj-$(CONFIG_OF_SIMPLE_GPIO) += of_simple_gpio.o
+
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
diff --git a/arch/powerpc/sysdev/of_simple_gpio.c
b/arch/powerpc/sysdev/of_simple_gpio.c
new file mode 100644
index 000..536c0c2
--- /dev/null
+++ b/arch/powerpc/sysdev/of_simple_gpio.c
@@ -0,0 +1,154 @@
+/*
+ * Simple Memory-Mapped GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct u8_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u8 data;
+};
+
+static struct u8_gpio_chip *to_u8_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct u8_gpio_chip, mm_gc);
+}
+
+static u8 u8_pin2mask(unsigned int pin)
+{
+ return 1 << (8 - 1 - pin);
+}
+
+static int u8_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return in_8(mm_gc->regs) & u8_pin2mask(gpio);
+}
+
+static void u8_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_chip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&u8_gc->lock, flags);
+
+ if (val)
+ u8_gc->data |= u8_pin2mask(gpio);
+ else
+ u8_gc->data &= ~u8_pin2mask(gpio);
+
+ out_8(mm_gc->regs, u8_gc->data);
+
+ spin_unlock_irqrestore(&u8_gc->lock, flags);
+}
+
+static int u8_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ return 0;
+}
+
+static int u8_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ u8_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static void u8_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_chip(mm_gc);
+
+ u8_gc->data = in_8(mm_gc->regs);
+}
+
+static int __init u8_simple_gpiochip_add(struct device_node *np)
+{
+ int ret;
+ struct u8_gpio_chip *u8_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ u8_gc = kzalloc(sizeof(*u8_gc), GFP_KERNEL);
+ if (!u8_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&u8_gc->lock);
+
+ mm_gc = &u8_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = u8_gpio_save_regs;
+ of_gc->gpio_cells = 2;
+ gc->ngpio = 8;
+ gc->direction_input = u8_gpio_dir_in;
+ gc->direction_output = u8_gpio_dir_out;
+ gc->get = u8_gpio_get;
+ gc->set = u8_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+ return 0;
+err:
+ kfree(u8_gc);
+ return ret;
+}
+
+static int __init simpl
[RFC PATCH 2/2] powerpc/83xx: mpc836x_mds: add support for USB Host
Various changes to support QE USB Host on a MPC8360E-MDS board:
- Update the device tree per QE USB bindings;
- Configure QE Par IO;
- Set up BCSR for both USB Host and Peripheral modes;
- Add timer (GTM) node;
- Add gpio-controller node for BCSR13 bank;
- Select FSL_GTM, QE_GPIO and OF_SIMPLE_GPIO.
The work is loosely based on Li Yang's patch[1], which is used
to support peripheral mode only.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
The s-o-b line of the original patch preserved here.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 44 +++-
arch/powerpc/platforms/83xx/Kconfig |3 ++
arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 +++-
3 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index ada8446..0be98f3 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -69,8 +69,19 @@
};
[EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "board-control";
reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio",
+"simple-gpio-bank";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
};
};
@@ -191,10 +202,21 @@
};
[EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
reg = <0x1400 0x100>;
+ ranges = <0 0x1400 0x100>;
device_type = "par_io";
num-ports = <7>;
+ qe_pio_b: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x18 0x18>;
+ gpio-controller;
+ };
+
pio1: [EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -278,6 +300,15 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-gtm",
+"fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ clock-frequency = <13200>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ };
+
[EMAIL PROTECTED] {
cell-index = <0>;
compatible = "fsl,spi";
@@ -297,11 +328,20 @@
};
[EMAIL PROTECTED] {
- compatible = "qe_udc";
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
- mode = "slave";
+ fsl,fullspeed-clock = "clk21";
+ fsl,lowspeed-clock = "brg9";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&bcsr135 0 /* SPEED */
+&bcsr134 1>; /* POWER */
};
enet0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/Kconfig
b/arch/powerpc/platforms/83xx/Kconfig
index 6159c5d..558458d 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -58,6 +58,9 @@ config MPC836x_MDS
bool "Freescale MPC836x MDS"
select DEFAULT_UIMAGE
select QUICC_ENGINE
+ select QE_GPIO
+ select OF_SIMPLE_GPIO
+ select FSL_GTM
help
This option enables support for the MPC836x MDS Processor Board.
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 9d46e5b..58aabfb 100644
--- a/arch/powerpc/platforms/83xx/mpc836x
Re: initramfs vs initrd
When the kernel is booting, is it possible to check if the initrd is good ? 2008/8/25, Sébastien Chrétien <[EMAIL PROTECTED]>: > > ok thank you > > > > 2008/8/25, Josh Boyer <[EMAIL PROTECTED]>: >> >> On Mon, Aug 25, 2008 at 02:57:14PM +0200, >> =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote: >> >Hello, >> > >> >What is the difference between initramfs and initrd ? >> >> >> You could poke around in the Documentation directory of the kernel. That >> should answer your question. >> >> Briefly, initramfs is a gzipped cpio archive. initrd is typically a >> compressed ext2 filesystem and requires a ramdisk to be unpacked to. >> >> josh >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: gdb problems with threads on mpc512x
Dear Daniele Bosi, In message <[EMAIL PROTECTED]> you wrote: > > > Please post plain text only on mailing lists. > I encountered several problem debugging multithreated software with gdb > on mpc512x, remotely (gdbserver) and locally. > I built gdb 6.8 from scratch, but it's crashing when I stop execution > into a thread. > > Did anyone get it to work correctly? We use GDB 6.7 in our ELDK 4.2; we didn't encounter such problems in our tests. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] I often quote myself; it adds spice to my conversation. - G. B. Shaw ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why does one "stw" fail with address translation disabled in PPC405EP?
Hi, I think maybe you have known this project named XtratuM (http://www.xtratum.org). I'm porting it from x86 to PPC405. The implementation on PPC440 has been basically finished (ftp://dslab.lzu.edu.cn/pub/xtratum/xtratum-ppc/snapshots/xtratum-ppc-20071205.tar.bz2) and I know there was discussion about it in this mail list before. XtratuM is an ADEOS based nano kernel. It aims for realtime and is designed to provide virtual timer, virtual interrupt and memory space sperations for domains. Each domain is loaded by a userspace program (instead of the root domain as a kernel module) and the loader will load the domain's (ELF staticly excutable) PT_LOAD section into memory, and then raise a properly system call (passing the structurized loaded data as arguments) to load the domain via load_domain_sys() of XtratuM, and at the last step of loading the domain, xtratum will jump to the entry code of the new domain(asm wrappered start() routine) and then everything should be fine. 0x10a0 is the entry point of the test domain, and that is why I need to start execution from it. I think I can say something of my analysis so far for the cause of my problem. Thanks for the mention of memory size. Once the kernel module of XtratuM is loaded, the symbols of it are placed to virtual addresses like 0xc3xx. Because in normal state, address translation is enabled (MSR[IR, DR] = [1, 1]), these addresses are okay. However, when loading the domain, because the entry point 0x10a0 is not in TLB and it should be reloaded, Data TLB Miss Exception arises and DTLBMiss is called. The exception clears MSR[IR, DR], so address translation is disabled and physical address should be used at this moment. If we want something at the virtual address of 0xc3xx, we must access the physical addresses like 0x03xx. Nevertheless, the limitation of 32MB memory makes the valid physical address range from 0x0 to 0x1ff. Therefore, during the exception handling, the addresses out of range should not be accessed, but the instructions cannot know the memory limitation in advance and tries to do something in addresses such as 0x03072da0 based on the address translation mechanism, which leads to machine check. I haved tried to append "mem=32M" to kernel command line but no help. I think it is because when loading the kernel in normal state, address translation is enabled and the virtual addresses are okay. Kernel cannot foresee that there is going to be a TLB miss exception and the illegal physical addresses like 0x03xx may be accessed. So any ideas for this problem are welcome. Thank you very much for taking care. Best Wishes Zhou Rui 2008-08-25 在 2008-08-24日的 20:55 +0200，Wolfgang Denk写道： > Dear Zhou Rui, > > In message <[EMAIL PROTECTED]> you wrote: > > > > > >I am running a kernel module which will execute a user space > > > >application. The entry point of the application is 0x10a0. At the > > > > > > That should be the first clue that you are doing it wrong. Don't do > > > stuff like that in modules... > > > > Oh, but our project needs a function like that ... > > You should really think about this. Why do you think you need this? > What exactly are you trying to do? [Probably there are better > approaches to solve your problem...] > > It is physical address at this moment. Address translation is disabled > > automatically (MSR[IR, DR] = [0, 0]) because of TLB Miss Exception and > > Instrunction Storage Exception. > > Hm.. are you absolutely sure that the 0x10a0 mentioned above is a > physical address? > > > > Do you have enough DRAM to cover that? Some of those boards only come > > > with 32MiB of DRAM. > > > > My board only has 32MB DRAM. Do you mean 32MB is not enough for that? > > Well, 0x1000'00A0 is above 256 MB, while you have only 32 MB RAM > which is most probably mapped from 0x'...0x01FF'... So > what you claim to be a physical address (and I think your claim is > wrong) is far outside available physical memory. > > > The same codes can run well in a PPC440EP (Yosemite Board) which owns > > 256MB DRAM. At the beginning of my work, I thought memory size may be > > the cause of failure. But I did not know how to demonstrate it. So if > > the limitation of 32MB DRAM leads to the failure, are there any methods > > for the codes to solve it? > > I think you got lost on the wrong track. Please describe which task > you want to implement, and there might be another, better approach > for it. > > Best regards, > > Wolfgang Denk __ �Ͽ�ע���Ż�? http://cn.mail.yahoo.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Check rc of notifier chain for memory remove
The return code from invocation of the notifier for pSeries_reconfig_chain during update of the device tree is not checked. This causes writes to /proc/ppc64/ofdt to update memory properties (i.e. ibm,dyamic-reconfiguration-memory) to always return success, instead of the result of the notifier chain. This happens specifically when we remove/add memory from the device tree on machines using memory specified in the ibm,dynamic-reconfiguration-memory property of the device tree. Signed-off-by: Nathan Fontenot <[EMAIL PROTECTED]> --- Index: linux-2.6-paulus/arch/powerpc/platforms/pseries/reconfig.c === --- linux-2.6-paulus.orig/arch/powerpc/platforms/pseries/reconfig.c 2008-08-25 13:08:27.0 -0500 +++ linux-2.6-paulus/arch/powerpc/platforms/pseries/reconfig.c 2008-08-25 13:45:12.0 -0500 @@ -466,11 +466,11 @@ else action = PSERIES_DRCONF_MEM_REMOVE; - blocking_notifier_call_chain(&pSeries_reconfig_chain, -action, value); + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain, + action, value); } - return 0; + return rc; } /** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 FEC problems
I'm adding the Analogue & Micro Boa (MPC5200/B) platform to the public 2.6.26 tree. Under heavy network load (sometimes even not so heavy!), I get this error: net eth0: FEC_IEVENT_RFIFO_ERROR I've read the thread about how this leads to an incorrect call to the PHY code in the ISR. It's good to know that part of the problem is being worked on. My question is - what exactly does this error imply? Looking at the MPC5200 manual doesn't give much info - just that there was a Rx FIFO error. I'm also perplexed by the fact that I have two slightly different Boa boards (same CPU rev, speed, etc). About the only thing that's different is the SDRAM setup. One board is rock solid while the other gets this error almost immediately. Also, I sometimes get a Tx timeout on this platform (the one that fails as above). net eth0: transmit timed out Note that I don't have any trouble with this platform running RedBoot or eCos, just Linux :-( Here's the basic info on my platform: [EMAIL PROTECTED]:~ cat /proc/cpuinfo processor : 0 cpu : G2_LE clock : 396.00MHz revision: 1.4 (pvr 8082 2014) bogomips: 49.40 timebase: 2475 Ideas? Any help graciously accepted. n.b. I'm not currently subscribed to this list, so please CC me on any replies. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Add low level PLL config register interface module
Kumar Gala wrote: On Aug 25, 2008, at 5:41 AM, Kevin Diggs wrote: This adds a small module to handle the low level details of dealing with the PLL config register (HID1) found in the IBM 750GX. It provides 2 possible interfaces, both selectable via kernel config options. One is a sysfs attribute and the other is a normal function API. It is called pll_if. The determination of the bus frequency is what worked on a PowerMac 8600. Any suggestions on a more general solution are welcome. WARNING - I used some #ifdefs - Let the fur fly! My name is Kevin Diggs and I approve this patch. This really should be split into two patches. One for the perl script and one for the actual kernel code. First, thanks for taking the time for the review! I can do that. But how? Do I respin everything as x/5? Do I only send out the PERL script as 5/4? Do I redo patch 1 as 1a/4 and 1b/4 (or 1.1/4 and 1.2/4)? Scanning the actual kernel code you have a lot of #ifdef's that should be cleaned up: Can't #ifdef CONFIG_PPC_750GX_DUAL_PLL_IF_SYSFS just be #ifdef CONFIG_SYSFS and the same for CONFIG_PPC_750GX_DUAL_PLL_IF_HRTIMER & CONFIG_PPC_750GX_DUAL_PLL_IF_CPU_FREQ? I like flexibility. So I allow this module to be configured with either one or both (or none - if you just want some dead code!) of the available interfaces. As an example, CONFIG_..._PLL_IF_SYSFS adds the sysfs attribute to directly control the PLL from user space via writes to the attribute file under /sys. On my system, a PowerMac 8600, this shows up in /sys/devices/system/cpu/cpu0/ppc750gxpll. CONFIG_..._PLL_IF_CPU_FREQ adds the public API functions that are used by the cpufreq driver. CONFIG_..._PLL_IF_HRTIMER causes it to use the HR timer stuff. This results in MUCH lower latencies (102 usec vs 3900 usec (HZ=250)). But I did not want to REQUIRE HR timers (even though they are pretty cool!). Did I mention that I like flexibility? Seriously, should I add a check that at least one of ..._SYSFS or ..._CPU_FREQ is defined and refuse to compile otherwise? Via a pragma or something? #ifdef CONFIG_PPC_OF seems unnecessary as all PPC always has this set. I ... uh ... have no idea? Should I remove it? What's up with #define MULFIRST and the #if 0? This was just some goofing off in a debug message. I was playing around trying to see what effect various code arrangements had on accuracy. Since this is in debug code I was kinda hoping for some leniancy. The "#if 0" is removing code that ... prevented preemption between the processor speed switch and the changing of the loops_per_jiffy value. The idea was that I did not want to change any sleeps. I now think that processor speed is not a determining factor in delays. I think the time base register (or decrementer) are used. I don't even change the loops_per_jiffy any more (Maybe that is incorrect?). I left this code in there to potentially jog my memory if I find myself debugging some problem in the future? Would a comment be helpful? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev At the tone the timebase will be 12499983. No trailing 0s. Very bad for accuracy. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Efficient memcpy()/memmove() for G2/G3 cores...
On Mon, 2008-08-25 at 15:06 +0200, David Jander wrote: > Hi Matt, > > On Monday 25 August 2008 13:00:10 Matt Sealey wrote: > > The focus has definitely been on VMX but that's not to say lower power > > processors were forgotten :) > > lower-power (pun intended) is coming strong these days, as energy-efficiency > is getteing more important every day. And the MPC5121 is a brand-new embedded > processor, that will pop-up in quite a lot devices around you most > probably ;-) It would be useful of somebody interested in getting things things into glibc did the necessary FSF copyright assignment stuff and worked toward integrating them. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ttyS0
man mknod - k On Aug 25, 2008, at 9:16 AM, Sébastien Chrétien wrote: Hello, I must create a ttyS0 console for my ppc board. Can someone advice an example ? Thanks Sébastien Chrétien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Add cpufreq driver for the IBM PowerPC 750GX
Arnd Bergmann wrote:
On Monday 25 August 2008, Kevin Diggs wrote:
+ * cf750gx.c - cpufreq driver for the dual PLLs in the 750gx
Thanks for posting this driver and for your attention for detail
and for documentation in particular. Few people bother to write
documentation at this level.
I don't understand enough of cpufreq or your hardware to comment
on that, but please let me give you a few hints on coding style.
+ * Copyright (C) 2008 kevin Diggs
Most people list their email address here as well
For reasons I'd rather not go into, my email address is not likely
to remain valid for much longer.
+#define cf750gxmChangingPll(0x8000)
+#define cf750gxmChangingPllBit (31)
+#define cf750gxmTurningIdlePllOff (0x4000)
+#define cf750gxmTurningIdlePllOffBit (30)
constants should be ALL_CAPS, not sIllYCaPS.
Are cf750gxm_CHANGING_PLL and cf750gxm_CHANGING_PLL_BIT_POS ok?
+struct pll_750fgx_t {
+ unsigned short min_ratio; /* min bus ratio */
+ unsigned short max_ratio; /* max bus ratio */
+ unsigned int min_core; /* min core frequency per spec (KHz) */
+ unsigned int max_core; /* max core frequency per spec (KHz) */
+};
please drop the _t at the end of the identifier.
done
+MODULE_AUTHOR("Kevin Diggs");
+MODULE_DESCRIPTION("750GX Dual PLL cpufreq driver");
+MODULE_LICENSE("GPL");
Move this to the end.
done
+struct cf750gx_t_call_data {
+ struct cpufreq_freqs freqs;
+ unsigned long current_pll;
+ int idle_pll_off;
+};
drop the _t here, or make explicit what is meant by it.
Now that I look at it the _t is supposed to be at the end. It is
meant to indicate that this is a structure tag or type. I'll
remove it.
+static const struct pll_750fgx_t __initdata pll_750fx = {
+ .min_ratio = 2,
+ .max_ratio = 20,
+ .min_core = 40,
+ .max_core = 80,
+};
+
+static const struct pll_750fgx_t __initdata pll_750gx = {
+ .min_ratio = 2,
+ .max_ratio = 20,
+ .min_core = 50,
+ .max_core = 100,
+};
Are these correct on any board? If they can be different
depending on the board design, it would be better to get
this data from the device tree.
They are a spceification of the processor itself. Should be
the same for any board using the 750GX (or FX).
+static DECLARE_COMPLETION(cf750gx_v_exit_completion);
+
+static unsigned int override_min_core = 0;
+static unsigned int override_max_core = 0;
+static unsigned int minmaxmode = 0;
+
+static unsigned int cf750gx_v_min_core = 0;
+static unsigned int cf750gx_v_max_core = 0;
+static int cf750gx_v_idle_pll_off = 0;
+static int cf750gx_v_min_max_mode = 0;
+static unsigned long cf750gx_v_state_bits = 0;
Is 0 a meaningful value for these? If it just means 'uninitialized',
then better don't initialize them in the first place, for clarity.
The first 3 are module parameters. For the first 2, 0 means
that they were not set. minmaxmode is a boolean. 0 is the
default of disabled.
When I was initially writing the code I figured I would
need the min and max core frequencies in several places.
As it turns out they are only used in the code
initialization routine (cf750gx_init()). I have made
them locals.
..._idle_pll_off is a boolean for a sysfs attribute. 0 is
the default of disabled.
..._min_max_mode is a boolean to hold the state of
minmaxmode. Seems to be only used to print the current
value.
..._state_bits is a global to maintain state.
Does the PowerPC suffer any performance penalties when
accessing shorts compared to ints? Can I save a few bytes
by using shorts?
+static struct cpufreq_frequency_table *cf750gx_v_f_table;
+static struct cpufreq_frequency_table *cf750gx_v_freq_table;
+static struct cpufreq_frequency_table *cf750gx_v_min_max_freq_table;
+
+static struct cf750gx_t_call_data cf750gx_v_switch_call_data;
+static struct cf750gx_t_call_data cf750gx_v_lock_call_data;
+static struct notifier_block cf750gx_v_pll_switch_nb;
+static struct notifier_block cf750gx_v_pll_lock_nb;
Also, in general, try to avoid global variables here, even
in file scope (static), but rather put all device specific
data into a per-device data structure.
How big of a problem is this? I regret the decision to rip
the SMP stuff out. But it is kinda done. If absolutely
necessary I can put these into a structure?
+static int cf750gx_pll_switch_cb(struct notifier_block *nb, unsigned long
+ action, void *data)
+{
+struct cf750gx_t_call_data *cd;
+unsigned int idle_pll;
+unsigned int pll_off_cmd;
+unsigned int new_pll;
The whitespace appears damaged here.
Just a coding style thing. I put declarations (or definitions -
I get the two confused?) on the same indent as the block they are
in. Is this a 15 yard illegal procedure penalty?
+ cd = (struct cf750gx_t_call_data *)data;
done
data is a void pointer, so you don't need the cast, and shouldn't
have it there
Re: [PATCH] add a simple 405EP based board
On Thu, Aug 21, 2008 at 10:07:58AM +0200, Markus Brunner wrote:
> This adds support for a simple ppc405ep board.
> At the moment, there are no 405ep boards in arch/powerpc, so this can be used
> as a template
> for new boards, or migrating them from arch/ppc.
> I2c, UART and EMAC are working. PCI could not be tested, so it was not
> included in the dts.
>
> Signed-off-by: Markus Brunner <[EMAIL PROTECTED]>
[snip]
> + EMAC0: [EMAIL PROTECTED] {
> + linux,network-index = <0>;
The network-index property is obsolete, you shouldn't need it any
more.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][for 2.6.27] fs_enet: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()
From: Heiko Schocher <[EMAIL PROTECTED]>
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Updated to apply cleanly to top of linus's tree.
- k
arch/powerpc/include/asm/cpm2.h|5 +
drivers/net/fs_enet/fs_enet-main.c |8
drivers/net/fs_enet/mac-scc.c |8 +++-
3 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm2.h b/arch/powerpc/include/asm/cpm2.h
index 2a6fa01..0f5e8ff 100644
--- a/arch/powerpc/include/asm/cpm2.h
+++ b/arch/powerpc/include/asm/cpm2.h
@@ -337,6 +337,11 @@ typedef struct scc_param {
uintscc_tcrc; /* Internal */
} sccp_t;
+/* Function code bits.
+*/
+#define SCC_EB ((u_char) 0x10) /* Set big endian byte order */
+#define SCC_GBL((u_char) 0x20) /* Snooping enabled */
+
/* CPM Ethernet through SCC1.
*/
typedef struct scc_enet {
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 9a51ec8..9d46182 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -792,6 +792,10 @@ static int fs_enet_open(struct net_device *dev)
int r;
int err;
+ /* to initialize the fep->cur_rx,... */
+ /* not doing this, will cause a crash in fs_enet_rx_napi */
+ fs_init_bds(fep->ndev);
+
if (fep->fpi->use_napi)
napi_enable(&fep->napi);
@@ -1167,6 +1171,10 @@ static struct of_device_id fs_enet_match[] = {
.compatible = "fsl,cpm1-scc-enet",
.data = (void *)&fs_scc_ops,
},
+ {
+ .compatible = "fsl,cpm2-scc-enet",
+ .data = (void *)&fs_scc_ops,
+ },
#endif
#ifdef CONFIG_FS_ENET_HAS_FCC
{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 029b3c7..22f50dd 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -47,7 +47,6 @@
#include "fs_enet.h"
/*/
-
#if defined(CONFIG_CPM1)
/* for a 8xx __raw_xxx's are sufficient */
#define __fs_out32(addr, x)__raw_writel(x, addr)
@@ -62,6 +61,8 @@
#define __fs_out16(addr, x)out_be16(addr, x)
#define __fs_in32(addr)in_be32(addr)
#define __fs_in16(addr)in_be16(addr)
+#define __fs_out8(addr, x) out_8(addr, x)
+#define __fs_in8(addr) in_8(addr)
#endif
/* write, read, set bits, clear bits */
@@ -262,8 +263,13 @@ static void restart(struct net_device *dev)
/* Initialize function code registers for big-endian.
*/
+#ifndef CONFIG_NOT_COHERENT_CACHE
+ W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+ W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
W8(ep, sen_genscc.scc_rfcr, SCC_EB);
W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif
/* Set maximum bytes per receive buffer.
* This appears to be an Ethernet frame size, not the buffer
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
The calculation to get TI_CPU based off of SPRG3 was just plain wrong. Since we already have thread_info in r9 there is no reason to bother to figure it out again. This was pointed out by Chen Gong <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- Paul, this is in for-2.6.27 branch. - k arch/powerpc/kernel/idle_6xx.S | 13 +++-- arch/powerpc/kernel/idle_e500.S | 11 ++- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S index 019b02d..0138d88 100644 --- a/arch/powerpc/kernel/idle_6xx.S +++ b/arch/powerpc/kernel/idle_6xx.S @@ -151,19 +151,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) * Return from NAP/DOZE mode, restore some CPU specific registers, * we are called with DR/IR still off and r2 containing physical * address of current. R11 points to the exception frame (physical - * address). We have to preserve r10. + * address). We have to preserve r10. R9 contains the physical + * address of thread_info. */ _GLOBAL(power_save_ppc32_restore) - lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ - stw r9,_NIP(r11)/* make it do a blr */ - #ifdef CONFIG_SMP - mfspr r12,SPRN_SPRG3 - lwz r11,TI_CPU(r12) /* get cpu number * 4 */ + lwz r11,TI_CPU(r9) /* get cpu number * 4 */ slwir11,r11,2 #else li r11,0 #endif + + lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ + stw r9,_NIP(r11)/* make it do a blr */ + /* Todo make sure all these are in the same page * and load r11 (@ha part + CPU offset) only once */ diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S index 0630403..c9d7234 100644 --- a/arch/powerpc/kernel/idle_e500.S +++ b/arch/powerpc/kernel/idle_e500.S @@ -76,18 +76,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP) /* * Return from NAP/DOZE mode, restore some CPU specific registers, * r2 containing physical address of current. + * r9 points to thread_info * r11 points to the exception frame (physical address). * We have to preserve r10. */ _GLOBAL(power_save_ppc32_restore) - lwz r9,_LINK(r11) /* interrupted in e500_idle */ - stw r9,_NIP(r11)/* make it do a blr */ - #ifdef CONFIG_SMP - mfspr r12,SPRN_SPRG3 - lwz r11,TI_CPU(r12) /* get cpu number * 4 */ + lwz r11,TI_CPU(r9) /* get cpu number * 4 */ slwir11,r11,2 #else li r11,0 #endif + + lwz r9,_LINK(r11) /* interrupted in e500_idle */ + stw r9,_NIP(r11)/* make it do a blr */ + b transfer_to_handler_cont -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
The calculation to get TI_CPU based off of SPRG3 was just plain wrong. Just offset off the stack pointer (to get to thread_info) like all the other references to TI_CPU do. This was pointed out by Chen Gong <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- The first version was just brain damaged. This version should be cleaner and doesn't assume anything about the call site having r9 setup already. (updated for-2.6.27 w/this and rebased to top of linus). - k arch/powerpc/kernel/idle_6xx.S |3 ++- arch/powerpc/kernel/idle_e500.S |3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S index 019b02d..6dfcdb6 100644 --- a/arch/powerpc/kernel/idle_6xx.S +++ b/arch/powerpc/kernel/idle_6xx.S @@ -158,7 +158,8 @@ _GLOBAL(power_save_ppc32_restore) stw r9,_NIP(r11)/* make it do a blr */ #ifdef CONFIG_SMP - mfspr r12,SPRN_SPRG3 + rlwinm r12,r1,0,0,31-THREAD_SHIFT + tophys(r12,r12) /* check local flags */ lwz r11,TI_CPU(r12) /* get cpu number * 4 */ slwir11,r11,2 #else diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S index 0630403..47a1a98 100644 --- a/arch/powerpc/kernel/idle_e500.S +++ b/arch/powerpc/kernel/idle_e500.S @@ -84,10 +84,11 @@ _GLOBAL(power_save_ppc32_restore) stw r9,_NIP(r11)/* make it do a blr */ #ifdef CONFIG_SMP - mfspr r12,SPRN_SPRG3 + rlwinm r12,r1,0,0,31-THREAD_SHIFT lwz r11,TI_CPU(r12) /* get cpu number * 4 */ slwir11,r11,2 #else li r11,0 #endif + b transfer_to_handler_cont -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.27' (updated)
Please pull from 'for-2.6.27' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.27 to receive the following updates: arch/powerpc/boot/dts/mpc8641_hpcn.dts|2 arch/powerpc/boot/dts/tqm8548-bigflash.dts|8 arch/powerpc/boot/dts/tqm8548.dts |3 arch/powerpc/boot/wrapper |2 arch/powerpc/configs/83xx/asp8347_defconfig | 1334 + arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 188 +- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 188 +- arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 172 +- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 176 +- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 175 +- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 172 +- arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 168 +- arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 172 +- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 183 +- arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 351 arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 340 arch/powerpc/configs/83xx/sbc834x_defconfig | 239 ++- arch/powerpc/configs/85xx/ksi8560_defconfig | 95 - arch/powerpc/configs/85xx/mpc8536_ds_defconfig| 1654 ++ arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 71 arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 178 +- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 98 - arch/powerpc/configs/85xx/mpc8568mds_defconfig| 121 + arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 177 +- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 85 - arch/powerpc/configs/85xx/sbc8548_defconfig | 63 arch/powerpc/configs/85xx/sbc8560_defconfig | 69 arch/powerpc/configs/85xx/stx_gp3_defconfig | 163 +- arch/powerpc/configs/85xx/tqm8540_defconfig | 112 + arch/powerpc/configs/85xx/tqm8541_defconfig | 139 + arch/powerpc/configs/85xx/tqm8548_defconfig | 129 + arch/powerpc/configs/85xx/tqm8555_defconfig | 139 + arch/powerpc/configs/85xx/tqm8560_defconfig | 139 + arch/powerpc/configs/adder875_defconfig | 55 arch/powerpc/configs/asp8347_defconfig| 1214 arch/powerpc/configs/c2k_defconfig| 245 +-- arch/powerpc/configs/ep8248e_defconfig| 198 ++ arch/powerpc/configs/ep88xc_defconfig | 57 arch/powerpc/configs/linkstation_defconfig| 133 + arch/powerpc/configs/mpc7448_hpc2_defconfig | 72 arch/powerpc/configs/mpc8272_ads_defconfig| 132 + arch/powerpc/configs/mpc83xx_defconfig| 389 - arch/powerpc/configs/mpc8536_ds_defconfig | 1637 - arch/powerpc/configs/mpc85xx_defconfig| 207 +- arch/powerpc/configs/mpc8610_hpcd_defconfig | 165 +- arch/powerpc/configs/mpc8641_hpcn_defconfig | 215 +- arch/powerpc/configs/mpc866_ads_defconfig | 61 arch/powerpc/configs/mpc885_ads_defconfig | 57 arch/powerpc/configs/pq2fads_defconfig| 147 + arch/powerpc/configs/prpmc2800_defconfig | 125 + arch/powerpc/configs/sbc8641d_defconfig | 173 +- arch/powerpc/configs/storcenter_defconfig | 113 + arch/powerpc/kernel/idle_6xx.S|3 arch/powerpc/kernel/idle_e500.S |3 arch/powerpc/sysdev/cpm_common.c | 37 arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 57 files changed, 8097 insertions(+), 4658 deletions(-) Kumar Gala (3): powerpc: Fix whitespace merge in mpc8641 hpcn device tree powerpc: Update defconfigs for FSL PPC boards powerpc: Fix determining TI_CPU in power_save_ppc32_restore() Laurent Pinchart (1): cpm2: Fix race condition in CPM2 GPIO library. Scott Wood (1): powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target Timur Tabi (1): powerpc: fix memory leaks in QE library Wolfgang Grandegger (1): powerpc/85xx: TQM8548: DTS file fixes and cleanup ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/ idle_6xx.S index 019b02d..0138d88 100644 --- a/arch/powerpc/kernel/idle_6xx.S +++ b/arch/powerpc/kernel/idle_6xx.S @@ -151,19 +151,20 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) * Return from NAP/DOZE mode, restore some CPU specific registers, * we are called with DR/IR still off and r2 containing physical * address of current. R11 points to the exception frame (physical - * address). We have to preserve r10. + * address). We have to preserve r10. R9 contains the physical + * address of thread_info. */ _GLOBAL(power_save_ppc32_restore) - lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ - stw r9,_NIP(r11)/* make it do a blr */ - #ifdef CONFIG_SMP - mfspr r12,SPRN_SPRG3 - lwz r11,TI_CPU(r12) /* get cpu number * 4 */ + lwz r11,TI_CPU(r9) /* get cpu number * 4 */ slwir11,r11,2 #else li r11,0 #endif + + lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ + stw r9,_NIP(r11)/* make it do a blr */ + this is just brain damaged as I'm clobber r11 before setting up r9 with LR. V2 of the patch does things right. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get some more bug-fixes and defconfig updates for powerpc. Almost all of the lines changed are in the defconfigs. The rest of the changes are fixes for various regressions, build failures, and a possible oops, plus two commits that fix memory leaks and race conditions in code that is only used on embedded systems with Freescale processors. Thanks, Paul. arch/powerpc/boot/dts/mpc8641_hpcn.dts|2 arch/powerpc/boot/dts/tqm8548-bigflash.dts|8 arch/powerpc/boot/dts/tqm8548.dts |3 arch/powerpc/boot/wrapper |2 arch/powerpc/configs/83xx/asp8347_defconfig | 312 - arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 188 -- arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 188 -- arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 172 +++-- arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 176 +++--- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 175 +++-- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 172 +++-- arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 168 +++-- arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 172 +++-- arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 183 +++--- arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 351 +-- arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 340 -- arch/powerpc/configs/83xx/sbc834x_defconfig | 239 +++-- arch/powerpc/configs/85xx/ksi8560_defconfig | 95 - arch/powerpc/configs/85xx/mpc8536_ds_defconfig| 167 + arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 71 +++- arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 178 ++ arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 98 - arch/powerpc/configs/85xx/mpc8568mds_defconfig| 121 +-- arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 177 ++ arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 85 +++-- arch/powerpc/configs/85xx/sbc8548_defconfig | 63 ++- arch/powerpc/configs/85xx/sbc8560_defconfig | 69 +++- arch/powerpc/configs/85xx/stx_gp3_defconfig | 163 ++--- arch/powerpc/configs/85xx/tqm8540_defconfig | 112 -- arch/powerpc/configs/85xx/tqm8541_defconfig | 139 ++-- arch/powerpc/configs/85xx/tqm8548_defconfig | 129 +-- arch/powerpc/configs/85xx/tqm8555_defconfig | 139 ++-- arch/powerpc/configs/85xx/tqm8560_defconfig | 139 ++-- arch/powerpc/configs/adder875_defconfig | 55 ++- arch/powerpc/configs/c2k_defconfig| 245 ++--- arch/powerpc/configs/chrp32_defconfig | 141 +--- arch/powerpc/configs/ep8248e_defconfig| 198 +-- arch/powerpc/configs/ep88xc_defconfig | 57 ++- arch/powerpc/configs/g5_defconfig | 227 +++- arch/powerpc/configs/iseries_defconfig| 87 +++-- arch/powerpc/configs/linkstation_defconfig| 133 +-- arch/powerpc/configs/maple_defconfig | 381 ++--- arch/powerpc/configs/mpc7448_hpc2_defconfig | 72 +++- arch/powerpc/configs/mpc8272_ads_defconfig| 132 +-- arch/powerpc/configs/mpc83xx_defconfig| 389 +++-- arch/powerpc/configs/mpc85xx_defconfig| 207 +++ arch/powerpc/configs/mpc8610_hpcd_defconfig | 165 + arch/powerpc/configs/mpc8641_hpcn_defconfig | 215 +++- arch/powerpc/configs/mpc866_ads_defconfig | 61 ++- arch/powerpc/configs/mpc885_ads_defconfig | 57 ++- arch/powerpc/configs/pmac32_defconfig | 241 +++-- arch/powerpc/configs/ppc64_defconfig | 237 +++-- arch/powerpc/configs/ppc6xx_defconfig | 144 arch/powerpc/configs/pq2fads_defconfig| 147 ++-- arch/powerpc/configs/prpmc2800_defconfig | 125 +-- arch/powerpc/configs/ps3_defconfig| 153 +++- arch/powerpc/configs/pseries_defconfig| 172 +++-- arch/powerpc/configs/sbc8641d_defconfig | 173 +++-- arch/powerpc/configs/storcenter_defconfig | 113 -- arch/powerpc/platforms/ps3/htab.c | 269 +-- arch/powerpc/platforms/ps3/setup.c|1 arch/powerpc/platforms/ps3/spu.c | 18 + arch/powerpc/platforms/pseries/setup.c|1 arch/powerpc/sysdev/cpm_common.c | 37 +- arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 drivers/oprofile/cpu_buffer.c |4 drivers/oprofile/event_buffer.c
Re: [PATCH] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
> #ifdef CONFIG_SMP > - mfspr r12,SPRN_SPRG3 > - lwz r11,TI_CPU(r12) /* get cpu number * 4 */ > + lwz r11,TI_CPU(r9) /* get cpu number * 4 */ > slwir11,r11,2 > #else > li r11,0 > #endif > + > + lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */ > + stw r9,_NIP(r11)/* make it do a blr */ > + hrm... you just clobbered r11, won't work very well :-) Ben. > /* Todo make sure all these are in the same page >* and load r11 (@ha part + CPU offset) only once >*/ > diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S > index 0630403..c9d7234 100644 > --- a/arch/powerpc/kernel/idle_e500.S > +++ b/arch/powerpc/kernel/idle_e500.S > @@ -76,18 +76,19 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP) > /* > * Return from NAP/DOZE mode, restore some CPU specific registers, > * r2 containing physical address of current. > + * r9 points to thread_info > * r11 points to the exception frame (physical address). > * We have to preserve r10. > */ > _GLOBAL(power_save_ppc32_restore) > - lwz r9,_LINK(r11) /* interrupted in e500_idle */ > - stw r9,_NIP(r11)/* make it do a blr */ > - > #ifdef CONFIG_SMP > - mfspr r12,SPRN_SPRG3 > - lwz r11,TI_CPU(r12) /* get cpu number * 4 */ > + lwz r11,TI_CPU(r9) /* get cpu number * 4 */ > slwir11,r11,2 > #else > li r11,0 > #endif > + > + lwz r9,_LINK(r11) /* interrupted in e500_idle */ > + stw r9,_NIP(r11)/* make it do a blr */ > + > b transfer_to_handler_cont ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Fix determining TI_CPU in power_save_ppc32_restore()
On Mon, 2008-08-25 at 21:08 -0500, Kumar Gala wrote: > The calculation to get TI_CPU based off of SPRG3 was just plain wrong. > Just offset off the stack pointer (to get to thread_info) like all the > other references to TI_CPU do. > > This was pointed out by Chen Gong <[EMAIL PROTECTED]> > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.27' (updated)
On Mon, 2008-08-25 at 21:09 -0500, Kumar Gala wrote: > Kumar Gala (3): > powerpc: Fix whitespace merge in mpc8641 hpcn device tree > powerpc: Update defconfigs for FSL PPC boards > powerpc: Fix determining TI_CPU in power_save_ppc32_restore() Please, don't put a patch in a git pull request that has been out for review exactly ... 1mn according to the email time stamps. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 2/2] powerpc/83xx: mpc836x_mds: add support for USB Host
On Mon, Aug 25, 2008 at 07:27:36PM +0400, Anton Vorontsov wrote:
> Various changes to support QE USB Host on a MPC8360E-MDS board:
>
> - Update the device tree per QE USB bindings;
> - Configure QE Par IO;
> - Set up BCSR for both USB Host and Peripheral modes;
> - Add timer (GTM) node;
> - Add gpio-controller node for BCSR13 bank;
> - Select FSL_GTM, QE_GPIO and OF_SIMPLE_GPIO.
>
> The work is loosely based on Li Yang's patch[1], which is used
> to support peripheral mode only.
>
> [1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
>
> The s-o-b line of the original patch preserved here.
>
> Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc836x_mds.dts | 44 +++-
> arch/powerpc/platforms/83xx/Kconfig |3 ++
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 +++-
> 3 files changed, 75 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
> b/arch/powerpc/boot/dts/mpc836x_mds.dts
> index ada8446..0be98f3 100644
> --- a/arch/powerpc/boot/dts/mpc836x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
> @@ -69,8 +69,19 @@
> };
>
> [EMAIL PROTECTED],0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> device_type = "board-control";
Not the fault of this patch, obviously, but this device_type should
never have been here.
> reg = <1 0 0x8000>;
> + ranges = <0 1 0 0x8000>;
> +
> + bcsr13: [EMAIL PROTECTED] {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8360mds-bcsr-gpio",
> + "simple-gpio-bank";
> + reg = <0xd 1>;
> + gpio-controller;
> + };
> };
> };
>
> @@ -191,10 +202,21 @@
> };
>
> [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> reg = <0x1400 0x100>;
> + ranges = <0 0x1400 0x100>;
> device_type = "par_io";
Nor this one
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 FEC problems
Hello Gary, On Mon, Aug 25, 2008 at 09:36:07AM -0600, Gary Thomas wrote: > I'm adding the Analogue & Micro Boa (MPC5200/B) platform to the > public 2.6.26 tree. Under heavy network load (sometimes even > not so heavy!), I get this error: > net eth0: FEC_IEVENT_RFIFO_ERROR Yeah, I know this one :( > My question is - what exactly does this error imply? Looking at > the MPC5200 manual doesn't give much info - just that there was > a Rx FIFO error. In deed, the manual seems not very helpful. The description of the set FIFO status bit did not help me that much. > I'm also perplexed by the fact that I have two slightly different > Boa boards (same CPU rev, speed, etc). About the only thing that's > different is the SDRAM setup. One board is rock solid while the > other gets this error almost immediately. I'm not sure if this is really of importance, but do the boards have different PHYs? > Note that I don't have any trouble with this platform running RedBoot > or eCos, just Linux :-( Try this patch and please report if it worked for you: http://www.nabble.com/-PATCH--MPC52XX:-Don't-touch-pipelining-for-MPC5200B-td19028341.html All the best, Wolfram -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
