unsubscribe

[Usha Rani Konudula]

 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH v2] ftrace: On PowerPC we don't need frame pointers forCALLER_ADDRs

[Usha Rani Konudula]

unsubscribe linux-kernel

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[no subject]

[Usha Rani Konudula]

unsubscribe linux-kernel

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing

[Martyn Welch]

On Wed, 2009-02-04 at 11:47 +1100, Benjamin Herrenschmidt wrote:
 On Tue, 2009-02-03 at 15:50 +, Martyn Welch wrote:
  
  The primary CPU is spinning in smp_generic_give_timebase() waiting for
  !tbsync-ack. The secondary CPU has made it into
  smp_generic_take_timebase() and has apparently (according to some
  printk's I put in there) set tbsync-ack=1. After that I don't get
  any printk's, I guess that the one I have put in the !
  tbsync-handshake while loop is making it to the print buffer, but
  with both processors spinning it's not getting to the serial console.
  
  At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744
  seems to be the point that it stopped working correctly, that tbsync
  is now somehow becoming cached?
  
 Maybe we are missing the M bit in the mapping ?
 
 Let's see... the kernel mapping is done via BATs on those guys (ie, e600
 is a hash table based processor right ? some kind of 74xx). The code
 that sets them up is in
 
 arch/powerpc/mm/ppc_mmu_32.c
 
 In mmu_mapin_ram() we call setbat() multiple times. The last argument is
 the flags which is set to _PAGE_RAM. That should contain
 _PAGE_COHERENT when CONFIG_SMP is set unless I screwed up. IE. _PAGE_RAM
 is _PAGE_KERNEL | _PAGE_HWEXEC. _PAGE_KERNEL is _PAGE_BASE plus things,
 and _PAGE_BASE should contains _PAGE_COHERENT if CONFIG_SMP or
 CONFIG_PPC_STD_MMU are set and they should both be in your case.
 
 setbat() itself will clear _PAGE_COHERENT under some circumstances
 however. Either if the flags contain _PAGE_NO_CACHE, which should not be
 the case here, or if the CPU feature bit CPU_FTR_NEED_COHERENT is -not-
 set. I think that could be the cause of the problem.
 
 CPU_FTR_NEED_COHERENT is set as part of CPU_FTR_COMMON if CONFIG_SMP
 is set (among other things). So it -should- be set for you. since
 CPU_FTR_COMMON should be OR'ed with all CPU table entries.
 
 So I'm a bit at a loss here... unless something else went wrong.
 
 Please let me know what you find out.
 
 Cheers,
 Ben.

I think it is indeed something else. I added the patch below which
resulted in the following lines in the kernel messages:

Set BAT 2 for 0x1000 from phys:0x0 at virt:0xc000
Page coherency set
Set BAT 3 for 0x1000 from phys:0x1000 at virt:0xd000
Page coherency set
...
tbsync structure allocated at 0xef818360 for 0x48
tbsync happens to live at 0xc0515110
running happens to live at 0xc0515114

This suggests to me that whilst *tbsync and running are located within
RAM mapped by the BATs, the memory allocated for the tbsync structure is
not and is mapped via page tables. I guess this structure is then only
mapped correctly for the first core.

Martyn

-- 

diff --git a/arch/powerpc/kernel/smp-tbsync.c b/arch/powerpc/kernel/smp-tbsync.c
index a5e5452..fdeda20 100644
--- a/arch/powerpc/kernel/smp-tbsync.c
+++ b/arch/powerpc/kernel/smp-tbsync.c
@@ -117,6 +117,10 @@ void __devinit smp_generic_give_timebase(void)
 
/* if this fails then this kernel won't work anyway... */
tbsync = kzalloc( sizeof(*tbsync), GFP_KERNEL );
+   printk(tbsync structure allocated at 0x%p for 0x%x\n, tbsync, 
+   sizeof(*tbsync));
+   printk(tbsync happens to live at 0x%p\n, tbsync);
+   printk(running happens to live at 0x%p\n, running);
mb();
running = 1;
 
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index fe65c40..2035cd6 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -123,6 +123,9 @@ void __init setbat(int index, unsigned long virt, phys_addr_
int wimgxpp;
struct ppc_bat *bat = BATS[index];
 
+   printk(Set BAT %d for 0x%x from phys:0x%lx at virt:0x%lx\n, index, 
+   size, phys, virt);
+
if ((flags  _PAGE_NO_CACHE) ||
(cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0))
flags = ~_PAGE_COHERENT;
@@ -134,6 +137,11 @@ void __init setbat(int index, unsigned long virt, phys_addr
wimgxpp = flags  (_PAGE_WRITETHRU | _PAGE_NO_CACHE
   | _PAGE_COHERENT | _PAGE_GUARDED);
wimgxpp |= (flags  _PAGE_RW)? BPP_RW: BPP_RX;
+   if (wimgxpp  _PAGE_COHERENT) {
+   printk(Page coherency set\n);
+   } else {
+   printk(Page coherency cleared\n);
+   }
bat[1].batu = virt | (bl  2) | 2; /* Vs=1, Vp=0 */
bat[1].batl = BAT_PHYS_ADDR(phys) | wimgxpp;
 #ifndef CONFIG_KGDB /* want user access for breakpoints */


-- 
Martyn Welch MEng MPhil MIET (Principal Software Engineer)   T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester,  |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB  VAT:GB 729849476

___
Linuxppc-dev mailing list

Re: next-20090204 build break : ftrace

[Steven Rostedt]

On Wed, 4 Feb 2009, Sachin P. Sant wrote:

 Hi Stephen,
 
 20090204 randconfig build on powerpc fails with :
 
  CC  arch/powerpc/kernel/ftrace.o
 arch/powerpc/kernel/ftrace.c: In function __ftrace_make_nop:
 arch/powerpc/kernel/ftrace.c:204: error: dereferencing pointer to incomplete
 type
 arch/powerpc/kernel/ftrace.c: In function __ftrace_make_call:
 arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete
 type
 arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete
 type
 arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete
 type
 arch/powerpc/kernel/ftrace.c:407: error: dereferencing pointer to incomplete
 type
 make[1]: *** [arch/powerpc/kernel/ftrace.o] Error 1
 make: *** [arch/powerpc/kernel] Error 2
 
 config attached.
 

Thanks, I'll give it a try later today on my PPC64 box.

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

ADS5121 problem using audio interface

[Stefan Strobl]

Hi

I'm trying to get the audio interface working on my ADS5121 Rev4.0 and
have some questions.

I did manage to record and play audio files of type raw and format
S32_BE like this:

$ arecord -traw -c2 -fS32_BE -Dhw:0,0 testfile
$ aplay -traw -c2 -fS32_BE -Dhw:0,0 testfile

I am not able to get the auto conversion work, so that I could play a
wav file of any format. I'm getting this error:

$ aplay -Dplughw:0,0 test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono
ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to find
an usable access for 'plughw:0,0'
aplay: set_params:901: Sample format non available

I'm not sure, but I expect this to be a problem of my ALSA configuration
and this is where I'm stuck.
Does anyone have a working ALSA configuration file for the ads5121?
Or any other hints on how to overcome this problem?
Does anyone know how to convert wav files so that they can be played in
raw mode?

Many thanks
Stefan.

-
These are the steps I performed to get audio work:

I'm using kernel 2.6.24.6 (linux-2.6-denx.git/ads5121) with ALSA-1.0.15
built into the kernel and ELDK-4.2.

1. Build and install alsa-lib-1.0.15 and alsa-utils-1.0.15 natively on
the target.

$ wget ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.15.tar.bz2
$ tar xf alsa-lib-1.0.15.tar.bz2
$ cd alsa-lib-1.0.15
$ ./configure
$ make
$ make install

$ wget ftp://ftp.alsa-project.org/pub/utils/alsa-utils-1.0.15.tar.bz2
$ tar xf alsa-utils-1.0.15.tar.bz2
$ cd alsa-utils-1.0.15
$ ./configure --disable-nls
$ make
$ make install

2. Manually create the device nodes, with Minor numbers according to
output from /proc/asound/devices

$ cat /proc/asound/devices
  0: [ 0]   : control
  1:: sequencer
 16: [ 0- 0]: digital audio playback
 24: [ 0- 0]: digital audio capture
 33:: timer

$ mkdir /dev/snd
$ mknod /dev/snd/pcmC0D0p c 116 16
$ mknod /dev/snd/pcmC0D0c c 116 24
$ mknod /dev/snd/controlC0 c 116 0
$ mknod /dev/snd/timer c 116 33
$ mknod /dev/snd/seq c 116 1

3. Run aplay...

$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: ADS [MPC5121 ADS], device 0: AC97 AC97 HiFi-NULL-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

$ aplay -L
default:CARD=ADS
MPC5121 ADS,
Default Audio Device
null
Discard all samples (playback) or generate zero samples (capture)

$ aplay -traw -c2 -fS32_BE -Dhw:0,0 /dev/urandom
$ arecord -traw -c2 -fS32_BE -Dhw:0,0 testfile
$ aplay -traw -c2 -fS32_BE -Dhw:0,0 testfile
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Can not get PATA to work for Compact Flash with 2.6.28 kernel

[Steven A. Falco]

Lixin Yao wrote:
 I redefined io functions in libata-sff.c, byte operations are converted
 to 16bit word operations. Maybe I should ask for HW changes in new
 revisions of the board.
 

I do recommend that.  We got it wrong on our first board too. :-)  It
is much better to get the hardware right than to carry your endian SW
patch forever.

Two other potential issues: 1) making sure the most significant
byte enable is used, so that byte writes work correctly.  You most
likely have this correct already, or you would not have gotten this
far.

And 2) make sure you allow for the hold time / turn-off time of the
CF.  We use a 440EPx, and cannot set up the external bus controller
to generate valid cycles in all cases.  So, we added some flip-flops
to stretch the rising edge of the chip select, which guarantees proper
timing.  (I'm going a bit far afield from the purpose of this mailing
list, so if you want more details, please contact me directly.)

Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs

[Anton Vorontsov]

On Tue, Feb 03, 2009 at 07:19:55PM +0300, Anton Vorontsov wrote:
 On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote:
  
  * Anton Vorontsov avoront...@ru.mvista.com wrote:
  
   According to this discussion:
   
   http://lkml.org/lkml/2008/7/25/338
   http://lkml.org/lkml/2008/7/26/72
   
   Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug
   makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h
   requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. [...]
  
  hm, why not add PPC to FRAME_POINTERS list of architectures, and select it 
  from the powerpc arch Kconfig? Does that cause complications somewhere?
 
 -fno-omit-frame-pointers makes the code worse w/o any actual
 benefit that we would use. Plus, there is a long standing bug in
 gcc that makes -fno-omit-frame-pointer generate wrong code for PPC
 targets:
 
 http://lkml.org/lkml/2008/9/2/25
 
 That is, the only tracer that needs[1] -fno-omit-frame-pointer is
 FUNCTION_TRCER, but we workaround the issue via -mno-sched-epilog,
 quoting arch/powerpc/Makefile:
 
 # Work around a gcc code-gen bug with -fno-omit-frame-pointer.
 ifeq ($(CONFIG_FUNCTION_TRACER),y)
 KBUILD_CFLAGS   += -mno-sched-epilog
 endif

Thinking about it more... we can workaround the bug the other way,
and then permit CONFIG_FRAME_POINTER on PowerPC.

Patches are coming...

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/3] Makefile: Include arch Makefiles as late as possible

[Anton Vorontsov]

This patch gives arches more freedom on overwriting CFLAGS, specifically
on PowerPC we want to remove -fno-omit-frame-pointer flag.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 7715b2c..d1ba93f 100644
--- a/Makefile
+++ b/Makefile
@@ -525,8 +525,6 @@ else
 KBUILD_CFLAGS  += -O2
 endif
 
-include $(srctree)/arch/$(SRCARCH)/Makefile
-
 ifneq (CONFIG_FRAME_WARN,0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
@@ -555,6 +553,8 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
 KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
 endif
 
+include $(srctree)/arch/$(SRCARCH)/Makefile
+
 # arch Makefile may override CC so keep this after arch Makefile is included
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Anton Vorontsov]

Remove -fno-omit-frame-pointer flag from CFLAGS.
Remove -fno-omit-frame-pointer workarounds.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 arch/powerpc/Makefile|   10 ++
 arch/powerpc/kernel/Makefile |   10 +-
 arch/powerpc/platforms/powermac/Makefile |2 +-
 lib/Kconfig.debug|8 
 4 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 72d17f5..627aa7f 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -120,10 +120,12 @@ ifeq ($(CONFIG_6xx),y)
 KBUILD_CFLAGS  += -mcpu=powerpc
 endif
 
-# Work around a gcc code-gen bug with -fno-omit-frame-pointer.
-ifeq ($(CONFIG_FUNCTION_TRACER),y)
-KBUILD_CFLAGS  += -mno-sched-epilog
-endif
+# Remove -fno-omit-frame-pointer flag. There are two reasons:
+# 1. On powerpc we always have frame pointers.
+# 2. Some gcc versions might generate wrong code with -fno-omit-frame-pointer
+#flag. So, if for some reason you're going to remove this line, then add
+#-mno-sched-epilog to workaround the gcc bug.
+KBUILD_CFLAGS := $(subst -fno-omit-frame-pointer,,$(KBUILD_CFLAGS))
 
 cpu-as-$(CONFIG_4xx)   += -Wa,-m405
 cpu-as-$(CONFIG_6xx)   += -Wa,-maltivec
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 8d1a419..a97f215 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -14,14 +14,14 @@ endif
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog
-CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_cputable.o = -pg
+CFLAGS_REMOVE_prom_init.o = -pg
+CFLAGS_REMOVE_btext.o = -pg
+CFLAGS_REMOVE_prom.o = -pg
 
 ifdef CONFIG_DYNAMIC_FTRACE
 # dynamic ftrace setup.
-CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_ftrace.o = -pg
 endif
 
 endif
diff --git a/arch/powerpc/platforms/powermac/Makefile 
b/arch/powerpc/platforms/powermac/Makefile
index 50f1693..0eb8781 100644
--- a/arch/powerpc/platforms/powermac/Makefile
+++ b/arch/powerpc/platforms/powermac/Makefile
@@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog
+CFLAGS_REMOVE_bootx_init.o = -pg
 endif
 
 obj-y  += pic.o setup.o time.o feature.o pci.o \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 29044f5..657126c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -402,7 +402,7 @@ config LOCKDEP
bool
depends on DEBUG_KERNEL  TRACE_IRQFLAGS_SUPPORT  STACKTRACE_SUPPORT 
 LOCKDEP_SUPPORT
select STACKTRACE
-   select FRAME_POINTER if !X86  !MIPS  !PPC
+   select FRAME_POINTER if !X86  !MIPS
select KALLSYMS
select KALLSYMS_ALL
 
@@ -583,7 +583,7 @@ config FRAME_POINTER
bool Compile the kernel with frame pointers
depends on DEBUG_KERNEL  \
(CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
-AVR32 || SUPERH || BLACKFIN || MN10300) || \
+AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \
ARCH_WANT_FRAME_POINTERS
default y if (DEBUG_INFO  UML) || ARCH_WANT_FRAME_POINTERS
help
@@ -771,13 +771,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER
depends on FAULT_INJECTION_DEBUG_FS  STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
-   select FRAME_POINTER if !PPC
+   select FRAME_POINTER
help
  Provide stacktrace filter for fault-injection capabilities
 
 config LATENCYTOP
bool Latency measuring infrastructure
-   select FRAME_POINTER if !MIPS  !PPC
+   select FRAME_POINTER if !MIPS
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
-- 
1.5.6.5

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER

[Anton Vorontsov]

Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they
should select FRAME_POINTER. Otherwise traces are meaningless.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 kernel/trace/Kconfig |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index e2a4ff6..48f7a37 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -86,6 +86,7 @@ config IRQSOFF_TRACER
select TRACE_IRQFLAGS
select TRACING
select TRACER_MAX_TRACE
+   select FRAME_POINTER
help
  This option measures the time spent in irqs-off critical
  sections, with microsecond accuracy.
@@ -108,6 +109,7 @@ config PREEMPT_TRACER
depends on DEBUG_KERNEL
select TRACING
select TRACER_MAX_TRACE
+   select FRAME_POINTER
help
  This option measures the time spent in preemption off critical
  sections, with microsecond accuracy.
@@ -136,6 +138,7 @@ config SCHED_TRACER
select TRACING
select CONTEXT_SWITCH_TRACER
select TRACER_MAX_TRACE
+   select FRAME_POINTER
help
  This tracer tracks the latency of the highest priority task
  to be scheduled in, starting from the point it has woken up.
-- 
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER

[Steven Rostedt]

On Wed, 2009-02-04 at 16:26 +0100, Frédéric Weisbecker wrote:
 2009/2/4 Anton Vorontsov avoront...@ru.mvista.com:
  Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they
  should select FRAME_POINTER. Otherwise traces are meaningless.
 
  Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
  ---
   kernel/trace/Kconfig |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
 
  diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
  index e2a4ff6..48f7a37 100644
  --- a/kernel/trace/Kconfig
  +++ b/kernel/trace/Kconfig
  @@ -86,6 +86,7 @@ config IRQSOFF_TRACER
 select TRACE_IRQFLAGS
 select TRACING
 select TRACER_MAX_TRACE
  +   select FRAME_POINTER
 help
   This option measures the time spent in irqs-off critical
   sections, with microsecond accuracy.
  @@ -108,6 +109,7 @@ config PREEMPT_TRACER
 depends on DEBUG_KERNEL
 select TRACING
 select TRACER_MAX_TRACE
  +   select FRAME_POINTER
 help
   This option measures the time spent in preemption off critical
   sections, with microsecond accuracy.
  @@ -136,6 +138,7 @@ config SCHED_TRACER
 select TRACING
 select CONTEXT_SWITCH_TRACER
 select TRACER_MAX_TRACE
  +   select FRAME_POINTER
 help
   This tracer tracks the latency of the highest priority task
   to be scheduled in, starting from the point it has woken up.
  --
 
 
 Looks right.
 
 BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ?
 I guess it would only work with the first caller builtin_return_address(0)


From ftrace.h:

#ifdef CONFIG_FRAME_POINTER
/* TODO: need to fix this for ARM */
# define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
# define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1))
# define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2))
# define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3))
# define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4))
# define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5))
# define CALLER_ADDR6 ((unsigned long)__builtin_return_address(6))
#else
# define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
# define CALLER_ADDR1 0UL
# define CALLER_ADDR2 0UL
# define CALLER_ADDR3 0UL
# define CALLER_ADDR4 0UL
# define CALLER_ADDR5 0UL
# define CALLER_ADDR6 0UL
#endif

Yep!

-- Steve


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER

[Frédéric Weisbecker]

2009/2/4 Anton Vorontsov avoront...@ru.mvista.com:
 Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they
 should select FRAME_POINTER. Otherwise traces are meaningless.

 Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
 ---
  kernel/trace/Kconfig |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
 index e2a4ff6..48f7a37 100644
 --- a/kernel/trace/Kconfig
 +++ b/kernel/trace/Kconfig
 @@ -86,6 +86,7 @@ config IRQSOFF_TRACER
select TRACE_IRQFLAGS
select TRACING
select TRACER_MAX_TRACE
 +   select FRAME_POINTER
help
  This option measures the time spent in irqs-off critical
  sections, with microsecond accuracy.
 @@ -108,6 +109,7 @@ config PREEMPT_TRACER
depends on DEBUG_KERNEL
select TRACING
select TRACER_MAX_TRACE
 +   select FRAME_POINTER
help
  This option measures the time spent in preemption off critical
  sections, with microsecond accuracy.
 @@ -136,6 +138,7 @@ config SCHED_TRACER
select TRACING
select CONTEXT_SWITCH_TRACER
select TRACER_MAX_TRACE
 +   select FRAME_POINTER
help
  This tracer tracks the latency of the highest priority task
  to be scheduled in, starting from the point it has woken up.
 --


Looks right.

BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ?
I guess it would only work with the first caller builtin_return_address(0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER

[Anton Vorontsov]

On Wed, Feb 04, 2009 at 04:26:15PM +0100, Frédéric Weisbecker wrote:
[...]
  @@ -136,6 +138,7 @@ config SCHED_TRACER
 select TRACING
 select CONTEXT_SWITCH_TRACER
 select TRACER_MAX_TRACE
  +   select FRAME_POINTER
 help
   This tracer tracks the latency of the highest priority task
   to be scheduled in, starting from the point it has woken up.
  --
 
 
 Looks right.
 
 BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ?
 I guess it would only work with the first caller builtin_return_address(0)

It depends on the architecture. On PowerPC we always have frame pointers,
thus __builtin_return_address(1..) will always work. On x86 it won't work
that way.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation

[Serge E. Hallyn]

Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
 
  +struct cr_hdr_cpu {
  +   struct pt_regs pt_regs;
  +   /* relevant fields from thread_struct */
  +   double fpr[32][TS_FPRWIDTH];
  +   unsigned int fpscr;
  +   int fpexc_mode;
  +   /* unsigned int align_ctl; this is never updated? */
  +   unsigned long dabr;
  +};
 
 Is there some version or other identification somewhere ? If not there
 should be. ie, we're going to add things here. For example, what about
 the vector registers ? Also, some CPUs will have more HW debug registers
 than just the DABR (we plan to add support for all the BookE architected
 IACs and DACs for example), etc...

The arch-independent checkpoint header does have kernel
maj:min:rev:patch info.  We expect to have to do more,
assuming that the .config can change the arch-dependent
cpu header (i.e. perhaps TS_FPRWIDTH could be changed).

-serge
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

next-20090204 build break : ftrace

[Sachin P. Sant]

Hi Stephen,

20090204 randconfig build on powerpc fails with :

 CC  arch/powerpc/kernel/ftrace.o
arch/powerpc/kernel/ftrace.c: In function __ftrace_make_nop:
arch/powerpc/kernel/ftrace.c:204: error: dereferencing pointer to incomplete 
type
arch/powerpc/kernel/ftrace.c: In function __ftrace_make_call:
arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete 
type
arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete 
type
arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete 
type
arch/powerpc/kernel/ftrace.c:407: error: dereferencing pointer to incomplete 
type
make[1]: *** [arch/powerpc/kernel/ftrace.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

config attached.

Thanks
-Sachin

--

-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.29-rc3
# Wed Feb  4 18:31:52 2009
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_POWER4_ONLY=y
CONFIG_POWER4=y
CONFIG_TUNE_CELL=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_MM_SLICES=y
# CONFIG_VIRT_CPU_ACCOUNTING is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=32
CONFIG_64BIT=y
CONFIG_WORD_SIZE=64
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_IRQ_PER_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
CONFIG_GENERIC_TBSYNC=y
CONFIG_AUDIT_ARCH=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_HIBERNATE_64=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
CONFIG_PPC_DCR_MMIO=y
CONFIG_PPC_DCR=y
CONFIG_PPC_OF_PLATFORM_PCI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUPS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_PCSPKR_PLATFORM is not set
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_PCI_QUIRKS=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLQB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_SYSCALL_WRAPPERS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_SLOW_WORK=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory
# CONFIG_FREEZER is not set

unsubscribe

[Bietry, Ray]

 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

unsubscribe

[ravi . rao]

Ravishankar Govindarao
RFL Electronics Inc.
E-mail : ravi@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
 
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or 
legally privileged information.  The Information is intended only for the 
use of the individual or entity named on this e-mail .  If you are not the 
intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of 
this transmitted Information is strictly prohibited.  Further, if you are 
not the intended recipient, please notify us by return e-mail and delete 
the Information promptly.
 
 
 ___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...

[Mike Timmons]

I received great help last week in getting a USB wi fi device working. 
Thanks again, but can someone read below and advise me on kernel 2.6.24? 
The best out-of-the box solution for me was 2.6.27.8, for which I needed 
a Denx eldx toolchain in place of the toolchain I was using to compile 
2.6.24. The significance of all this is that I did get  USB wi fi 
working, but...


I'm not in a position to upgrade from 2.6.24 at this time. I need to get 
the USB wi wi (Linksys WUSB54GC) working under 2.6.24.


After success with linking firmware with the 2.6.27.8 kernel, 2.6.24 I 
keep hitting this error when loading from user space (I don't appear to 
have the, link with kernel option with 2.6.24)...


sh-2.05b# ifconfig wlan0 up
[  764.744354] phy0 - rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt73.bin'.


After a considerable delay I get an error that indicates the file can't 
be found.


I have spent many, many hours following leads (and links) this group has 
directed me to. Thanks again. I'm either missing a very simple step or 
indeed support under 6.2.24 is not good. Please advise. I've done the 
following...


1)placed rt73.bin in various locations (/lib/firmware, 
lib/firmware/'uname -a', and the location specified by my 
/etc/hotplug/firmware.agent), according to tips on some threads I've read.


None of this appears to make a difference.

2) I'm a bit confused by the hotplug dependancy, although I do have 
hotplug enabled. hotplug makes me think I should be configuring some 
script to load the firmware upon device insertion, but, ifconfig wlan0 
up appears to want to load the firmware anyway so I'm guessing if I 
just get rt73.bin installed correctly it should work.


Comparing my working 2.6.27.8 to 2.6.24 in the areas of, firmware and 
the ralink rt2x00 drivers reveals MANY changes, no doubt for the better.


QUESTIONS:
1) Am I missing something VERY simple on this firmware loading topic 
that should make this work under 2.6.24, or am I bumping into the reason 
so much of this code has changed between 2.6.24 and 2.6.27.8?
-linking firmware with the lernel at compile time is a nice, obvious 
method offered by the later kernel. I'm confused by the userspace method 
and I think this is where my problem lay.


2) am I correctly, installing the firmware just by placing rt73.bin in 
the correct location in my filesystem, or is there some other magic 
required before, request_firmware() will work?


Just when I thought I understood some of the kernel I hit a new topic: 
firmware loading! Any help much appreciated...


-Mike
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER

[Frédéric Weisbecker]

2009/2/4 Steven Rostedt srost...@redhat.com:

 From ftrace.h:

 #ifdef CONFIG_FRAME_POINTER
 /* TODO: need to fix this for ARM */
 # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
 # define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1))
 # define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2))
 # define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3))
 # define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4))
 # define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5))
 # define CALLER_ADDR6 ((unsigned long)__builtin_return_address(6))
 #else
 # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
 # define CALLER_ADDR1 0UL
 # define CALLER_ADDR2 0UL
 # define CALLER_ADDR3 0UL
 # define CALLER_ADDR4 0UL
 # define CALLER_ADDR5 0UL
 # define CALLER_ADDR6 0UL
 #endif

 Yep!


Ok.

2009/2/4 Anton Vorontsov avoront...@ru.mvista.com:
 It depends on the architecture. On PowerPC we always have frame pointers,
 thus __builtin_return_address(1..) will always work. On x86 it won't work
 that way.

 Thanks,

 --
 Anton Vorontsov

Thanks for your answers!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC5200 PCI Issues

[Grant Likely]

On Wed, Feb 4, 2009 at 9:53 AM, Tobias Knutsson
tobias.knuts...@gmail.com wrote:
   clock-frequency = 0x1e84800;  //0; // From boot loader
   interrupts = 2 8 0 2 9 0 2 10 0;
   interrupt-parent = mpc5200_pic;
   bus-range = 0 0;
   ranges = 0x0200 0 0x5000 0x5000 0 0x1000
 0x0100 0 0x 0x6000 0 0x0100;
   };

 The cards' memory regions are mapped out fine to different addresses
 in the 0x5000-0x6000 range. However, the IO regions are all mapped
 to zero.

 Do you have any idea on what could be wrong or in which direction I
 should be looking?

Hmmm.  Your ranges property looks okay to me.  The MPC5200 setup code
may be doing the wrong thing.  Turn on debug at the top of
arch/powerpc/platforms/mpc52xx/mpc52xx_pci.c and post your kernel
output.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller

[Grant Likely]

From: Grant Likely grant.lik...@secretlab.ca

This patch adds IRQ controller support to the MPC5200 General
Purpose Timer (GPT) device driver.  With this patch the mpc5200-gpt
driver supports both GPIO and IRQ functions.

The GPT driver was contained within the mpc52xx_gpio.c file, but this
patch moves it out into a new file (mpc52xx_gpt.c) since it has more
than just GPIO functionality now and it was only grouped with the
mpc52xx-gpio drivers as a matter of convenience before.  Also, this
driver will most likely get extended again to also provide support
for the timer function.

Implementation note: Alternately, I could have tried to implement
the IRQ support as a separate driver and left the GPIO portion alone.
However, multiple functions of this device (ie. GPIO input+interrupt
controller, or timer+GPIO) can be active at the same time and the
registers are shared so it is safer to contain all functionality
within a single driver.

v4 changes:
- Fix compile error when GPIOLIB is not enabled.
v3 changes:
- Use set/clbits() for manipulating registers
- Fix incorrect comments
- Other minor tidying
v2 changes:
- Removed magic numbers
- Only set to GPIO mode if it has the gpio-controller property.  Otherwise
  leave the configuration alone.  Firmware may have already configured it.

Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---

Here is what I hope to be the last version of this patch.  This version fixes
a compile error when GPIO support is not compiled into the kernel.  I've
pushed this out to my -next tree.  I'll be asking Ben to pull it tomorrow.

g.

 arch/powerpc/platforms/52xx/Makefile   |2 
 arch/powerpc/platforms/52xx/mpc52xx_gpio.c |   85 -
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c  |  435 
 3 files changed, 436 insertions(+), 86 deletions(-)
 create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c


diff --git a/arch/powerpc/platforms/52xx/Makefile 
b/arch/powerpc/platforms/52xx/Makefile
index 9dfbde2..bfd4f52 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile for 52xx based boards
 #
-obj-y  += mpc52xx_pic.o mpc52xx_common.o
+obj-y  += mpc52xx_pic.o mpc52xx_common.o mpc52xx_gpt.o
 obj-$(CONFIG_PCI)  += mpc52xx_pci.o
 
 obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 07f89ae..2b8d8ef 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -354,88 +354,6 @@ static struct of_platform_driver 
mpc52xx_simple_gpiochip_driver = {
.remove = mpc52xx_gpiochip_remove,
 };
 
-/*
- * GPIO LIB API implementation for gpt GPIOs.
- *
- * Each gpt only has a single GPIO.
- */
-static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
-{
-   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
-   struct mpc52xx_gpt __iomem *regs = mm_gc-regs;
-
-   return (in_be32(regs-status)  (1  (31 - 23))) ? 1 : 0;
-}
-
-static void
-mpc52xx_gpt_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 mpc52xx_gpt __iomem *regs = mm_gc-regs;
-
-   if (val)
-   out_be32(regs-mode, 0x34);
-   else
-   out_be32(regs-mode, 0x24);
-
-   pr_debug(%s: gpio: %d val: %d\n, __func__, gpio, val);
-}
-
-static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
-{
-   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
-   struct mpc52xx_gpt __iomem *regs = mm_gc-regs;
-
-   out_be32(regs-mode, 0x04);
-
-   return 0;
-}
-
-static int
-mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
-{
-   mpc52xx_gpt_gpio_set(gc, gpio, val);
-   pr_debug(%s: gpio: %d val: %d\n, __func__, gpio, val);
-
-   return 0;
-}
-
-static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
-   const struct of_device_id *match)
-{
-   struct of_mm_gpio_chip *mmchip;
-   struct of_gpio_chip *chip;
-
-   mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
-   if (!mmchip)
-   return -ENOMEM;
-
-   chip = mmchip-of_gc;
-
-   chip-gpio_cells  = 2;
-   chip-gc.ngpio= 1;
-   chip-gc.direction_input  = mpc52xx_gpt_gpio_dir_in;
-   chip-gc.direction_output = mpc52xx_gpt_gpio_dir_out;
-   chip-gc.get  = mpc52xx_gpt_gpio_get;
-   chip-gc.set  = mpc52xx_gpt_gpio_set;
-
-   return of_mm_gpiochip_add(ofdev-node, mmchip);
-}
-
-static const struct of_device_id mpc52xx_gpt_gpiochip_match[] = {
-   {
-   .compatible = fsl,mpc5200-gpt-gpio,
-   },
-   {}
-};
-
-static struct of_platform_driver mpc52xx_gpt_gpiochip_driver = {
-   

Re: Maple PPC970 kexec crash-dump problems

[Benjamin Walsh]

Hi Milton,

I've tracked it down to the device tree passed to the second kernel being
screwed-up when patched by kexec-tools. Namely, it was creating
linux,usable-memory entries that were wrong, and the MMU initialization hung
when it failed allocating for the page tables. I hacked the tool, and got
passed that point in the init sequence, but the very first IO mapped access
fails, so the MMU doesn't seem to be set up correctly.

Anyway, up to my question: is the crash dump (kdump) kernel supposed to use
the memory reserved for it by the first kernel for its working memory ? e.g.
On that board, I have 0-2GB and 4-6GB for a total of 4GB of RAM. Let's say
I reserve 1...@32m, that's 0x200-0xa00. Is the second kernel
supposed to use

(0x200+kernel size) - 0xa00

for its memory pool and leave everything else:

0-0x200, 0xa00 - 8000, 0x1 - 0x18000

as memory that is from the first kernel, used to debug it ?

Basically, I am trying to figure out if I patched the tool correctly.

Thanks,
Ben

On Sat, Jan 24, 2009 at 2:52 AM, Milton Miller milt...@bga.com wrote:

 On Sat Jan 24 at 07:59:47 EST in 2009, Benjamin Walsh wrote:

 I am trying to use kexec with a crash dump kernel on a Maple board
 (Motorola
 ATCA6101 to be precise). This board is running a two-CPU PPC970FX. I am
 running a 2.6.27-10 kernel and have tried both older kexec-tools and the
 newest ones. I have tried SMP and non-SMP kernels.


 Once you start the second cpu it is likly executing instructions somewhere.

 Priory to 2.6.27 you had to compile a fixxed offset kerenl to run kdump.
  With 2.6.27 that option was removed and replaced with teh relocatable
 kerenl.  However, becasue of the way linux interacts with open firmware, the
 kernel will still move itself to 0 unless a specific flag is set.   The
 location of the flag was changed twice during the merge process, and the
 patches for kexec-tools were not made until early this year.

  Using kexec -l to fast boot works correctly. However, loading a crash dump
 kernel and triggering a crash via echo c  /proc/sysrq-trigger simply
 hangs
 the board. I have traced the sequence down to after the call to
 kexec_copy_flush(), when the CPU returns to real-address mode (bl
 real_mode). At this point I have no further debugging information.



  Two things could help me:

 - Getting the fix if this is a known issue and a fix exists. I have looked
 at recent patches and nothing lept to mind, mostly relocatable kernel
 support.


 That is a major change.

 That said, I don't know if anyone has tested kexec panic beyond pseries for
 64 bit powerpc.

 I know Paul originally prototyped the relocatable patch on a powermac, but
 I dont' know what if any smp testing he performed.   And you said you are
 actualy on maple not a powermac, so the startup issues are different.

  - Obtaining the address of the serial port @3f8 in real mode. The init
 sequence with udbg ON says that the physical address of the port is
 0xf40003f8; however, setting it up in poll mode and trying to stuff
 characters in the tx buffer doesn't produce anything.


 Ah yes.  In real mode you can only talk to cacheable memory without
 implementation specific assistance.  However, if you look in the kernel for
 the maple early udbg support, you will find the code you need to talk to
 that serial port in real mode.


 Has anyone recently tried to use the serial port in real mode ?

 Thanks for any help.

 Ben


 Hope this gets you started.  I wrote a lot of the kernel code, but I had
 the advantage of external jtag access to the processor to see where it when
 ended up when it went astray.

 milton


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

MPC5200 PCI Issues

[Tobias Knutsson]

I am currently trying to get an MPC5200-based board to run Linux
2.6.28. Most of the devices are working, however i have some issues
with the PCI-bus. More precisely, the issue is that all of
the cards' IO-regions are mapped to address 0x0.

In my device tree I have the following:

   p...@fd00 {
   #interrupt-cells = 1;
   #size-cells = 2;
   #address-cells = 3;
   device_type = pci;
   compatible = fsl,mpc5200b-pci,fsl,mpc5200-pci;
   reg = 0xfd00 0x100;
   interrupt-map-mask = 0xf800 0 0 7;
   interrupt-map = 0xb000 0 0 1 mpc5200_pic 0 0 3 // MPC5200
0xb000 0 0 2 mpc5200_pic 0 0 3
0xb000 0 0 3 mpc5200_pic 0 0 3
0xb000 0 0 4 mpc5200_pic 0 0 3

0xb800 0 0 1 mpc5200_pic 1 1 3 // c64x0
0xb800 0 0 2 mpc5200_pic 1 1 3
0xb800 0 0 3 mpc5200_pic 1 1 3
0xb800 0 0 4 mpc5200_pic 1 1 3

0xc000 0 0 1 mpc5200_pic 1 1 3 // c64x1
0xc000 0 0 2 mpc5200_pic 1 1 3
0xc000 0 0 3 mpc5200_pic 1 1 3
0xc000 0 0 4 mpc5200_pic 1 1 3

0xc800 0 0 1 mpc5200_pic 1 1 3 // c64x2
0xc800 0 0 2 mpc5200_pic 1 1 3
0xc800 0 0 3 mpc5200_pic 1 1 3
0xc800 0 0 4 mpc5200_pic 1 1 3

0xd000 0 0 1 mpc5200_pic 1 1 3 // c64x3
0xd000 0 0 2 mpc5200_pic 1 1 3
0xd000 0 0 3 mpc5200_pic 1 1 3
0xd000 0 0 4 mpc5200_pic 1 1 3

0xd800 0 0 1 mpc5200_pic 1 1 3 // c64x4
0xd800 0 0 2 mpc5200_pic 1 1 3
0xd800 0 0 3 mpc5200_pic 1 1 3
0xd800 0 0 4 mpc5200_pic 1 1 3;

   clock-frequency = 0x1e84800;  //0; // From boot loader
   interrupts = 2 8 0 2 9 0 2 10 0;
   interrupt-parent = mpc5200_pic;
   bus-range = 0 0;
   ranges = 0x0200 0 0x5000 0x5000 0 0x1000
 0x0100 0 0x 0x6000 0 0x0100;
   };

The cards' memory regions are mapped out fine to different addresses
in the 0x5000-0x6000 range. However, the IO regions are all mapped
to zero.

Do you have any idea on what could be wrong or in which direction I
should be looking?


-- 

Hälsningar/Regards
Tobias Knutsson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT

[Roland Dreier]

 huge_page_size(page_hstate(page))

   That would suit.  I assume the intention is for that to be usable by
   driver modules on any architecture?

  erm, you overestimate the amount of planning and forethought which goes
  into these things ;)

  The lack of any EXPORT_SYMBOL(size_to_hstate) is a broadish hint.

Heh.  Looking into the implementation, it seems that I could actually do

PAGE_SIZE  compound_order(page)

directly (since there's no reason to go from size to hstate and back to
size.  I don't know all the details of these VM internals, but that
seems to only work on the first (small) page of a giant page?  Which
causes problems for what we're trying to do here...

To summarize the goal, we are mapping user memory to a device that has
its own page tables, where the device's page tables can also use
multiple page sizes.  Using big pages on the device leads to similar
efficiencies as hugetlb pages do on the CPU, and in fact if a user has
used hugetlb pages for the memory they're giving to the device, that's a
very strong hint that the device should use big pages too.

But one valid situation we have to handle in the driver is if, say,
userspace has a hugetlb mapped at virtual address 0x20, and wants to
map 0x8 bytes at 0x28 to the device.  In that case, we're going
to do essentially

get_user_pages(..., 0x28, 0x8 / PAGE_SIZE, ...)

and get_user_pages() is going to give us a bunch of normal PAGE_SIZE
pages starting at offset 0x80 within the compound page that makes up
the huge page mapped at 0x20.

get_user_pages() also gives us the vma back, and we can see from
is_vm_hugetlb_page() (-- BTW can I just say that a function
is_xxx_page() that operates on vmas is horribly misnamed --) that these
pages all come from a hugetlb mapping, but figuring out the size of that
mapping is I guess a challenge.

 - R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...

[Alan Nishioka]

request_firmware uses the hotplug code so the kernel doesn't have any 
sourceless binaries compiled into it.  on init, the driver requests the 
firmware, user mode hotplug daemon loads the firmware from disk and 
gives the driver a pointer to it.


since this is a short term problem, i would suggest converting rt73.bin 
to a header file and compiling it into the kernel.  you have to make a 
few minor changes to where request_firmware is called, but in the end 
firmware is just an array of bytes with a pointer to it.  this is what i 
did when i was testing usb wifi a little while ago.


i am probably going to open source hell for suggesting this, but i'm a 
hardware engineer, so i am in hell already.


alan nishioka


Mike Timmons wrote:
I received great help last week in getting a USB wi fi device working. 
Thanks again, but can someone read below and advise me on kernel 
2.6.24? The best out-of-the box solution for me was 2.6.27.8, for 
which I needed a Denx eldx toolchain in place of the toolchain I was 
using to compile 2.6.24. The significance of all this is that I did 
get  USB wi fi working, but...


I'm not in a position to upgrade from 2.6.24 at this time. I need to 
get the USB wi wi (Linksys WUSB54GC) working under 2.6.24.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller

[Wolfram Sang]

Hello Grant,

On Wed, Feb 04, 2009 at 11:23:05AM -0700, Grant Likely wrote:
 From: Grant Likely grant.lik...@secretlab.ca
 
 This patch adds IRQ controller support to the MPC5200 General
 Purpose Timer (GPT) device driver.  With this patch the mpc5200-gpt
 driver supports both GPIO and IRQ functions.
 
 The GPT driver was contained within the mpc52xx_gpio.c file, but this
 patch moves it out into a new file (mpc52xx_gpt.c) since it has more
 than just GPIO functionality now and it was only grouped with the
 mpc52xx-gpio drivers as a matter of convenience before.  Also, this
 driver will most likely get extended again to also provide support
 for the timer function.
 
 Implementation note: Alternately, I could have tried to implement
 the IRQ support as a separate driver and left the GPIO portion alone.
 However, multiple functions of this device (ie. GPIO input+interrupt
 controller, or timer+GPIO) can be active at the same time and the
 registers are shared so it is safer to contain all functionality
 within a single driver.
 
 v4 changes:
 - Fix compile error when GPIOLIB is not enabled.
 v3 changes:
 - Use set/clbits() for manipulating registers
 - Fix incorrect comments
 - Other minor tidying
 v2 changes:
 - Removed magic numbers
 - Only set to GPIO mode if it has the gpio-controller property.  Otherwise
   leave the configuration alone.  Firmware may have already configured it.

I have been told to move such a changelog below the dashed lines,
because it is not so important for the git-history.

 
 Signed-off-by: Grant Likely grant.lik...@secretlab.ca
 ---
 
 Here is what I hope to be the last version of this patch.  This version fixes
 a compile error when GPIO support is not compiled into the kernel.  I've
 pushed this out to my -next tree.  I'll be asking Ben to pull it tomorrow.

Sorry, but it still has issues. This review in a hurry leaves me with a
bit uneasy feelings, still, if the remaining issues get resolved, you
may add my

Reviewed-by: Wolfram Sang w.s...@pengutronix.de

 
 g.
 
  arch/powerpc/platforms/52xx/Makefile   |2 
  arch/powerpc/platforms/52xx/mpc52xx_gpio.c |   85 -
  arch/powerpc/platforms/52xx/mpc52xx_gpt.c  |  435 
 
  3 files changed, 436 insertions(+), 86 deletions(-)
  create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c
 
 
 diff --git a/arch/powerpc/platforms/52xx/Makefile 
 b/arch/powerpc/platforms/52xx/Makefile
 index 9dfbde2..bfd4f52 100644
 --- a/arch/powerpc/platforms/52xx/Makefile
 +++ b/arch/powerpc/platforms/52xx/Makefile
 @@ -1,7 +1,7 @@
  #
  # Makefile for 52xx based boards
  #
 -obj-y+= mpc52xx_pic.o mpc52xx_common.o
 +obj-y+= mpc52xx_pic.o mpc52xx_common.o 
 mpc52xx_gpt.o
  obj-$(CONFIG_PCI)+= mpc52xx_pci.o
  
  obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
 diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c 
 b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
 index 07f89ae..2b8d8ef 100644
 --- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
 +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
 @@ -354,88 +354,6 @@ static struct of_platform_driver 
 mpc52xx_simple_gpiochip_driver = {
   .remove = mpc52xx_gpiochip_remove,
  };
  
 -/*
 - * GPIO LIB API implementation for gpt GPIOs.
 - *
 - * Each gpt only has a single GPIO.
 - */
 -static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
 -{
 - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
 - struct mpc52xx_gpt __iomem *regs = mm_gc-regs;
 -
 - return (in_be32(regs-status)  (1  (31 - 23))) ? 1 : 0;
 -}
 -
 -static void
 -mpc52xx_gpt_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 mpc52xx_gpt __iomem *regs = mm_gc-regs;
 -
 - if (val)
 - out_be32(regs-mode, 0x34);
 - else
 - out_be32(regs-mode, 0x24);
 -
 - pr_debug(%s: gpio: %d val: %d\n, __func__, gpio, val);
 -}
 -
 -static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
 -{
 - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
 - struct mpc52xx_gpt __iomem *regs = mm_gc-regs;
 -
 - out_be32(regs-mode, 0x04);
 -
 - return 0;
 -}
 -
 -static int
 -mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
 -{
 - mpc52xx_gpt_gpio_set(gc, gpio, val);
 - pr_debug(%s: gpio: %d val: %d\n, __func__, gpio, val);
 -
 - return 0;
 -}
 -
 -static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
 - const struct of_device_id *match)
 -{
 - struct of_mm_gpio_chip *mmchip;
 - struct of_gpio_chip *chip;
 -
 - mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
 - if (!mmchip)
 - return -ENOMEM;
 -
 - chip = mmchip-of_gc;
 -
 - chip-gpio_cells  = 2;
 - chip-gc.ngpio= 1;
 - chip-gc.direction_input  = 

Re: kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...

[Matt Gessner]

On Wed, Feb 4, 2009 at 2:14 PM, Alan Nishioka a...@nishioka.com wrote:

 request_firmware uses the hotplug code so the kernel doesn't have any
 sourceless binaries compiled into it.  on init, the driver requests the
 firmware, user mode hotplug daemon loads the firmware from disk and gives
 the driver a pointer to it.

 since this is a short term problem, i would suggest converting rt73.bin to
 a header file and compiling it into the kernel.  you have to make a few
 minor changes to where request_firmware is called, but in the end firmware
 is just an array of bytes with a pointer to it.  this is what i did when i
 was testing usb wifi a little while ago.

 i am probably going to open source hell for suggesting this, but i'm a
 hardware engineer, so i am in hell already.

 alan nishioka


Yes, you will certainly burn for this.  :-)

Mike Timmons:

I'll show you how MINE works (and if someone out there can point out errors,
fire away -- I'm not making the claim that this is completely correct).  I
hope that this will be new and helpful information for you.  If it's not, my
apologies; feel free to dump this in the bit bucket.

In my /sbin/hotplug I have a bunch of stuff for doing field updates, but at
the very bottom, I have this:

if [ $1 == firmware ]  [ $ACTION == add ]; then
  echo 1  /sys/$DEVPATH/loading
  cat /lib/firmware/$FIRMWARE  /sys/$DEVPATH/data
  echo 0  /sys/$DEVPATH/loading
  echo RT73 firmware loaded.  /dev/console
fi

That's how the firmware is loaded.

caveat: I am using 2.6.25 in my system.  I have no idea what's changed from
.24 to .25 that might be getting in your way.  You could consider moving
just the section in .25 that deals with the chipsets in question (ralink, I
think??).

I put all this together in about an hour after doing a little reading.  It
all works very well.

Now if I could just get that pesky AP mode working...

Also in my hotplug script is

if [ $1 == net ]  [ $ACTION == add ]  [ $INTERFACE == wlan0
]; then
  iwconfig wlan0 mode managed
  iwconfig wlan0 channel auto
  iwconfig wlan0 key DADADADADADADADADADADADADA
  iwconfig wlan0 essid mlxwap
fi

You will want to get the sources for the wifi utilities compiled for your
target, too.  Not hard to do.  I don't think I had to make any changes to
it.

Those who wish, feel free to post suggestions, etc.  I'm doing all of my
work on an ARM target, so I don't know if there are any gotchas in the rt
drivers for the rt73 usb stuff.

Also, you could check out rt2x00.serialmonkey.com if you haven't found it.
They are live (well, mostly dead) on #rt2x00 on freenode.

Good luck; if you have questions, feel free to email me directly.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller

[Grant Likely]

Hey Wolfram, thanks for the review.

On Wed, Feb 4, 2009 at 12:55 PM, Wolfram Sang w.s...@pengutronix.de wrote:

 I have been told to move such a changelog below the dashed lines,
 because it is not so important for the git-history.

This is only in my email for review purposes.  It won't be in the git commit.

 + status = in_be32(gpt-regs-status) | MPC52xx_GPT_STATUS_IRQMASK;

 Like I mentioned in my first review, the following if-clause is always
 true. You probably mean  MPC52xx_GPT_STATUS_IRQMASK?

You're right.  I missed this from your first review.  Fixed.

 +/* -
 + * GPIOLIB hooks
 + */
 +#if defined(CONFIG_GPIOLIB)
 +static inline struct mpc52xx_gpt_priv *gc_to_mpc52xx_gpt(struct gpio_chip 
 *gc)
 +{
 + return container_of(to_of_gpio_chip(gc), struct 
 mpc52xx_gpt_priv,of_gc);

 Space after ','. As it is now, this is a checkpatch-error. Lines over 80
 chars are a warning.

This is on purpose as I described earlier.  Checkpatch is not God, and
the cure is worse than the disease.  (Granted, the disease is
equivalent to a running nose, and the cure to cheap kleenex, but hey,
it's still my decision).

 +#else /* defined(CONFIG_SYSFS) */
 +static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return 
 0; }
 +#endif /* defined(CONFIG_SYSFS) */

 Hmmm, I still have problems with this sysfs-entry. If you say that this
 is good for debugging, then please make it #DEBUG at least. Imagine
 every driver doing such things, this adds bloat. I'd still rather
 suggest using

 ~ memedit /dev/mem
 - map MBAR 0x4000
 - md 0x600

 which does the same and even allows for more (writing for example).

I understand your argument, but I'm still going to leave it in and
leave it enabled for now.  I will consider removing it after a release
or too.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Please pull 'next' branch of linux-2.6-mpc52xx.git

[Grant Likely]

And I really mean -next this time.  :-)

The following changes since commit b1792e367053968f2ddb48bc911d314143ce6242:
  Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6

are available in the git repository at:

  git://git.secretlab.ca/git/linux-2.6-mpc52xx.git next

Grant Likely (7):
  powerpc/5200: Stop using device_type and port-number properties
  powerpc/5200: Trim cruft from device trees
  powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver
  powerpc/5200: Remove pr_debug() from hot paths in irq driver
  powerpc/5200: Refactor mpc5200 interrupt controller driver
  powerpc/5200: Rework GPT driver to also be an IRQ controller
  powerpc/5200: Add support for the Media5200 board from Freescale

Grzegorz Bernacki (1):
  powerpc/5200: Add support for the digsy MTC board.

 arch/powerpc/boot/Makefile   |4 +-
 arch/powerpc/boot/dts/cm5200.dts |   49 +---
 arch/powerpc/boot/dts/digsy_mtc.dts  |  254 +++
 arch/powerpc/boot/dts/lite5200.dts   |   52 +---
 arch/powerpc/boot/dts/lite5200b.dts  |   63 +---
 arch/powerpc/boot/dts/media5200.dts  |  318 +++
 arch/powerpc/boot/dts/motionpro.dts  |   42 +--
 arch/powerpc/boot/dts/pcm030.dts |  182 ---
 arch/powerpc/boot/dts/tqm5200.dts|   32 +--
 arch/powerpc/platforms/52xx/Kconfig  |   12 +-
 arch/powerpc/platforms/52xx/Makefile |3 +-
 arch/powerpc/platforms/52xx/media5200.c  |  273 
 arch/powerpc/platforms/52xx/mpc5200_simple.c |1 +
 arch/powerpc/platforms/52xx/mpc52xx_gpio.c   |   85 -
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c|  435 ++
 arch/powerpc/platforms/52xx/mpc52xx_pic.c|  170 ---
 drivers/net/fec_mpc52xx.c|6 +-
 drivers/serial/mpc52xx_uart.c|   40 +--
 18 files changed, 1476 insertions(+), 545 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/digsy_mtc.dts
 create mode 100644 arch/powerpc/boot/dts/media5200.dts
 create mode 100644 arch/powerpc/platforms/52xx/media5200.c
 create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
 Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
  
   +struct cr_hdr_cpu {
   + struct pt_regs pt_regs;
   + /* relevant fields from thread_struct */
   + double fpr[32][TS_FPRWIDTH];
   + unsigned int fpscr;
   + int fpexc_mode;
   + /* unsigned int align_ctl; this is never updated? */
   + unsigned long dabr;
   +};
  
  Is there some version or other identification somewhere ? If not there
  should be. ie, we're going to add things here. For example, what about
  the vector registers ? Also, some CPUs will have more HW debug registers
  than just the DABR (we plan to add support for all the BookE architected
  IACs and DACs for example), etc...
 
 The arch-independent checkpoint header does have kernel
 maj:min:rev:patch info.  We expect to have to do more,
 assuming that the .config can change the arch-dependent
 cpu header (i.e. perhaps TS_FPRWIDTH could be changed).

It could to a certain extent... things like VSX, VSR, or freescale SPE,
or even the Cell SPU state etc

I wonder if we want a tagged structure so we can easily add things...

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 1/4] Add platform support for AmigaOne

[Gabriel Paubert]

On Wed, Feb 04, 2009 at 02:50:07PM +1100, Benjamin Herrenschmidt wrote:
 
  + hose-first_busno = bus_range ? bus_range[0] : 0;
  + hose-last_busno = bus_range ? bus_range[1] : 0xff;
  +
  + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0);
 
 Minor in the context of amigaone but still... the above should come from
 the device-tree... I suppose those are really just IO space addresses
 cf8 and cfc, in which case, an option is to call that first:

Hmm, the first is feC...,the other one feE..., 2Mbytes apart.

I don't know the hardware but I've never seen something like that.
Of course a typo is always a possibility...

Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT

[wli]

On Wed, Feb 04, 2009 at 11:11:22AM -0800, Roland Dreier wrote:
 Heh.  Looking into the implementation, it seems that I could actually do
   PAGE_SIZE  compound_order(page)
 directly (since there's no reason to go from size to hstate and back to
 size.  I don't know all the details of these VM internals, but that
 seems to only work on the first (small) page of a giant page?  Which
 causes problems for what we're trying to do here...

You should be able to find the head of a compound page using the
compound_head() inline, so try

PAGE_SIZE  compound_order(compound_head(page))


-- wli
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2 1/4] Add platform support for AmigaOne

[John W. Linville]

On Wed, Feb 04, 2009 at 10:35:31PM +0100, Gerhard Pircher wrote:
 
  Original-Nachricht 
  Datum: Wed, 4 Feb 2009 21:59:41 +0100
  Von: Gabriel Paubert paub...@iram.es
  An: Benjamin Herrenschmidt b...@kernel.crashing.org
  CC: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev list 
  linuxppc-dev@ozlabs.org
  Betreff: Re: [PATCH v2 1/4] Add platform support for AmigaOne
 
  On Wed, Feb 04, 2009 at 02:50:07PM +1100, Benjamin Herrenschmidt wrote:
   
+ hose-first_busno = bus_range ? bus_range[0] : 0;
+ hose-last_busno = bus_range ? bus_range[1] : 0xff;
+
+ setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0);
   
   Minor in the context of amigaone but still... the above should come
   from the device-tree... I suppose those are really just IO space
   addresses cf8 and cfc, in which case, an option is to call that first:
  
  Hmm, the first is feC...,the other one feE..., 2Mbytes apart.
  
  I don't know the hardware but I've never seen something like that.
  Of course a typo is always a possibility...
 The Pegasos 1 uses the same northbridge and chrp_find_bridges() calls
 setup_indirect_pci() with the same addresses.

As a proud owner, I concur that those numbers are correct...

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Dynamic-ftrace not working in PlayStation3

[Steven Rostedt]

On Sat, 31 Jan 2009, Arnd Bergmann wrote:

 On Saturday 31 January 2009, Geoff Levand wrote:
   
   So I take it that the above showed that the code worked for some?
  
  In my trials it blows up on the first load_module() call, and for my
  config that was usbcore:
 
 I looked into it some more with Remis yesterday, and we got ftrace
 working by building usbcore and alsa into the kernel. Incidentally,
 usbcore is the largest module in this installation (~3MB), which
 indicates that it is in some way either related to the size of the
 module.
 
  This ptr of 5f666f725f726573 seems bogus.  I think this code is not
  working correctly:
 
 This is an ascii string _for_res, probably part of
 usb_lock_device_for_reset. We saw the same behaviour, but
 a different string.

OK, I've been able to reproduce it. It looks like the assumptions of the 
trampoline that I've made is not correct if the size of the module is over 
some limit.  I had to make usb-core into a module, and I see the same 
bug.

I'll take a deeper look into it.

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] arch/powerpc: Eliminate double sizeof

[Julia Lawall]

From: Julia Lawall ju...@diku.dk

Taking sizeof the result of sizeof is quite strange and does not seem to be
what is wanted here.

This was fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)

// smpl
@@
expression E;
@@

- sizeof (
  sizeof (E)
- )

@@
type T;
@@

- sizeof (
  sizeof (T)
- )
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk
---
 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c 
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -186,7 +186,7 @@ out_unmap_regs:
iounmap(priv-regs);
 out_free_bootmem:
free_bootmem((unsigned long)priv,
-sizeof(sizeof(struct pq2ads_pci_pic)));
+sizeof(struct pq2ads_pci_pic));
of_node_put(np);
 out_unmap_irq:
irq_dispose_mapping(irq);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] arch/powerpc: Eliminate double sizeof

[Scott Wood]

Julia Lawall wrote:

Signed-off-by: Julia Lawall ju...@diku.dk
---
 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c 
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -186,7 +186,7 @@ out_unmap_regs:
iounmap(priv-regs);
 out_free_bootmem:
free_bootmem((unsigned long)priv,
-sizeof(sizeof(struct pq2ads_pci_pic)));
+sizeof(struct pq2ads_pci_pic));
of_node_put(np);
 out_unmap_irq:
irq_dispose_mapping(irq);


ACK

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Dynamic-ftrace not working in PlayStation3

[Benjamin Herrenschmidt]

 OK, I've been able to reproduce it. It looks like the assumptions of the 
 trampoline that I've made is not correct if the size of the module is over 
 some limit.  I had to make usb-core into a module, and I see the same 
 bug.
 
 I'll take a deeper look into it.

Thanks ! I've been a bit swamped lately and didn't get a chance to dig
into that one .. yet. Let me know if you are stuck tho.

Cheers
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation

[Oren Laadan]

Benjamin Herrenschmidt wrote:
 On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
 Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
 +struct cr_hdr_cpu {
 +  struct pt_regs pt_regs;
 +  /* relevant fields from thread_struct */
 +  double fpr[32][TS_FPRWIDTH];
 +  unsigned int fpscr;
 +  int fpexc_mode;
 +  /* unsigned int align_ctl; this is never updated? */
 +  unsigned long dabr;
 +};
 Is there some version or other identification somewhere ? If not there
 should be. ie, we're going to add things here. For example, what about
 the vector registers ? Also, some CPUs will have more HW debug registers
 than just the DABR (we plan to add support for all the BookE architected
 IACs and DACs for example), etc...
 The arch-independent checkpoint header does have kernel
 maj:min:rev:patch info.  We expect to have to do more,
 assuming that the .config can change the arch-dependent
 cpu header (i.e. perhaps TS_FPRWIDTH could be changed).
 
 It could to a certain extent... things like VSX, VSR, or freescale SPE,
 or even the Cell SPU state etc
 
 I wonder if we want a tagged structure so we can easily add things...

From the little bit I read hear, I suspect that the sub-arch classification
is best done in an arch-dependent header. I'd follow the following rule
of thumb:

* Anything that is decided at compiled time should probably go to the arch-
dependent header.

* Anything that can change at boot time (e.g., for x86 that would include
the capabilities of the FPU), or even run time (is there any ?) should
be described to the letter (in fine print) in 'struct cr_hdr_cpu' and
friends.

Oren.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/1 v3] AMCC PPC 460SX redwood SoC platform initial framework

[Madhulika Madishetty]

From: Madhulika Madishetty mmadishe...@amcc.com

This patch contains initial framework for the AMCC Redwood board.

Signed-off-by: Madhulika Madishetty mmadishe...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
Signed-off-by: Feng Kan f...@amcc.com
Signed-off-by: Vidhyananth Venkatasamy vvenkatas...@amcc.com
Signed-off-by: Preetesh Parekh ppar...@amcc.com
Acked-by: Loc Ho l...@amcc.com
Acked-by: Feng Kan f...@amcc.com
---
 arch/powerpc/boot/dts/redwood.dts  |  244 ++
 arch/powerpc/configs/44x/redwood_defconfig | 1176 
 arch/powerpc/kernel/cpu_setup_44x.S|1 +
 arch/powerpc/kernel/cputable.c |   13 +
 arch/powerpc/platforms/44x/Kconfig |   19 +
 arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
 6 files changed, 1454 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/redwood.dts
 create mode 100644 arch/powerpc/configs/44x/redwood_defconfig

diff --git a/arch/powerpc/boot/dts/redwood.dts 
b/arch/powerpc/boot/dts/redwood.dts
new file mode 100644
index 000..ad402c4
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -0,0 +1,244 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC tma...@amcc.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = 2;
+   #size-cells = 1;
+   model = amcc,redwood;
+   compatible = amcc,redwood;
+   dcr-parent = {/cpus/c...@0};
+
+   aliases {
+   ethernet0 = EMAC0;
+   serial0 = UART0;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   c...@0 {
+   device_type = cpu;
+   model = PowerPC,460SX;
+   reg = 0x;
+   clock-frequency = 0; /* Filled in by U-Boot */
+   timebase-frequency = 0; /* Filled in by U-Boot */
+   i-cache-line-size = 32;
+   d-cache-line-size = 32;
+   i-cache-size = 32768;
+   d-cache-size = 32768;
+   dcr-controller;
+   dcr-access-method = native;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x 0x 0x; /* Filled in by 
U-Boot */
+   };
+
+   UIC0: interrupt-controller0 {
+   compatible = ibm,uic-460sx,ibm,uic;
+   interrupt-controller;
+   cell-index = 0;
+   dcr-reg = 0x0c0 0x009;
+   #address-cells = 0;
+   #size-cells = 0;
+   #interrupt-cells = 2;
+   };
+
+   UIC1: interrupt-controller1 {
+   compatible = ibm,uic-460sx,ibm,uic;
+   interrupt-controller;
+   cell-index = 1;
+   dcr-reg = 0x0d0 0x009;
+   #address-cells = 0;
+   #size-cells = 0;
+   #interrupt-cells = 2;
+   interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
+   interrupt-parent = UIC0;
+   };
+
+   UIC2: interrupt-controller2 {
+   compatible = ibm,uic-460sx,ibm,uic;
+   interrupt-controller;
+   cell-index = 2;
+   dcr-reg = 0x0e0 0x009;
+   #address-cells = 0;
+   #size-cells = 0;
+   #interrupt-cells = 2;
+   interrupts = 0xa 0x4 0xb 0x4; /* cascade */
+   interrupt-parent = UIC0;
+   };
+
+   UIC3: interrupt-controller3 {
+   compatible = ibm,uic-460sx,ibm,uic;
+   interrupt-controller;
+   cell-index = 3;
+   dcr-reg = 0x0f0 0x009;
+   #address-cells = 0;
+   #size-cells = 0;
+   #interrupt-cells = 2;
+   interrupts = 0x10 0x4 0x11 0x4; /* cascade */
+   interrupt-parent = UIC0;
+   };
+
+   SDR0: sdr {
+   compatible = ibm,sdr-460sx;
+   dcr-reg = 0x00e 0x002;
+   };
+
+   CPR0: cpr {
+   compatible = ibm,cpr-460sx;
+   dcr-reg = 0x00c 0x002;
+   };
+
+   plb {
+   compatible = ibm,plb-460sx, ibm,plb4;
+   #address-cells = 2;
+   #size-cells = 1;
+   ranges;
+   clock-frequency = 0; /* Filled in by U-Boot */
+
+   SDRAM0: sdram {
+   compatible = ibm,sdram-460sx, ibm,sdram-405gp;
+   dcr-reg = 0x010 0x002;
+   };
+
+   MAL0: mcmal {
+   compatible = ibm,mcmal-460sx, ibm,mcmal2;
+   dcr-reg = 0x180 0x62;
+   num-tx-chans = 4;
+   

Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT

[Benjamin Herrenschmidt]

 get_user_pages() also gives us the vma back, and we can see from
 is_vm_hugetlb_page() (-- BTW can I just say that a function
 is_xxx_page() that operates on vmas is horribly misnamed --) that these
 pages all come from a hugetlb mapping, but figuring out the size of that
 mapping is I guess a challenge.

Note that g_u_p() has all sort of shortcommings... we were discussing
some of that recently due to bugs reported from the field.

The problem mostly is that you cannot guarantee that the physical page
will remain mapped to that virtual address in the process. For example,
if your code is part of some library used by an application, and that
application somewhere does a fork/exec (for example, a system() call to
run a shell helper), copy-on-write will hit, and you may end up with
the child process getting the original physical page and the original
process getting the copy...

So your HW will still DMA to a valid page (ie, it's count will have
been incremented) but it's not going to be the one the application
uses any more.

There are similar issues that can be cause, afaik, by madvise, etc...

We've been discussing that at KS with various people, Linus says g_u_p()
sucks, don't do that :-) Most of the time, the other approach should be
used, ie, the driver allocates memory, and userspace mmap's it, in which
case you get access to the VMA to set flags such as don't copy on fork.

An option possibly would be to make fork() pre-COW pages with an
elevated count to ensure that at least the original process is the one
to keep the original physical page... but that has other potential side
effects or performance issues.

A can of worms..

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote:
 * Anything that is decided at compiled time should probably go to the arch-
 dependent header.
 
 * Anything that can change at boot time (e.g., for x86 that would include
 the capabilities of the FPU), or even run time (is there any ?) should
 be described to the letter (in fine print) in 'struct cr_hdr_cpu' and
 friends.

I think we should avoid compile time completely.

We mostly try to have kernels running on everything anyway, and there's
no reason not to be able to move a snapshot to a different CPU if it's
not using a feature of the CPU that is different.

Nathan, what about you start the structure with a 64 bit bitmask that
indicates what records are present followed by concatenated records ?

IE. The main state (pt_regs) wouldn't change, but then, you could have
a list of things:

 - FPRs
 - old style VSX
 - VSRs
 - Freescale SPE state
 - DABR
 - BookE IAC/DACs
 - tbd...

Then, when resuming a snapshot, we can use some bit masks trickery
indicating the validity on a given target. IE. If CPU has no VSX and
original program uses VSX then you can't resume. But if CPU has VSR you
can.. etc... We can keep it trivial at fist, especting the same
features, and try to be smart later.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote:
 Remove -fno-omit-frame-pointer flag from CFLAGS.
 Remove -fno-omit-frame-pointer workarounds.

But what about -pg -requires -fno-omit-frame-pointer ?

Ben.

 Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
 ---
  arch/powerpc/Makefile|   10 ++
  arch/powerpc/kernel/Makefile |   10 +-
  arch/powerpc/platforms/powermac/Makefile |2 +-
  lib/Kconfig.debug|8 
  4 files changed, 16 insertions(+), 14 deletions(-)
 
 diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
 index 72d17f5..627aa7f 100644
 --- a/arch/powerpc/Makefile
 +++ b/arch/powerpc/Makefile
 @@ -120,10 +120,12 @@ ifeq ($(CONFIG_6xx),y)
  KBUILD_CFLAGS+= -mcpu=powerpc
  endif
  
 -# Work around a gcc code-gen bug with -fno-omit-frame-pointer.
 -ifeq ($(CONFIG_FUNCTION_TRACER),y)
 -KBUILD_CFLAGS+= -mno-sched-epilog
 -endif
 +# Remove -fno-omit-frame-pointer flag. There are two reasons:
 +# 1. On powerpc we always have frame pointers.
 +# 2. Some gcc versions might generate wrong code with -fno-omit-frame-pointer
 +#flag. So, if for some reason you're going to remove this line, then add
 +#-mno-sched-epilog to workaround the gcc bug.
 +KBUILD_CFLAGS := $(subst -fno-omit-frame-pointer,,$(KBUILD_CFLAGS))
  
  cpu-as-$(CONFIG_4xx) += -Wa,-m405
  cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
 diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
 index 8d1a419..a97f215 100644
 --- a/arch/powerpc/kernel/Makefile
 +++ b/arch/powerpc/kernel/Makefile
 @@ -14,14 +14,14 @@ endif
  
  ifdef CONFIG_FUNCTION_TRACER
  # Do not trace early boot code
 -CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog
 -CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog
 -CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog
 -CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog
 +CFLAGS_REMOVE_cputable.o = -pg
 +CFLAGS_REMOVE_prom_init.o = -pg
 +CFLAGS_REMOVE_btext.o = -pg
 +CFLAGS_REMOVE_prom.o = -pg
  
  ifdef CONFIG_DYNAMIC_FTRACE
  # dynamic ftrace setup.
 -CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
 +CFLAGS_REMOVE_ftrace.o = -pg
  endif
  
  endif
 diff --git a/arch/powerpc/platforms/powermac/Makefile 
 b/arch/powerpc/platforms/powermac/Makefile
 index 50f1693..0eb8781 100644
 --- a/arch/powerpc/platforms/powermac/Makefile
 +++ b/arch/powerpc/platforms/powermac/Makefile
 @@ -2,7 +2,7 @@ CFLAGS_bootx_init.o   += -fPIC
  
  ifdef CONFIG_FUNCTION_TRACER
  # Do not trace early boot code
 -CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog
 +CFLAGS_REMOVE_bootx_init.o = -pg
  endif
  
  obj-y+= pic.o setup.o time.o feature.o pci.o 
 \
 diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
 index 29044f5..657126c 100644
 --- a/lib/Kconfig.debug
 +++ b/lib/Kconfig.debug
 @@ -402,7 +402,7 @@ config LOCKDEP
   bool
   depends on DEBUG_KERNEL  TRACE_IRQFLAGS_SUPPORT  STACKTRACE_SUPPORT 
  LOCKDEP_SUPPORT
   select STACKTRACE
 - select FRAME_POINTER if !X86  !MIPS  !PPC
 + select FRAME_POINTER if !X86  !MIPS
   select KALLSYMS
   select KALLSYMS_ALL
  
 @@ -583,7 +583,7 @@ config FRAME_POINTER
   bool Compile the kernel with frame pointers
   depends on DEBUG_KERNEL  \
   (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
 -  AVR32 || SUPERH || BLACKFIN || MN10300) || \
 +  AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \
   ARCH_WANT_FRAME_POINTERS
   default y if (DEBUG_INFO  UML) || ARCH_WANT_FRAME_POINTERS
   help
 @@ -771,13 +771,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER
   depends on FAULT_INJECTION_DEBUG_FS  STACKTRACE_SUPPORT
   depends on !X86_64
   select STACKTRACE
 - select FRAME_POINTER if !PPC
 + select FRAME_POINTER
   help
 Provide stacktrace filter for fault-injection capabilities
  
  config LATENCYTOP
   bool Latency measuring infrastructure
 - select FRAME_POINTER if !MIPS  !PPC
 + select FRAME_POINTER if !MIPS
   select KALLSYMS
   select KALLSYMS_ALL
   select STACKTRACE

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Steven Rostedt]

On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote:
 On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote:
  Remove -fno-omit-frame-pointer flag from CFLAGS.
  Remove -fno-omit-frame-pointer workarounds.
 
 But what about -pg -requires -fno-omit-frame-pointer ?

I don't think it requires -fno-omit-frame-pointer. It is just
incompatible with -fomit-frame-pointer.

-- Steve


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Anton Vorontsov]

On Wed, Feb 04, 2009 at 07:35:54PM -0500, Steven Rostedt wrote:
 
 On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote:
  On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote:
   Remove -fno-omit-frame-pointer flag from CFLAGS.
   Remove -fno-omit-frame-pointer workarounds.
  
  But what about -pg -requires -fno-omit-frame-pointer ?
 
 I don't think it requires -fno-omit-frame-pointer. It is just
 incompatible with -fomit-frame-pointer.

Yep, -fno-omit-frame-poiner isn't needed for -pg.

I explained this in http://lkml.org/lkml/2009/2/3/342 :

| Ah...
|
| $ gcc -pg -fomit-frame-pointer -S c.c
| gcc: -pg and -fomit-frame-pointer are incompatible
|
| It's hard-coded in gcc, in the code that don't know about
| architecture details.
|
| But on PowerPC -O1 implies -fomit-frame-pointer, that is
|
| gcc -pg -O1 -fno-omit-frame-pointer
| and
| gcc -pg -O1
|
| produce different outputs. Thus -pg -O should be the same
| as -pg -O -fomit-framepointer.

That is,

`gcc -O -pg -fno-omit-frame-pointer -S` output:

main:
mflr 0
stw 0,4(1)
bl _mcount
stwu 1,-16(1)
mflr 0
stw 0,20(1)
stw 31,12(1)
mr 31,1
li 3,0
lwz 11,0(1)
lwz 0,4(11)
mtlr 0
lwz 31,-4(11)
mr 1,11
blr

^^ -pg works (_mcount call), but r31 wasted.

Now `gcc -O -pg -S` output:

main:
mflr 0
stw 0,4(1)
bl _mcount
stwu 1,-16(1)
mflr 0
stw 0,20(1)
li 3,0
lwz 0,20(1)
mtlr 0
addi 1,1,16
blr

^^ _mcount is still there, and r31 isn't used.

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 19:35 -0500, Steven Rostedt wrote:
 On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote:
  On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote:
   Remove -fno-omit-frame-pointer flag from CFLAGS.
   Remove -fno-omit-frame-pointer workarounds.
  
  But what about -pg -requires -fno-omit-frame-pointer ?
 
 I don't think it requires -fno-omit-frame-pointer. It is just
 incompatible with -fomit-frame-pointer.

From a quick test, you seem to be right.

Now the question of course is whether -pg will internally trigger
the bug for which we need the workaround tho...

Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER

[Anton Vorontsov]

On Thu, Feb 05, 2009 at 12:15:31PM +1100, Benjamin Herrenschmidt wrote:
 On Wed, 2009-02-04 at 19:35 -0500, Steven Rostedt wrote:
  On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote:
   On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote:
Remove -fno-omit-frame-pointer flag from CFLAGS.
Remove -fno-omit-frame-pointer workarounds.
   
   But what about -pg -requires -fno-omit-frame-pointer ?
  
  I don't think it requires -fno-omit-frame-pointer. It is just
  incompatible with -fomit-frame-pointer.
 
 From a quick test, you seem to be right.
 
 Now the question of course is whether -pg will internally trigger
 the bug for which we need the workaround tho...

According to http://marc.info/?l=linux-kernelm=121958694215835w=4
just removing -fno-omit-frame-pointer solved the problem.

But I'll double check that on the actual hardware.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT

[Roland Dreier]

  Right, but then you need to set that in the VMA's, and thus gone is your
  nice fast g_u_p() that doesn't touch VMAs :-)

Registering memory is a slow path thing in the RDMA world.  Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can leave it out.

   Yes, but unfortunately MPI says apps can allocate memory however they
   damn well please... in any case these issues are all-too-well-known in
   the RDMA world for quite a while.

  Yup. What do you think of the idea of pre-COWing pages with an elevated
  count at fork time ?

Super-duper sucks if the first thing the child does is exec() :)
Also if the parent has registered  half the memory in the system then
it's instant OOM.  So not that useful for the RDMA case :)

The one thing that might make sense is to pre-COW any partial pages that
the parent has registered -- ie if half a page can be used by the child,
at least pre-COW that, but leave all the full pages with VM_DONTCOPY.

 - R.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Commits pushed to test branch

[Benjamin Herrenschmidt]

I've pushed these commits to the test branch. This include the next
branches from Kumar and Grant, which I'll move over to my next branch
soon, probably tomorrow, if the world doesn't end in the meantime.

The rest is picked up from patchwork, and will trickle up to next as I
see fit unless somebody hollers.

People are _MUCH_WELCOME_ to pull that test branch and test it, that's
the whole point of having it, so we can catch problems before their hit
the next branch that we can't rebase.

Further occurences of this announce won't be that verbose, though I
haven't decided on a proper format or subject tag yet :-)

Anton Vorontsov (2):
  powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support
  powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E

Benjamin Herrenschmidt (3):
  powerpc: Rework I$/D$ coherency (v2)

Grant Likely (7):
  powerpc/5200: Stop using device_type and port-number properties
  powerpc/5200: Trim cruft from device trees
  powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver
  powerpc/5200: Remove pr_debug() from hot paths in irq driver
  powerpc/5200: Refactor mpc5200 interrupt controller driver
  powerpc/5200: Rework GPT driver to also be an IRQ controller
  powerpc/5200: Add support for the Media5200 board from Freescale

Grzegorz Bernacki (1):
  powerpc/5200: Add support for the digsy MTC board.

Kumar Gala (3):
  powerpc/fsl-booke: Cleanup init/exception setup to be runtime
  powerpc/fsl: Ensure PCI_QUIRKS are enabled for FSL_PCI
  powerpc: Unify asm opcode definitions and support

Laurent Pinchart (1):
  cpm2: Round the baud-rate clock divider to the nearest integer.

Martyn Welch (3):
  powerpc/86xx: Board support for GE Fanuc SBC310
  powerpc/86xx: Default configutation for GE Fanuc's SBC310
  powerpc/86xx: Extend GE Fanuc GPIO driver for the SBC310

Michael Ellerman (7):
  powerpc: Remove unused ppc64_terminate_msg()
  powerpc: Allow debugging of LMBs with lmb=debug
  lmb: Rework lmb_dump_all() output
  powerpc/pseries: Fix MSI-X interrupt querying
  powerpc/pseries: Add support for ibm,req#msi-x
  powerpc/pseries: Check for MSI-X also in rtas_msi_pci_irq_fixup()
  powerpc/pseries: Return the number of MSIs we could allocate

Milton Miller (3):
  powerpc/numa: Avoid possible reference beyond prop. length in 
find_min_common_depth()
  powerpc/numa: Remove redundant find_cpu_node()
  powerpc/pseries: Remove write only variable in PCI DLPAR

Peter Korsgaard (1):
  powerpc: convert dts-bindings/fsl/dma.txt to dts-v1 syntax

Reynes Philippe (2):
  powerpc/83xx: Add i2c eeprom to dts for MPC837x RDB
  powerpc/83xx: Add gpio to MPC837x RDB

Trent Piepho (3):
  powerpc/fsl-booke: Remove code duplication in lowmem mapping
  powerpc/fsl-booke: Allow larger CAM sizes than 256 MB
  powerpc/fsl-booke: Make CAM entries used for lowmem configurable

Wolfgang Grandegger (2):
  powerpc/85xx: TQM85xx - fix sensitivity of CAN interrupts
  powerpc/85xx: TQM85xx - add i2c device nodes for LM75



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [ANN] Introducing new test branch in powerpc.git tree

[Kumar Gala]

On Feb 4, 2009, at 10:01 PM, Benjamin Herrenschmidt wrote:


Hoy !

So I've been annoyed for some time by the way we do our preparation  
for
the next merge window. The next branch is defined as not being  
rebased

ever (well, as much as possible), which makes it impossible to just
stash things early in there and rebase if needed, which is a useful
exercise in the weeks leading to the merge window to be able to test
patches, fix them, etc... while keeping a good idea of what's  
planned to

go in.

Thus I've created a test branch. I'll push it out later today with
various things pending. For pulls from sub-maintainers, I'll probably
merge into next quickly (ie. a day or two after hitting test just
enough time to find gross problems). That will allow me to be more
pro-active also at pulling things off the mailing list and sticking  
them
there even if some cosmetic changes have been requested to the patch  
as

I will have no issue rebasing it when the new patch comes in.

Now, one important rule is: test will be reset at the beginning of  
every
merge window. I will not let it degenerate into the old linuxppc-dev  
bk

tree that drifted for years and had things that never got merged.

I'm also not sure whether sub-maintainers should do the same thing  
with

a test branch of their own. I certainly don't mind if they rebase
their next branches so I'm happy for them to play the same game
directly into their 'next' branch as long as the day they ask me to  
pull
it into the real 'next', they are reasonably confident that the  
stuff in

there is stable.

For any complaint, see my secretary in the Oort cloud.


Are you going to ask test get pulled into Stephen's -next tree?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/1 v3] AMCC PPC 460SX redwood SoC platform initial framework

[Kumar Gala]

On Feb 4, 2009, at 5:45 PM, Madhulika Madishetty wrote:

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/ 
cputable.c

index 923f87a..5c40da4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -43,6 +43,7 @@ extern void __setup_cpu_440spe(unsigned long  
offset, struct cpu_spec* spec);
extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec*  
spec);
extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec*  
spec);
extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec*  
spec);
+extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec  
*spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec*  
spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec*  
spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec*  
spec);
@@ -1634,6 +1635,18 @@ static struct cpu_spec __initdata cpu_specs[]  
= {

.machine_check  = machine_check_440A,
.platform   = ppc440,
},
+   { /* 460SX */
+   .pvr_mask   = 0xff00,
+   .pvr_value  = 0x13541800,
+   .cpu_name   = 460SX,
+   .cpu_features   = CPU_FTRS_44X,
+   .cpu_user_features  = COMMON_USER_BOOKE,
+   .icache_bsize   = 32,
+   .dcache_bsize   = 32,
+   .cpu_setup  = __setup_cpu_460sx,
+   .machine_check  = machine_check_440A,
+   .platform   = ppc440,
+   },


This needs to be updated to include the new mmu_features field.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[no subject]

[03212009]

2009-02-05 



03212009 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [ANN] Introducing new test branch in powerpc.git tree

[Benjamin Herrenschmidt]

On Wed, 2009-02-04 at 23:53 -0600, Kumar Gala wrote:
 
 Are you going to ask test get pulled into Stephen's -next tree?

No, I don't intend to let things stage long enough in test for that to
matter and I asked Stephen, he isn't hot about it. Hopefully the max
lifetime for something in test should be around a week.

It's really a way for me to advertise what I want to push out and still
have a last minute chance to catch big mistakes.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC5200 PCI Issues

[Tobias Knutsson]

When enabling the debug-printouts, it came to me that I forgot to
mention something kind of important. Using the standard mpc52xx_pci.c,
even the memory resources are mapped to zero.

After disabling this code block, the memory regions are mapped out
fine (but still no IO):

static void
mpc52xx_pci_fixup_resources(struct pci_dev *dev)
{
int i;

pr_debug(mpc52xx_pci_fixup_resources() %.4x:%.4x\n,
 dev-vendor, dev-device);

/* We don't rely on boot loader for PCI and resets all
   devices */
for (i = 0; i  DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource[i];
if (res-end  res-start) {/* Only valid resources */
res-end -= res-start;
res-start = 0;
res-flags |= IORESOURCE_UNSET;
}
}

What is the purpose of this code? Since all resources are reset here,
where are they inteded to be re-allocated?

Here is the bootlog with the aforementioned code enabled:


reading cuImage.lite5200b

1833699 bytes read
## Booting kernel from Legacy Image at 00201400 ...
   Image Name:   Linux-2.6.28
   Created:  2009-02-05   6:54:20 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1833635 Bytes =  1.7 MB
   Load Address: 0040
   Entry Point:  004005a0
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
[0.00] Using lite5200 machine description
[0.00] Linux version 2.6.28 (tknuts...@ztn-ubuntu) (gcc
version 4.3.2 (Sourcery G++ Lite 4.3-50) ) #66 Thu Feb 5 07:51:46 CET
2009
[0.00] Adding MPC52xx PCI host bridge /p...@fd00
[0.00] PCI host bridge /p...@fd00 (primary) ranges:
[0.00]  MEM 0x5000..0x5fff - 0x5000
[0.00]   IO 0x6000..0x60ff - 0x
[0.00] mpc52xx_pci_setup(hose=c03ec000, pci_regs=fdffad00)
[0.00] mem_resource[0] = {.start=5000, .end=5fff, .flags=200}
[0.00] .io_resource={.start=0,.end=ff,.flags=100}
.io_base_phys=0x6000
[0.00] Zone PFN ranges:
[0.00]   DMA  0x - 0x4000
[0.00]   Normal   0x4000 - 0x4000
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[1] active PFN ranges
[0.00] 0: 0x - 0x4000
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16256
[0.00] Kernel command line: console=ttyPSC0,115200 root=/dev/sda2 rw
[0.00] MPC52xx PIC is up and running!
[0.00] PID hash table entries: 256 (order: 8, 1024 bytes)
[0.00] clocksource: timebase mult[7d0] shift[22] registered
[0.000263] console [ttyPSC0] enabled
[0.121690] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.129012] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.147433] Memory: 60844k/65536k available (3704k kernel code,
4624k reserved, 156k data, 117k bss, 180k init)
[0.157672] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0,
CPUs=1, Nodes=1
[0.165373] Calibrating delay loop... 63.87 BogoMIPS (lpj=127744)
[0.236265] Mount-cache hash table entries: 512
[0.245719] net_namespace: 288 bytes
[0.250237] NET: Registered protocol family 16
[0.284887] PCI: Probing PCI hardware
[0.289670] mpc52xx_pci_fixup_resources() 1057:5809
[0.294799] PCI::00:17.0 Resource 0
5040-507f [21208] fixup...
[0.303180] PCI::00:17.05040-507f
[0.309998] PCI::00:17.0 Resource 1
5080-50ff [20200] fixup...
[0.318262] PCI::00:17.05080-50ff
[0.325062] PCI::00:17.0 Resource 2
6000-600f [20101] fixup...
[0.26] PCI::00:17.06000-600f
[0.340124] mpc52xx_pci_fixup_resources() 104c:9065
[0.345242] PCI::00:18.0 Resource 0
5100-513f [21208] fixup...
[0.353519] PCI::00:18.05100-513f
[0.360319] PCI::00:18.0 Resource 1
5180-51ff [20200] fixup...
[0.368583] PCI::00:18.05180-51ff
[0.375383] PCI::00:18.0 Resource 2
6010-601f [20101] fixup...
[0.383647] PCI::00:18.06010-601f
[0.390444] mpc52xx_pci_fixup_resources() 104c:9065
[0.395549] PCI::00:19.0 Resource 0
5200-523f [21208] fixup...
[0.403826] PCI::00:19.05200-523f
[0.410626] PCI::00:19.0 Resource 1
5280-52ff [20200] fixup...
[0.418889] PCI::00:19.05280-52ff
[0.425690]