linuxsh-dev

Re: the error "undefined reference to `register_profile_notifier'"

[Paul M. <pau...@re...>]

On Tue, Oct 30, 2007 at 05:44:18PM +0800, Shuduo Sang wrote:
> On 10/30/07, Paul Mundt <pau...@re...> wrote:
> > On Tue, Oct 30, 2007 at 06:06:49PM +0900, Paul Mundt wrote:
> > > On Tue, Oct 30, 2007 at 04:21:45PM +0800, Shuduo Sang wrote:
> > > > In arch/sh/oprofile/op_model_sh7750.c, the oprofile code of sh7750
> > > > uses the interface register_profile_notifier() and
> > > > unregister_profile_notifier(), but observably they were removed from
> > > > kernel code. sorry I don't know exactly when they were.
> > > > In current kernel, 2.6.24-rc1, once both oprofile and subtype sh7750
> > > > be selected, the build will fail with the error like "undefined
> > > > reference to `register_profile_notifier'".
> > > > any idea?
> > > >
> > > That shows that no one has built this in some time (about 3 years!)
> > > Try this (untested):
> > >
> > And here's one that even compiles:
> >
> 
> thanks so much. :)
> any plan to main tree?
> 
Already pushed:

	http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commitdiff;h=b46378bc59989d6d284b569b5e2a28e8a50e70f8

It'll be in with the rest of the updates for -rc2.

Re: the error "undefined reference to `register_profile_notifier'"

[Shuduo S. <san...@gm...>]

On 10/30/07, Paul Mundt <pau...@re...> wrote:
> On Tue, Oct 30, 2007 at 06:06:49PM +0900, Paul Mundt wrote:
> > On Tue, Oct 30, 2007 at 04:21:45PM +0800, Shuduo Sang wrote:
> > > In arch/sh/oprofile/op_model_sh7750.c, the oprofile code of sh7750
> > > uses the interface register_profile_notifier() and
> > > unregister_profile_notifier(), but observably they were removed from
> > > kernel code. sorry I don't know exactly when they were.
> > > In current kernel, 2.6.24-rc1, once both oprofile and subtype sh7750
> > > be selected, the build will fail with the error like "undefined
> > > reference to `register_profile_notifier'".
> > > any idea?
> > >
> > That shows that no one has built this in some time (about 3 years!)
> > Try this (untested):
> >
> And here's one that even compiles:
>

thanks so much. :)
any plan to main tree?

> --
>
> diff --git a/arch/sh/oprofile/op_model_sh7750.c b/arch/sh/oprofile/op_model_sh7750.c
> index ebee7e2..6b9a98e 100644
> --- a/arch/sh/oprofile/op_model_sh7750.c
> +++ b/arch/sh/oprofile/op_model_sh7750.c
> @@ -16,7 +16,6 @@
>  #include <linux/errno.h>
>  #include <linux/interrupt.h>
>  #include <linux/fs.h>
> -#include <linux/notifier.h>
>  #include <asm/uaccess.h>
>  #include <asm/io.h>
>
> @@ -44,8 +43,6 @@
>   */
>  #define NR_CNTRS       2
>
> -extern const char *get_cpu_subtype(void);
> -
>  struct op_counter_config {
>         unsigned long enabled;
>         unsigned long event;
> @@ -111,17 +108,12 @@ static struct op_counter_config ctr[NR_CNTRS];
>   * behavior.
>   */
>
> -static int sh7750_timer_notify(struct notifier_block *self,
> -                              unsigned long val, void *regs)
> +static int sh7750_timer_notify(struct pt_regs *regs)
>  {
> -       oprofile_add_sample((struct pt_regs *)regs, 0);
> +       oprofile_add_sample(regs, 0);
>         return 0;
>  }
>
> -static struct notifier_block sh7750_timer_notifier = {
> -       .notifier_call          = sh7750_timer_notify,
> -};
> -
>  static u64 sh7750_read_counter(int counter)
>  {
>         u32 hi, lo;
> @@ -240,7 +232,7 @@ static int sh7750_perf_counter_start(void)
>                 ctrl_outw(pmcr | PMCR_ENABLE, PMCR2);
>         }
>
> -       return register_profile_notifier(&sh7750_timer_notifier);
> +       return register_timer_hook(sh7750_timer_notify);
>  }
>
>  static void sh7750_perf_counter_stop(void)
> @@ -248,7 +240,7 @@ static void sh7750_perf_counter_stop(void)
>         ctrl_outw(ctrl_inw(PMCR1) & ~PMCR_PMEN, PMCR1);
>         ctrl_outw(ctrl_inw(PMCR2) & ~PMCR_PMEN, PMCR2);
>
> -       unregister_profile_notifier(&sh7750_timer_notifier);
> +       unregister_timer_hook(sh7750_timer_notify);
>  }
>
>  static struct oprofile_operations sh7750_perf_counter_ops = {
> @@ -257,13 +249,13 @@ static struct oprofile_operations sh7750_perf_counter_ops = {
>         .stop           = sh7750_perf_counter_stop,
>  };
>
> -int __init oprofile_arch_init(struct oprofile_operations **ops)
> +int __init oprofile_arch_init(struct oprofile_operations *ops)
>  {
>         if (!(current_cpu_data.flags & CPU_HAS_PERF_COUNTER))
>                 return -ENODEV;
>
> -       sh7750_perf_counter_ops.cpu_type = (char *)get_cpu_subtype();
> -       *ops = &sh7750_perf_counter_ops;
> +       ops = &sh7750_perf_counter_ops;
> +       ops->cpu_type = (char *)get_cpu_subtype(&current_cpu_data);
>
>         printk(KERN_INFO "oprofile: using SH-4 (%s) performance monitoring.\n",
>                sh7750_perf_counter_ops.cpu_type);
>

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

Paul Mundt wrote:
> On Tue, Oct 30, 2007 at 09:50:08AM +0100, Heiko Schocher wrote:
>> Paul Mundt wrote:
>>> On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
>>>> After this I get an Intevent 0x1e0, and then nothing more works ...
>>>>
>>>> 1) Has somebody here an idea, where this intevent come from? How I can
>>>> prevent it?
>>>>
>>> It sounds like something is generating an interrupt that you aren't
>>> acking, for some reason it isn't being caught as spurious and disabled,
>>> and you are hanging as a result. If you want to hack around it, you can
>> Here the text ends ... I want to hack around it, what can I do?
>>
> I don't remember what I was writing here, I think it was in relation to
> the set_exception_table_evt() thing that was mentioned later :-)

:-)

>>> This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
>>> wrapped, that shouldn't happen. You shouldn't even be entering the
>>> do_IRQ() path here, are you certain that this is an INTEVT value rather
>>> than an EXPEVT one?
>> Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT
>> value.
>> Or is there a way do_IRQ () is called from an EXPEVT?
>
> In theory, no. In practice, you may have hit a bug in the interrupt
> exception dispatch. If you can trace the path through
> arch/sh/kernel/cpu/sh3/entry.S:handle_exception() and
> interrupt_exception() it might uncover some clues. Dumping out both the
> EXPEVT/INTEVT values would also help to see if something is getting
> mangled.

OK, I try this (but I have to say, I have no debugger ...)

> In any event, the evt2irq() math is correct. If there's nothing obvious
> in the exception dispatch, I'll dig out a SH7750R manual and see if there
> are some vectors that behave in a strange fashion. I suspect you're
> probably the first person to do much testing on SH7750R, SH7751R has had
> much more testing comparatively.

OK, I ll have a look in a SH7751R Manual, maybe there are some differences.

>> asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
>> unsigned long r6, unsigned long r7,
>> struct pt_regs __regs)
>> {
>> struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
>> long ex;
>>
>> lookup_exception_vector(ex);
>> die_if_kernel("1e0 exception", regs, ex);
>> }
>>
>> no change in the output ...
>>
> How about just a printk()? If this triggers at all, the r4 and ex values
> would be interesting to see.

I tried this also with a printk, didnt get an output.

>> Must I use another gcc? I am actually using:
>> Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1
>> 20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007
>>
> This should be fine, though you can of course try a 3.x and a 4.2.x for
> comparison. I used to primarily use ST's 4.1.1 until it stopped being
> able to build the kernel on any interesting configurations.
>
> You can find 3.4.5 and 4.2.1 compilers respectively here:
>
> http://userweb.kernel.org/~lethal/sh4-gcc-3.4.5-glibc-2.3.5.tar.bz2
> http://userweb.kernel.org/~lethal/gnush4_linux_v0702_rc-1-1.i386.tar.gz

thanks!
(If this not helps, I try to build the complete Toolchain ... because this
"error" triggers just after running the init application, maybe there is
a problem with some headers ...)

> Both of those produce working code (at least as far as the kernel is
> concerned), so should easily verify whether you've hit a code generation
> problem or not.
>
>> Is there a board running with a SH7750R? Maybe there is some CPU
>> specific stuff to set up ...
>>
> Can you attach your entire .config? I don't have a SH7750R handy, but can
> probably dig one up if nothing else helps.

Here my complete config, maybe I made a mistake somewhere ...

thanks
Heiko

Re: the error "undefined reference to `register_profile_notifier'"

[Paul M. <pau...@re...>]

On Tue, Oct 30, 2007 at 06:06:49PM +0900, Paul Mundt wrote:
> On Tue, Oct 30, 2007 at 04:21:45PM +0800, Shuduo Sang wrote:
> > In arch/sh/oprofile/op_model_sh7750.c, the oprofile code of sh7750
> > uses the interface register_profile_notifier() and
> > unregister_profile_notifier(), but observably they were removed from
> > kernel code. sorry I don't know exactly when they were.
> > In current kernel, 2.6.24-rc1, once both oprofile and subtype sh7750
> > be selected, the build will fail with the error like "undefined
> > reference to `register_profile_notifier'".
> > any idea?
> > 
> That shows that no one has built this in some time (about 3 years!)
> Try this (untested):
> 
And here's one that even compiles:

--

diff --git a/arch/sh/oprofile/op_model_sh7750.c b/arch/sh/oprofile/op_model_sh7750.c
index ebee7e2..6b9a98e 100644
--- a/arch/sh/oprofile/op_model_sh7750.c
+++ b/arch/sh/oprofile/op_model_sh7750.c
@@ -16,7 +16,6 @@
 #include <linux/errno.h>
 #include <linux/interrupt.h>
 #include <linux/fs.h>
-#include <linux/notifier.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 
@@ -44,8 +43,6 @@
  */
 #define NR_CNTRS	2
 
-extern const char *get_cpu_subtype(void);
-
 struct op_counter_config {
 	unsigned long enabled;
 	unsigned long event;
@@ -111,17 +108,12 @@ static struct op_counter_config ctr[NR_CNTRS];
  * behavior.
  */
 
-static int sh7750_timer_notify(struct notifier_block *self,
-			       unsigned long val, void *regs)
+static int sh7750_timer_notify(struct pt_regs *regs)
 {
-	oprofile_add_sample((struct pt_regs *)regs, 0);
+	oprofile_add_sample(regs, 0);
 	return 0;
 }
 
-static struct notifier_block sh7750_timer_notifier = {
-	.notifier_call		= sh7750_timer_notify,
-};
-
 static u64 sh7750_read_counter(int counter)
 {
 	u32 hi, lo;
@@ -240,7 +232,7 @@ static int sh7750_perf_counter_start(void)
 		ctrl_outw(pmcr | PMCR_ENABLE, PMCR2);
 	}
 
-	return register_profile_notifier(&sh7750_timer_notifier);
+	return register_timer_hook(sh7750_timer_notify);
 }
 
 static void sh7750_perf_counter_stop(void)
@@ -248,7 +240,7 @@ static void sh7750_perf_counter_stop(void)
 	ctrl_outw(ctrl_inw(PMCR1) & ~PMCR_PMEN, PMCR1);
 	ctrl_outw(ctrl_inw(PMCR2) & ~PMCR_PMEN, PMCR2);
 
-	unregister_profile_notifier(&sh7750_timer_notifier);
+	unregister_timer_hook(sh7750_timer_notify);
 }
 
 static struct oprofile_operations sh7750_perf_counter_ops = {
@@ -257,13 +249,13 @@ static struct oprofile_operations sh7750_perf_counter_ops = {
 	.stop		= sh7750_perf_counter_stop,
 };
 
-int __init oprofile_arch_init(struct oprofile_operations **ops)
+int __init oprofile_arch_init(struct oprofile_operations *ops)
 {
 	if (!(current_cpu_data.flags & CPU_HAS_PERF_COUNTER))
 		return -ENODEV;
 
-	sh7750_perf_counter_ops.cpu_type = (char *)get_cpu_subtype();
-	*ops = &sh7750_perf_counter_ops;
+	ops = &sh7750_perf_counter_ops;
+	ops->cpu_type = (char *)get_cpu_subtype(&current_cpu_data);
 
 	printk(KERN_INFO "oprofile: using SH-4 (%s) performance monitoring.\n",
 	       sh7750_perf_counter_ops.cpu_type);

Re: the error "undefined reference to `register_profile_notifier'"

[Paul M. <pau...@re...>]

On Tue, Oct 30, 2007 at 04:21:45PM +0800, Shuduo Sang wrote:
> In arch/sh/oprofile/op_model_sh7750.c, the oprofile code of sh7750
> uses the interface register_profile_notifier() and
> unregister_profile_notifier(), but observably they were removed from
> kernel code. sorry I don't know exactly when they were.
> In current kernel, 2.6.24-rc1, once both oprofile and subtype sh7750
> be selected, the build will fail with the error like "undefined
> reference to `register_profile_notifier'".
> any idea?
> 
That shows that no one has built this in some time (about 3 years!)
Try this (untested):

--

diff --git a/arch/sh/oprofile/op_model_sh7750.c b/arch/sh/oprofile/op_model_sh7750.c
index ebee7e2..cc10704 100644
--- a/arch/sh/oprofile/op_model_sh7750.c
+++ b/arch/sh/oprofile/op_model_sh7750.c
@@ -16,7 +16,6 @@
 #include <linux/errno.h>
 #include <linux/interrupt.h>
 #include <linux/fs.h>
-#include <linux/notifier.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 
@@ -111,17 +110,12 @@ static struct op_counter_config ctr[NR_CNTRS];
  * behavior.
  */
 
-static int sh7750_timer_notify(struct notifier_block *self,
-			       unsigned long val, void *regs)
+static int sh7750_timer_notify(struct pt_regs *regs)
 {
-	oprofile_add_sample((struct pt_regs *)regs, 0);
+	oprofile_add_sample(regs, 0);
 	return 0;
 }
 
-static struct notifier_block sh7750_timer_notifier = {
-	.notifier_call		= sh7750_timer_notify,
-};
-
 static u64 sh7750_read_counter(int counter)
 {
 	u32 hi, lo;
@@ -240,7 +234,7 @@ static int sh7750_perf_counter_start(void)
 		ctrl_outw(pmcr | PMCR_ENABLE, PMCR2);
 	}
 
-	return register_profile_notifier(&sh7750_timer_notifier);
+	return register_timer_hook(sh7750_timer_notify);
 }
 
 static void sh7750_perf_counter_stop(void)
@@ -248,7 +242,7 @@ static void sh7750_perf_counter_stop(void)
 	ctrl_outw(ctrl_inw(PMCR1) & ~PMCR_PMEN, PMCR1);
 	ctrl_outw(ctrl_inw(PMCR2) & ~PMCR_PMEN, PMCR2);
 
-	unregister_profile_notifier(&sh7750_timer_notifier);
+	unregister_timer_hook(sh7750_timer_notify);
 }
 
 static struct oprofile_operations sh7750_perf_counter_ops = {

the error "undefined reference to `register_profile_notifier'"

[Shuduo S. <san...@gm...>]

Hi list,

In arch/sh/oprofile/op_model_sh7750.c, the oprofile code of sh7750
uses the interface register_profile_notifier() and
unregister_profile_notifier(), but observably they were removed from
kernel code. sorry I don't know exactly when they were.
In current kernel, 2.6.24-rc1, once both oprofile and subtype sh7750
be selected, the build will fail with the error like "undefined
reference to `register_profile_notifier'".
any idea?

regards,
Sang Shuduo

Re: Problems starting init on a SH7750R based board

[Paul M. <pau...@re...>]

On Tue, Oct 30, 2007 at 09:50:08AM +0100, Heiko Schocher wrote:
> Paul Mundt wrote:
> > On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
> >> After this I get an Intevent 0x1e0, and then nothing more works ...
> >>
> >> 1) Has somebody here an idea, where this intevent come from? How I can
> >> prevent it?
> >>
> > It sounds like something is generating an interrupt that you aren't
> > acking, for some reason it isn't being caught as spurious and disabled,
> > and you are hanging as a result. If you want to hack around it, you can
> 
> Here the text ends ... I want to hack around it, what can I do?
> 
I don't remember what I was writing here, I think it was in relation to
the set_exception_table_evt() thing that was mentioned later :-)

> > This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
> > wrapped, that shouldn't happen. You shouldn't even be entering the
> > do_IRQ() path here, are you certain that this is an INTEVT value rather
> > than an EXPEVT one?
> Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT 
> value.
> Or is there a way do_IRQ () is called from an EXPEVT?

In theory, no. In practice, you may have hit a bug in the interrupt
exception dispatch. If you can trace the path through
arch/sh/kernel/cpu/sh3/entry.S:handle_exception() and
interrupt_exception() it might uncover some clues. Dumping out both the
EXPEVT/INTEVT values would also help to see if something is getting
mangled.

In any event, the evt2irq() math is correct. If there's nothing obvious
in the exception dispatch, I'll dig out a SH7750R manual and see if there
are some vectors that behave in a strange fashion. I suspect you're
probably the first person to do much testing on SH7750R, SH7751R has had
much more testing comparatively.

> asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
>                                    unsigned long r6, unsigned long r7,
>                                    struct pt_regs __regs)
> {
>         struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
>         long ex;
> 
>         lookup_exception_vector(ex);
>         die_if_kernel("1e0 exception", regs, ex);
> }
> 
> no change in the output ...
> 
How about just a printk()? If this triggers at all, the r4 and ex values
would be interesting to see.

> Must I use another gcc? I am actually using:
> Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1 
> 20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007
> 
This should be fine, though you can of course try a 3.x and a 4.2.x for
comparison. I used to primarily use ST's 4.1.1 until it stopped being
able to build the kernel on any interesting configurations.

You can find 3.4.5 and 4.2.1 compilers respectively here:

	http://userweb.kernel.org/~lethal/sh4-gcc-3.4.5-glibc-2.3.5.tar.bz2
	http://userweb.kernel.org/~lethal/gnush4_linux_v0702_rc-1-1.i386.tar.gz

Both of those produce working code (at least as far as the kernel is
concerned), so should easily verify whether you've hit a code generation
problem or not.

> Is there a board running with a SH7750R? Maybe there is some CPU
> specific stuff to set up ...
> 
Can you attach your entire .config? I don't have a SH7750R handy, but can
probably dig one up if nothing else helps.

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

thanks for responding

Paul Mundt wrote:
> On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
>> After this I get an Intevent 0x1e0, and then nothing more works ...
>>
>> 1) Has somebody here an idea, where this intevent come from? How I can
>> prevent it?
>>
> It sounds like something is generating an interrupt that you aren't
> acking, for some reason it isn't being caught as spurious and disabled,
> and you are hanging as a result. If you want to hack around it, you can

Here the text ends ... I want to hack around it, what can I do?

>> BTW:
>> 4) I think the generic_irq_demux funktion dont work nice, if I get such
>> an eventvector,
>> the resulting irq is 0x7ffffff, and irq is used as an index in
>> generic_handle_irq()
>> struct irq_desc *desc = irq_desc + irq;
>> , and + 0x7ffffff is somewhere in the RAM, thats not good.
>>
> This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
> wrapped, that shouldn't happen. You shouldn't even be entering the
> do_IRQ() path here, are you certain that this is an INTEVT value rather
> than an EXPEVT one?
Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT 
value.
Or is there a way do_IRQ () is called from an EXPEVT?
> You may also want to register a dummy handler at that EVT slot using
> set_exception_table_evt() (you probably also want to invalidate the
> I-cache for sanity after doing so), and see what falls out. That's
> certainly not a valid IRQ vector.

I made:

set_exception_table_evt(0x1e0, do_1e0_restore) in void __init 
trap_init(void)

with do_1e0_restore ()

asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
                                   unsigned long r6, unsigned long r7,
                                   struct pt_regs __regs)
{
        struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
        long ex;

        lookup_exception_vector(ex);
        die_if_kernel("1e0 exception", regs, ex);
}

no change in the output ...

Must I use another gcc? I am actually using:
Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1 
20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007

I think, there is something happening, when the user application is 
starting.
Some problems with Processwitching, Stack, ... Hmm, I have only to set
the following parameters, right?

CONFIG_PAGE_OFFSET=0x80000000
CONFIG_MEMORY_START=0x08000000
CONFIG_MEMORY_SIZE=0x08000000
CONFIG_ZERO_PAGE_OFFSET=0x00001000
CONFIG_BOOT_LINK_OFFSET=0x00800000

Is there a board running with a SH7750R? Maybe there is some CPU 
specific stuff
to set up ...

thanks,
heiko

Re: [PATCH] Fix maple bus compiler warning

[Paul M. <le...@li...>]

On Sun, Oct 28, 2007 at 02:24:10PM +0000, Adrian McMenamin wrote:
> The API for uevent has changed for 2.6.24 and this patch makes a
> consequential clean up.
> 
> (Apols to linux-sh list users seeing this for the second time, I
> should have included lkml first time round for completeness)
> 
> Signed-off-by: Adrian McMenamin <ad...@mc...>
> 
Applied, thanks.

Re: [PATCH] sh: fix zImage build with >=binutils-2.18

[Paul M. <le...@li...>]

On Sat, Oct 27, 2007 at 03:10:25PM +0200, Manuel Lauss wrote:
> >From 0e7c440cac67ba640abe4a36dc15a6f255f929e0 Mon Sep 17 00:00:00 2001
> From: Manuel Lauss <ma...@ro...>
> Date: Sat, 27 Oct 2007 15:05:00 +0200
> Subject: [PATCH] sh: fix zImage build with >=binutils-2.18
> 
> Starting with binutils somewhere around 2.17.50.14 the vmlinux file
> contains a ".note.gnu.build-id" section which doesn't get removed when
> the zImage is built; resulting in a 2GB intermediate file and a broken
> zImage.
> 
> Signed-off-by: Manuel Lauss <ma...@ro...>

Applied, thanks.

Re: Problems starting init on a SH7750R based board

[Paul M. <le...@li...>]

On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
> After this I get an Intevent 0x1e0, and then nothing more works ...
> 
> 1) Has somebody here an idea, where this intevent come from? How I can 
> prevent it?
> 
It sounds like something is generating an interrupt that you aren't
acking, for some reason it isn't being caught as spurious and disabled,
and you are hanging as a result. If you want to hack around it, you can 

> BTW:
> 4) I think the generic_irq_demux funktion dont work nice, if I get such 
> an eventvector,
>     the resulting irq is 0x7ffffff, and irq is used as an index in 
> generic_handle_irq()
>         struct irq_desc *desc = irq_desc + irq;
>     , and + 0x7ffffff is somewhere in the RAM, thats not good.
> 
This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
wrapped, that shouldn't happen. You shouldn't even be entering the
do_IRQ() path here, are you certain that this is an INTEVT value rather
than an EXPEVT one?

You may also want to register a dummy handler at that EVT slot using
set_exception_table_evt() (you probably also want to invalidate the
I-cache for sanity after doing so), and see what falls out. That's
certainly not a valid IRQ vector.

Re: [RFC PATCH] I2C bus driver for SH7760 SoC

[Paul M. <le...@li...>]

Basically this looks good to me, though a few minor nits:

On Thu, Oct 25, 2007 at 08:23:27PM +0200, Manuel Lauss wrote:
> +struct cami2c {
> +	void __iomem *iobase;	/* channel base address */
> +	struct i2c_adapter adap;
> +	u32 func;		/* supported functions */
> +	int irq;		/* IRQ vector */
> +	int chan;		/* channel number (0 or 1) */
> +
chan should be a bitfield? Or dynamically calculated based on the number
of registered platform devices?

> +/* calculate CCR register setting for a desired scl clock */
> +static int __devinit calc_CCR(unsigned long scl_freq)
> +{
> +	struct clk *mclk;
> +	unsigned long mck, m1, dff, odff, iclk;
> +	signed char cdf, cdfm = 0;
> +	int scgd, scgdm;
> +
> +	mclk = clk_get(NULL, "module_clk");
> +	if (!mclk) {
> +		mck = CONFIG_SH_PCLK_FREQ;

If the module_clk isn't valid, the system is going to be in bad enough
shape as it is. You should error out on this rather than using
SH_PCLK_FREQ directly. ie,

	if (IS_ERR(mclk))
		return PTR_ERR(mclk);

> +	id->iobase = (void __iomem *)res->start;

You should be ioremap()'ing or ioport_map()'ing this. Either one should
be sane here. Presently this will whine if you use 64-bit resources. The
existing in-tree users that do this casting need to be changed also.

> +out2:	free_irq(id->irq, (void *)id);

Useless cast.

> +static int __devexit sh7760_i2c_remove(struct platform_device *pdev)
> +{
> +	struct cami2c *id = platform_get_drvdata(pdev);
> +
> +	if (id) {
> +		i2c_del_adapter(&id->adap);
> +		free_irq(id->irq, (void *)id);

Likewise.

Once those are tidied up, feel free to add my Acked-by.

Re: [alsa-devel] [PATCH] Dreamcast AICA sound - Get rid of annoying compiler warning

[Takashi I. <ti...@su...>]

At Sun, 28 Oct 2007 14:27:04 +0000,
Adrian McMenamin wrote:
> 
> This patch supresses an annoying compiler warning that the variable
> err may be used uninitialised.
> 
> Signed-off by: Adrian McMenamin <ad...@mc...>

Applied to ALSA tree now.

Thanks,

Takashi

> 
> 
> diff --git a/sound/sh/aica.c b/sound/sh/aica.c
> index 88dc840..8861d2f 100644
> --- a/sound/sh/aica.c
> +++ b/sound/sh/aica.c
> @@ -237,6 +237,7 @@ static int aica_dma_transfer(int channels, int buffer_size,
>  	struct snd_card_aica *dreamcastcard;
>  	struct snd_pcm_runtime *runtime;
>  	unsigned long flags;
> +	err = 0;
>  	dreamcastcard = substream->pcm->private_data;
>  	period_offset = dreamcastcard->clicks;
>  	period_offset %= (AICA_PERIOD_NUMBER / channels);
> _______________________________________________
> Alsa-devel mailing list
> Als...@al...
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

[PATCH] Dreamcast AICA sound - Get rid of annoying compiler warning

[Adrian M. <lkm...@gm...>]

This patch supresses an annoying compiler warning that the variable
err may be used uninitialised.

Signed-off by: Adrian McMenamin <ad...@mc...>


diff --git a/sound/sh/aica.c b/sound/sh/aica.c
index 88dc840..8861d2f 100644
--- a/sound/sh/aica.c
+++ b/sound/sh/aica.c
@@ -237,6 +237,7 @@ static int aica_dma_transfer(int channels, int buffer_size,
 	struct snd_card_aica *dreamcastcard;
 	struct snd_pcm_runtime *runtime;
 	unsigned long flags;
+	err = 0;
 	dreamcastcard = substream->pcm->private_data;
 	period_offset = dreamcastcard->clicks;
 	period_offset %= (AICA_PERIOD_NUMBER / channels);

[PATCH - SH] Clean up maple bus code to supress compiler warning

[Adrian M. <lkm...@gm...>]

The API for uevent has changed for 2.6.24 and this patch makes a
consequential clean up.

(Apols to linux-sh list users seeing this for the second time, I
should have included lkml first time round for completeness)

Signed-off-by: Adrian McMenamin <ad...@mc...>

diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 161d102..e52a629 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -601,8 +601,7 @@ static int match_maple_bus_driver(struct device *devptr,
        return 0;
 }

-static int maple_bus_uevent(struct device *dev, char **envp,
-                           int num_envp, char *buffer, int buffer_size)
+static int maple_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
        return 0;
 }

[PATCH] Fix maple bus compiler warning

[Adrian M. <ad...@ne...>]

The uevent API has changed from 2.6.22 and this patch eliminates
annoying compiler errors

Signed off by: Adrian McMenamin <ad...@mc...>



diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 161d102..e52a629 100644 (file)
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -601,8 +601,7 @@ static int match_maple_bus_driver(struct device
*devptr,

        return 0;
 }

-static int maple_bus_uevent(struct device *dev, char **envp,
-                           int num_envp, char *buffer, int buffer_size)

+static int maple_bus_uevent(struct device *dev, struct kobj_uevent_env
*env)
 {
        return 0;
 }

[PATCH] sh: fix zImage build with >=binutils-2.18

[Manuel L. <ma...@ro...>]

>From 0e7c440cac67ba640abe4a36dc15a6f255f929e0 Mon Sep 17 00:00:00 2001
From: Manuel Lauss <ma...@ro...>
Date: Sat, 27 Oct 2007 15:05:00 +0200
Subject: [PATCH] sh: fix zImage build with >=binutils-2.18

Starting with binutils somewhere around 2.17.50.14 the vmlinux file
contains a ".note.gnu.build-id" section which doesn't get removed when
the zImage is built; resulting in a 2GB intermediate file and a broken
zImage.

Signed-off-by: Manuel Lauss <ma...@ro...>
---
 arch/sh/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index db808d7..27a0469 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -66,7 +66,7 @@ cflags-y	+= $(isaflags-y) -ffreestanding
 cflags-$(CONFIG_MORE_COMPILE_OPTIONS)	+= \
 	$(shell echo $(CONFIG_COMPILE_OPTIONS) | sed -e 's/"//g')
 
-OBJCOPYFLAGS	:= -O binary -R .note -R .comment -R .stab -R .stabstr -S
+OBJCOPYFLAGS	:= -O binary -R .note -R .note.gnu.build-id -R .comment -R .stab -R .stabstr -S
 
 #
 # arch/sh/defconfig doesn't reflect any real hardware, and as such should
-- 
1.5.3.4

Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello,

I am new to the sh port for Linux. I succesfully ported U-Boot to an 
SH7750R based
board, and trying to get Linux running. It works pretty nice until the 
init is loaded.
After this I get an Intevent 0x1e0, and then nothing more works ...

1) Has somebody here an idea, where this intevent come from? How I can 
prevent
    it?

2) I see this intevent only, after the console output "Freeing unused 
kernel memory: 88k freed"

3) Sometimes I see the output from the BusyBox, or from a hello_world 
applikation,
    sometimes I see nothing, somtimes after this intevent a ping to the 
board works,
    sometimes the console is working(I get back the characters I send)  ...

BTW:
4) I think the generic_irq_demux funktion dont work nice, if I get such 
an eventvector,
    the resulting irq is 0x7ffffff, and irq is used as an index in 
generic_handle_irq()
        struct irq_desc *desc = irq_desc + irq;
    , and + 0x7ffffff is somewhere in the RAM, thats not good.


Here my output from the console:

U-Boot 1.3.0-rc2-ga55412ee-dirty (Oct 26 2007 - 16:29:30)

CPU: SH4
     PVR: 4050045
     PRR: 103
     CVR: 20480000
BOARD: POSEIDON
DRAM:  128MB
FLASH: 1MB
640x480x15 31kHz 59Hz
Video: Drawing the logo ...
In:    serial
Out:   serial
Err:   serial
Net:   RTL8019AS
IDE:   Bus 0: OK
  Device 0: Model: PQI FLASH DISK Firm: db01.17a Ser#:
            Type: Removable Hard Disk
            Capacity: 62.5 MB = 0.0 GB (128000 x 512)
Hit any key to stop autoboot:  0
=>
=> run net_nfs
TFTP from server 192.168.1.4; our IP address is 192.168.1.10
Filename 'kernel'.
Load address: 0xc000000
Loading: #################################################################
         ######################
done
Bytes transferred = 1273920 (137040 hex)
## Booting image at 0c000000 ...
   Image Name:   testimage
   Created:      2007-10-26  15:31:23 UTC
   Image Type:   SuperH Linux Kernel Image (uncompressed)
   Data Size:    1273856 Bytes =  1.2 MB
   Load Address: 08800000
   Entry Point:  08800000
   Verifying Checksum ... OK
OK
starting SH kernel ...
Uncompressing Linux...
Ok, booting the kernel.

Linux version 2.6.23-rc9-ge2a57a81-dirty (hs@Zeus) (gcc version 4.1.1 
20061011 (Red Hat 4.1.1-30)) #504 Fri Oct 26 17:30:37 CEST 2007
Booting machvec: POSEIDON
Node 0: start_pfn = 0x8000, low = 0x10000
Zone PFN ranges:
  Normal      32768 ->    65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:    32768 ->    65536
Built 1 zonelists in Zone order.  Total pages: 32512
Kernel command line: root=/dev/nfs rw 
nfsroot=192.168.1.4:/home/hs/Entwicklung/sh4/rootfs,rsize=1024,wsize=1024 
ip=192.168.1.10:192.168.1.4::255.255.255.0:poseidon:eth0:off panic=1 
console=ttySC1,38400 netdev=8,0xa0200000,0,0xbad,eth0
PID hash table entries: 512 (order: 9, 2048 bytes)
Using tmu for system timer
Using 8.333 MHz high precision timer.
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127360k/131072k available (1886k kernel code, 417k data, 88k init)
PVR=04050045 CVR=20480000 PRR=00000103
I-cache : n_ways=2 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7750R
NET: Registered protocol family 16
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (8 channels).
Time: SuperH clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
fuse init (API version 7.8)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
console [ttySC1] enabled
loop: module loaded
NE*000 ethercard probe at 0xa0200000:dev IRQ: 8
 5a 77 3d 57 93 16
eth0: NE2000 found at 0xa0200000, using IRQ 8.
shwdt: initialized. heartbeat=30 sec (nowayout=0)
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
      device=eth0, addr=192.168.1.10, mask=255.255.255.0, 
gw=255.255.255.255,
     host=poseidon, domain=, nis-domain=(none),
     bootserver=192.168.1.4, rootserver=192.168.1.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.4
Looking up port of RPC 100005/1 on 192.168.1.4
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 88k freed
init started: BusyBox v1.7.2 (2007-10-24 12:59:04 CEST)
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
[...]
(between each "irq: 7ffffff evt: 1e0" line is a pause from approx. 1 minute)

To get the last outputs, I made a boardspecific irq_demux function:

static inline int poseidon_irq_demux(int irq)
{
        if ((irq != 16)  && (irq != 8) && (irq != 43))printk (" irq: %x 
evt: %x\n", irq, irq2evt(irq));
        /* 8 Ethernet, 43 Tx Empty, 16 Timer IRQ */
        irq &= 0xff;
        return irq;
}

(I now, I get now irq=255, but this is better then 0x7ffffff ;-) I 
think, the problem is in
getting the intevt 0x1e0 in the do_IRQ () function, but i have no idea, 
why this happens,
and how to prevent, solve it. Hope somebody here has an idea.

I also tried as init application an hello_world, same behaviour ....

thanks in advance
Heiko

Re: git

[Adrian M. <ad...@ne...>]

On Thu, 2007-10-25 at 13:19 +0900, Paul Mundt wrote:
> On Wed, Oct 24, 2007 at 11:41:38PM +0100, Adrian McMenamin wrote:

> > 
> I also have an outdated gitweb on linux-sh.org, I can get that fixed up
> if you'd prefer to use that directly.
> 
> > As an aside: was really surprised at how hard git hammers on the
> > server's resources.
> > 
> You just need enough RAM to fit the working set in page cache, then the
> problem works itself out ;-)

Thanks for the offer, but I think I have it more or less fixed now:

http://newgolddream.dyndns.info/cgi-bin/gitweb.cgi

Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot

[Kristoffer E. <kri...@gm...>]

Greetings,

I made another BAD kernel just to make sure that generic was inside it,
turns out the new bad kernel gives out : sd 0:0:0:0: Attached scsi generic
sg0 type 0 and still fails.
My mistake for not compiling the latest bad kernel myself.
So back to square one then I guess.

I did a small bisect last night going through arch/sh only and it didn't
produce any workable kernel, so atleast that implies the error lies
elsewhere.
Will see if I can bisect all changes and see where I end up.

Though:
ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77 this line
still contains "+mmio" when compaired to the good kernel. Not sure if that
actually reflects anything since we were using mmio long before, but perhaps
didn't inform about it at bootup.

Thanks for commenting paul

2007/10/25, Paul Mundt <le...@li...>:
>
> On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote:
> > The bottom line seems to be that it fails to attach scsi sg0. It
> > explains why it doesn't work, but not why it stopped working. And this
> > has nothing to do with the current kernel config, I've been over that
> > the last 4 days. It all started when I synced my jlime-current.git
> > repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then
> > synced up to 2.6.23-rc8/rc9 and thats when the troubles started.
> >
> At least that suggests it's not fallout from the INTC changes in -rc1, so
> that helps to narrow it down a bit. Since you have a known good and bad,
> it would be nice if you could bisect this to figure out what exactly
> caused the regression. There weren't any SH-specific changes between rc6
> and rc8/rc9 at least.
>

Re: [SUPERH / PATA / SCSI] Unable to do start userland after kernel boot

[Paul M. <le...@li...>]

On Thu, Oct 25, 2007 at 09:22:40PM -0700, Kristoffer Ericson wrote:
> The bottom line seems to be that it fails to attach scsi sg0. It
> explains why it doesn't work, but not why it stopped working. And this
> has nothing to do with the current kernel config, I've been over that
> the last 4 days. It all started when I synced my jlime-current.git
> repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then
> synced up to 2.6.23-rc8/rc9 and thats when the troubles started.
> 
At least that suggests it's not fallout from the INTC changes in -rc1, so
that helps to narrow it down a bit. Since you have a known good and bad,
it would be nice if you could bisect this to figure out what exactly
caused the regression. There weren't any SH-specific changes between rc6
and rc8/rc9 at least.

[SUPERH / PATA / SCSI] Unable to do start userland after kernel boot

[Kristoffer E. <kri...@gm...>]

Greetings,

I know I'm being annoying about this, but kinda a show stopper for hp6xx currently.
I compaired a bootlog (good kernel vs bad kernel), and they are identical apart from this stuff

The bottom line seems to be that it fails to attach scsi sg0. It explains why it doesn't work, but not why it stopped working. And this has nothing to do with the current kernel config, I've been over that the last 4 days. It all started when I synced my jlime-current.git repository with linux-2.6.git. As you can see I had 2.6.23-rc6 and then synced up to 2.6.23-rc8/rc9 and thats when the troubles started.

Any scsi/libata gurus giving feedback on this would be appreciated.

Best wishes
Kristoffer Ericson

[BAD KERNEL]
(Linux version 2.6.23-gbc53c3a1-dirty (kristoffer@Wolverine) (gcc version 3.4.5) #2 Tue Oct 23 19:34:27 PDT 2007)
scsi0 : pata_platform
ata1: PATA max PIO0 mmio cmd 0x150001f0 ctl 0x150001fe irq 77  <-- "mmio cmd" + ""
ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4
ata1.00: 2002896 sectors, multi 0: LBA
ata1.00: configured for PIO
scsi 0:0:0:0: Direct-Access     ATA      Hitachi XX.V.3.5 Rev  PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI removable disk
.........
.........
........
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 128k freed
Failed to execute /bin/sh.  Attempting defaults...
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.


[GOOD KERNEL]
(Linux version 2.6.23-rc6-gab762e2c-dirty (rafa@nodo3) (gcc version 3.4.4) #51 Sun Oct 21 15:23:19 ART 2007)
scsi0 : pata_platform
ata1: PATA max PIO0 cmd 0xb50001f0 ctl 0xb50001fe bmdma 0x00000000 irq 77 <--- "cmd" + "bmdma"
ata1.00: CFA: Hitachi XX.V.3.5.0.0, Rev 0.00, max PIO4
ata1.00: 2002896 sectors, multi 0: LBA
ata1.00: configured for PIO
ata1: EH pending after completion, repeating EH (cnt=4)
scsi 0:0:0:0: Direct-Access     ATA      Hitachi XX.V.3.5 Rev  PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 2002896 512-byte hardware sectors (1025 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0   <---- Only here, missing from bad kernel.
............
...........
.............
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 140k freed
/bin/sh: can't access tty; job control turned off       (init=/bin/sh was used as bootparam)
/ $ 

[RFC PATCH] I2C bus driver for SH7760 SoC

[Manuel L. <ma...@ro...>]

Good evening,

Here's a i2c bus driver for the 2 I2C interfaces of the SH7760.
I've been using this driver for 2 years now, and it seems to be very solid.
Tested with I2C touchscreens, I2S codecs, lots of eeproms and a MOST
controller.

Patch is againts latest git, comments appreciated.

Thanks!
	Manuel Lauss

---

>From b122c7a16f2a8bf664e2d478562e490cd3df6141 Mon Sep 17 00:00:00 2001
From: Manuel Lauss <ma...@ro...>
Date: Thu, 25 Oct 2007 20:05:44 +0200
Subject: [PATCH] i2c-sh7760: I2C bus driver for SH7760 SoC


Signed-off-by: Manuel Lauss <ma...@ro...>
---
 drivers/i2c/busses/Kconfig      |   11 +
 drivers/i2c/busses/Makefile     |    1 +
 drivers/i2c/busses/i2c-sh7760.c |  598 +++++++++++++++++++++++++++++++++++++++
 include/asm-sh/i2c-sh7760.h     |   23 ++
 4 files changed, 633 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-sh7760.c
 create mode 100644 include/asm-sh/i2c-sh7760.h

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c466c6c..94d6cc9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -675,4 +675,15 @@ config I2C_PMCMSP
 	  This driver can also be built as module. If so, the module
 	  will be called i2c-pmcmsp.
 
+config I2C_SH7760
+	tristate "Renesas SH7760 I2C Controller"
+	depends on I2C && CPU_SUBTYPE_SH7760
+	default n
+	help
+	  If you say yes to this option, support will be included for the
+	  built-in I2C interface of the Renesas SH7760 processor.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called i2c-sh7760.
+
 endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 81d43c2..548839e 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_I2C_SIMTEC)	+= i2c-simtec.o
 obj-$(CONFIG_I2C_SIS5595)	+= i2c-sis5595.o
 obj-$(CONFIG_I2C_SIS630)	+= i2c-sis630.o
 obj-$(CONFIG_I2C_SIS96X)	+= i2c-sis96x.o
+obj-$(CONFIG_I2C_SH7760)	+= i2c-sh7760.o
 obj-$(CONFIG_I2C_STUB)		+= i2c-stub.o
 obj-$(CONFIG_I2C_TAOS_EVM)	+= i2c-taos-evm.o
 obj-$(CONFIG_I2C_TINY_USB)	+= i2c-tiny-usb.o
diff --git a/drivers/i2c/busses/i2c-sh7760.c b/drivers/i2c/busses/i2c-sh7760.c
new file mode 100644
index 0000000..d901656
--- /dev/null
+++ b/drivers/i2c/busses/i2c-sh7760.c
@@ -0,0 +1,598 @@
+/*
+ * I2C bus driver for the SH7760 I2C Interfaces.
+ *
+ * (c) 2005-2007 MSC Vertriebsges.m.b.H.
+ *	<ml...@ms...>., <ma...@ro...>
+ *
+ * licensed under the terms outlined in the file COPYING.
+ *
+ */
+
+/* NOTE: SMBus QUICK Probe feature is "emulated" by reading 1 byte from
+ *	 the slave address, because the SH7760 I2C cannot be programmed
+ *	 to send a stop immediately after receiving the slave ACK/NACK.
+ *	 If this behavior is not wanted, set platform_data.noquick to 1.
+ */
+
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+
+#include <asm/clock.h>
+#include <asm/i2c-sh7760.h>
+#include <asm/io.h>
+
+/* register offsets */
+#define I2CSCR		0x0		/* slave ctrl */
+#define I2CMCR		0x4		/* master ctrl */
+#define I2CSSR		0x8		/* slave status */
+#define I2CMSR		0xC		/* master status */
+#define I2CSIER		0x10		/* slave irq enable */
+#define I2CMIER		0x14		/* master irq enable */
+#define I2CCCR		0x18		/* clock dividers */
+#define I2CSAR		0x1c		/* slave address */
+#define I2CMAR		0x20		/* master address */
+#define I2CRXTX		0x24		/* data port */
+#define I2CFCR		0x28		/* fifo control */
+#define I2CFSR		0x2C		/* fifo status */
+#define I2CFIER		0x30		/* fifo irq enable */
+#define I2CRFDR		0x34		/* rx fifo count */
+#define I2CTFDR		0x38		/* tx fifo count */
+
+#define REGSIZE		0x3C
+
+#define MCR_MDBS	0x80
+#define MCR_FSCL	0x40
+#define MCR_FSDA	0x20
+#define MCR_OBPC	0x10
+#define MCR_MIE		0x08
+#define MCR_TSBE	0x04
+#define MCR_FSB		0x02
+#define MCR_ESG		0x01
+
+#define MSR_MNR		0x40
+#define MSR_MAL		0x20
+#define MSR_MST		0x10
+#define MSR_MDE		0x08
+#define MSR_MDT		0x04
+#define MSR_MDR		0x02
+#define MSR_MAT		0x01
+
+#define MIE_MNRE	0x40
+#define MIE_MALE	0x20
+#define MIE_MSTE	0x10
+#define MIE_MDEE	0x08
+#define MIE_MDTE	0x04
+#define MIE_MDRE	0x02
+#define MIE_MATE	0x01
+
+#define FCR_RFRST	0x02
+#define FCR_TFRST	0x01
+
+#define FSR_TEND	0x04
+#define FSR_RDF		0x02
+#define FSR_TDFE	0x01
+
+#define FIER_TEIE	0x04
+#define FIER_RXIE	0x02
+#define FIER_TXIE	0x01
+
+#define FIFO_SIZE	16
+
+struct cami2c {
+	void __iomem *iobase;	/* channel base address */
+	struct i2c_adapter adap;
+	u32 func;		/* supported functions */
+	int irq;		/* IRQ vector */
+	int chan;		/* channel number (0 or 1) */
+
+	/* message processing */
+	struct i2c_msg	*msg;
+#define IDF_SEND	1
+#define IDF_RECV	2
+#define IDF_STOP	4
+	int		flags;
+
+#define IDS_DONE	1
+#define IDS_ARBLOST	2
+#define IDS_NACK	4
+	int		status;
+	struct completion xfer_done;
+};
+
+static inline void OUT32(struct cami2c *cam, int reg, unsigned long val)
+{
+	ctrl_outl(val, (unsigned long)cam->iobase + reg);
+}
+
+static inline unsigned long IN32(struct cami2c *cam, int reg)
+{
+	return ctrl_inl((unsigned long)cam->iobase + reg);
+}
+
+static irqreturn_t sh7760_i2c_irq(int this_irq, void *ptr)
+{
+	struct cami2c *id = ptr;
+	struct i2c_msg *msg;
+	unsigned long msr, fsr, fier, len;
+	char *data;
+
+	msg = id->msg;
+	data = msg->buf;
+
+	msr = IN32(id, I2CMSR);
+	fsr = IN32(id, I2CFSR);
+
+	/* arbitration lost */
+	if (msr & MSR_MAL) {
+		OUT32(id, I2CMCR, 0);
+		OUT32(id, I2CSCR, 0);
+		OUT32(id, I2CSAR, 0);
+		id->status |= IDS_DONE | IDS_ARBLOST;
+		goto out;
+	}
+
+	if (msr & MSR_MNR) {
+		/* NACK handling is very screwed up.  After receiving a
+		 * NAK IRQ one has to wait a bit  before writing to any
+		 * registers, or the ctl will lock up. After that delay
+		 * do a normal i2c stop. Then wait at least 1 ms before
+		 * attempting another xfer or risk another ctl hang.
+		 */
+		udelay(100);	/* wait or risk ctl hang */
+		OUT32(id, I2CFCR, FCR_RFRST | FCR_TFRST);
+		OUT32(id, I2CMCR, MCR_MIE | MCR_FSB);
+		OUT32(id, I2CFIER, 0);
+		OUT32(id, I2CMIER, MIE_MSTE);
+		OUT32(id, I2CSCR, 0);
+		OUT32(id, I2CSAR, 0);
+		id->status |= IDS_NACK;
+		msr &= ~MSR_MAT;
+		fsr = 0;
+		/* In some cases the MST bit is also set; so don't go
+		 * to the end of the handler
+		 */
+	}
+
+	/* i2c-stop was sent */
+	if (msr & MSR_MST) {
+		id->status |= IDS_DONE;
+		goto out;
+	}
+
+	/* i2c slave addr was sent */
+	if (msr & MSR_MAT)
+		OUT32(id, I2CMCR, MCR_MIE);
+
+	fier = IN32(id, I2CFIER);
+
+	if (fsr & FSR_RDF) {
+		/* there is data in the receive fifo */
+		len = IN32(id, I2CRFDR);
+		if (msg->len <= len) {
+			/* all data received, stop if required */
+			if (id->flags & IDF_STOP) {
+				OUT32(id, I2CMCR, MCR_MIE | MCR_FSB);
+				OUT32(id, I2CFIER, 0);
+				/* manual says: wait >= 0.5 SCL times */
+				udelay(5);
+				/* next int should contain MST */
+			} else {
+				id->status |= IDS_DONE;
+				/* keep the RDF bit: ctrl holds SCL low
+				 * until the setup for the next i2c_msg
+				 * clears this bit and ctl resumes work.
+				 */
+				fsr &= ~FSR_RDF;
+			}
+		}
+		/* read fifo */
+		while (msg->len && len) {
+			*data++ = IN32(id, I2CRXTX);
+			msg->len--;
+			len--;
+		}
+
+		if (msg->len) {
+			/* (re)adjust rx-fifo trigger */
+			if (msg->len >= FIFO_SIZE)
+				len = FIFO_SIZE - 1;
+			else
+				len = msg->len - 1;
+
+			OUT32(id, I2CFCR, FCR_TFRST | ((len & 0xf) << 4));
+		}
+
+	} else if (id->flags & IDF_SEND) {
+		/* transfer has ended, and no more data to send */
+		if ((fsr & FSR_TEND) && (msg->len < 1)) {
+			if (id->flags & IDF_STOP) {
+				OUT32(id, I2CMCR, MCR_MIE | MCR_FSB);
+			} else {
+				id->status |= IDS_DONE;
+				/* keep the TEND bit: ctl holds SCL low
+				 * until the setup for the next i2c_msg
+				 * clears this bit and ctl resumes work.
+				 */
+				fsr &= ~FSR_TEND;
+			}
+		}
+
+		/* there is an opening in the TX FIFO */
+		if (fsr & FSR_TDFE) {
+			while (msg->len && (IN32(id, I2CTFDR) < FIFO_SIZE)) {
+				OUT32(id, I2CRXTX, *data++);
+				(msg->len)--;
+			}
+
+			if (msg->len < 1) {
+				fier &= ~FIER_TXIE;
+				OUT32(id, I2CFIER, fier);
+			} else {
+				/* adjust tx-fifo trigger */
+				if (msg->len >= FIFO_SIZE)
+					len = 2;
+				else
+					len = 0;
+
+				OUT32(id, I2CFCR,
+					FCR_RFRST | ((len & 3) << 2));
+			}
+		}
+	}
+out:
+	if (id->status & IDS_DONE) {
+		OUT32(id, I2CMIER, 0);
+		OUT32(id, I2CFIER, 0);
+		id->msg = NULL;
+		complete(&id->xfer_done);
+	}
+	/* clear status flags and ctrl resumes work */
+	OUT32(id, I2CMSR, ~msr);
+	OUT32(id, I2CFSR, ~fsr);
+	OUT32(id, I2CSSR, 0);
+
+	return IRQ_HANDLED;
+}
+
+static inline int sh7760_i2c_bsy_check(struct cami2c *id)
+{
+	return (IN32(id, I2CMCR) & MCR_FSDA);
+}
+
+/* prepare and start a master receive operation */
+static void sh7760_i2c_mrecv(struct cami2c *id)
+{
+	int len;
+
+	/* set the slave addr reg; otherwise rcv wont work! */
+	OUT32(id, I2CSAR, 0xfe);
+	OUT32(id, I2CMAR, (id->msg->addr << 1) | 1);
+
+	/* adjust rx fifo trigger */
+	if (id->msg->len >= FIFO_SIZE)
+		len = FIFO_SIZE - 1;	/* trigger at fifo full */
+	else
+		len = id->msg->len - 1;	/* trigger before all received */
+
+	OUT32(id, I2CFCR, FCR_RFRST | FCR_TFRST);
+	OUT32(id, I2CFCR, FCR_TFRST | ((len & 0xF) << 4));
+
+	id->flags |= IDF_RECV;
+
+	OUT32(id, I2CMSR, 0);
+	if (id->msg->flags & I2C_M_NOSTART)
+		OUT32(id, I2CMCR, MCR_MIE);
+	else
+		OUT32(id, I2CMCR, MCR_MIE | MCR_ESG);
+
+	OUT32(id, I2CMIER, MIE_MNRE | MIE_MALE | MIE_MSTE | MIE_MATE);
+	OUT32(id, I2CFIER, FIER_RXIE);
+}
+
+/* prepare and start a master send operation */
+static void sh7760_i2c_msend(struct cami2c *id)
+{
+	int len;
+
+	/* set the slave addr reg; otherwise xmit wont work! */
+	OUT32(id, I2CSAR, 0xfe);
+	OUT32(id, I2CMAR, (id->msg->addr << 1) | 0);
+
+	/* adjust tx fifo trigger */
+	if (id->msg->len >= FIFO_SIZE)
+		len = 2;	/* trig: 2 bytes left in TX fifo */
+	else
+		len = 0;	/* trig: 8 bytes left in TX fifo */
+
+	OUT32(id, I2CFCR, FCR_RFRST | FCR_TFRST);
+	OUT32(id, I2CFCR, FCR_RFRST | ((len & 3) << 2));
+
+	while (id->msg->len && IN32(id, I2CTFDR) < FIFO_SIZE) {
+		OUT32( id, I2CRXTX, *(id->msg->buf));
+		(id->msg->len)--;
+		(id->msg->buf)++;
+	}
+
+	id->flags |= IDF_SEND;
+
+	OUT32(id, I2CMSR, 0);
+	if (id->msg->flags & I2C_M_NOSTART)
+		OUT32(id, I2CMCR, MCR_MIE);
+	else
+		OUT32(id, I2CMCR, MCR_MIE | MCR_ESG);
+
+	OUT32(id, I2CFSR, 0);
+
+	OUT32(id, I2CMIER, MIE_MNRE | MIE_MALE | MIE_MSTE | MIE_MATE);
+	OUT32(id, I2CFIER, FIER_TEIE | (id->msg->len ? FIER_TXIE : 0));
+}
+
+static int sh7760_i2c_master_xfer(struct i2c_adapter *adap,
+				  struct i2c_msg *msgs,
+				  int num)
+{
+	struct cami2c *id = adap->algo_data;
+	struct i2c_msg *msg = msgs, qmsg;
+	int i, addr, retr;
+	unsigned char buf;	/* dummy for qmsg */
+
+	if (sh7760_i2c_bsy_check(id)) {
+		pr_debug("sh7760-i2c%d: bus is busy!\n", id->chan);
+		num = -EBUSY;
+	}
+
+	i = 0;
+	while ((i < num) && (num > 0)) {
+		addr = msg->addr << 1;
+		if (msg->len < 1) {
+			/* SMBus Quick "emulation":
+			 * setup a dummy msg to read 1 byte from addr.
+			 */
+			qmsg.addr = msg->addr;
+			qmsg.len = 1;
+			qmsg.flags = msg->flags;
+			qmsg.buf = &buf;
+			addr |= 1;
+			id->msg = &qmsg;
+		} else {
+			if (msg->flags & I2C_M_RD)
+				addr |= 1;
+			if (msg->flags & I2C_M_REV_DIR_ADDR)
+				addr ^= 1;
+			msg->addr = addr >> 1;
+			id->msg = msg;
+		}
+		retr = adap->retries;
+
+retry:
+		id->flags = ((i == (num-1)) ? IDF_STOP : 0);
+		id->status = 0;
+		init_completion(&id->xfer_done);
+
+		if (addr & 1)
+			sh7760_i2c_mrecv(id);
+		else
+			sh7760_i2c_msend(id);
+
+		wait_for_completion(&id->xfer_done);
+
+		if (id->status == 0) {
+			num = -EIO;
+			break;
+		}
+
+		if (id->status & IDS_NACK) {
+			/* little delay. Without it, subsequent transfers
+			 * hang the i2c ctl... */
+			mdelay(1);
+			num = -EREMOTEIO;
+			break;
+		}
+
+		if (id->status & IDS_ARBLOST) {
+			if (retr--) {
+				mdelay(2);
+				goto retry;
+			}
+			num = -EREMOTEIO;
+			break;
+		}
+
+		/* message successfully processed. YAY! */
+		msg++;
+		i++;
+	}
+
+	id->msg = NULL;
+	id->flags = 0;
+	id->status = 0;
+
+	OUT32(id, I2CMCR, 0);
+	OUT32(id, I2CMSR, 0);
+	OUT32(id, I2CMIER, 0);
+	OUT32(id, I2CFIER, 0);
+
+	/* important: reset slave regs too: master mode enables slave
+	 * module for receive ops (ack, data). Without this reset,
+	 * eternal bus activity might be reported after NACK / ARBLOST.
+	 */
+	OUT32(id, I2CSCR, 0);
+	OUT32(id, I2CSAR, 0);
+	OUT32(id, I2CSSR, 0);
+
+	return num;
+}
+
+static u32 sh7760_i2c_func(struct i2c_adapter *adap)
+{
+	struct cami2c *id = adap->algo_data;
+	return id->func;
+}
+
+static struct i2c_algorithm sh7760_i2c_algo = {
+	.master_xfer	= sh7760_i2c_master_xfer,
+	.functionality	= sh7760_i2c_func,
+};
+
+/* calculate CCR register setting for a desired scl clock */
+static int __devinit calc_CCR(unsigned long scl_freq)
+{
+	struct clk *mclk;
+	unsigned long mck, m1, dff, odff, iclk;
+	signed char cdf, cdfm = 0;
+	int scgd, scgdm;
+
+	mclk = clk_get(NULL, "module_clk");
+	if (!mclk) {
+		mck = CONFIG_SH_PCLK_FREQ;
+	} else {
+		mck = mclk->rate;
+		clk_put(mclk);
+	}
+
+	/* pclock -> CDF -> i2c_module clock (iclk) -> SCGD -> SCL */
+	odff = scl_freq;
+	scgdm = cdfm = m1 = 0;
+	for (cdf = 3; cdf >= 0; cdf--) {
+		iclk = mck / (1 + cdf);
+		/* iclk must not be > 20MHz */
+		if (iclk >= 20000000)
+			continue;
+		for (scgd = 0; scgd < 63; scgd++) {
+			m1 = iclk / (20 + (scgd << 3));
+			dff = abs(scl_freq - m1);
+			if (dff < odff) {
+				odff = dff;
+				cdfm = cdf;
+				scgdm = scgd;
+			}
+		}
+	}
+	/* create a CCR register value */
+	m1 = ((scgdm & 63) << 2) | (cdfm & 3);
+
+	return m1;
+}
+
+/* register a channel with the i2c core */
+static int __devinit sh7760_i2c_probe(struct platform_device *pdev)
+{
+	struct sh7760_i2c_platdata *pd;
+	struct resource *res;
+	struct cami2c *id;
+	int ret;
+
+	pd = pdev->dev.platform_data;
+	if (!pd) {
+		dev_err(&pdev->dev, "no platform_data!\n");
+		ret = -ENODEV;
+		goto out0;
+	}
+
+	id = kzalloc(sizeof(struct cami2c), GFP_KERNEL);
+	if (!id) {
+		ret = -ENOMEM;
+		goto out0;
+	}
+
+	ret = -ENODEV;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		goto out1;
+
+	id->iobase = (void __iomem *)res->start;
+	id->irq = platform_get_irq(pdev, 0);
+	id->chan = pdev->id;
+	id->func = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+	if (pd->noquick)
+		id->func &= ~I2C_FUNC_SMBUS_QUICK;
+
+	id->adap.algo	= &sh7760_i2c_algo;
+	id->adap.class	= I2C_CLASS_ALL;
+	id->adap.timeout	= 100;
+	id->adap.retries	= 3;
+	id->adap.algo_data	= id;
+	id->adap.dev.parent	= &pdev->dev;
+	strcpy(id->adap.name, SH7760_I2C_DEVNAME);
+
+	OUT32(id, I2CMCR, 0);
+	OUT32(id, I2CMSR, 0);
+	OUT32(id, I2CMIER, 0);
+	OUT32(id, I2CMAR, 0);
+	OUT32(id, I2CSIER, 0);
+	OUT32(id, I2CSAR, 0);
+	OUT32(id, I2CSCR, 0);
+	OUT32(id, I2CSSR, 0);
+	OUT32(id, I2CFIER, 0);
+	OUT32(id, I2CFCR, FCR_RFRST | FCR_TFRST);
+	OUT32(id, I2CFSR, 0);
+	OUT32(id, I2CCCR, calc_CCR(pd->speed_khz * 1000));
+
+	if (request_irq(id->irq, sh7760_i2c_irq, IRQF_DISABLED,
+				SH7760_I2C_DEVNAME, id)) {
+		dev_err(&pdev->dev, "cannot get irq %d\n", id->irq);
+		ret = -ENODEV;
+		goto out1;
+	}
+
+	ret = i2c_add_adapter(&id->adap);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "i2c_add_adapter failed: %d\n", ret);
+		goto out2;
+	}
+
+	platform_set_drvdata(pdev, id);
+
+	printk(KERN_INFO "SH7760 I2C-%d, %d kHz, mmio %p, irq %d\n",
+		id->chan, pd->speed_khz, id->iobase, id->irq);
+
+	return 0;
+
+out2:	free_irq(id->irq, (void *)id);
+out1:	kfree(id);
+out0:	return ret;
+}
+
+static int __devexit sh7760_i2c_remove(struct platform_device *pdev)
+{
+	struct cami2c *id = platform_get_drvdata(pdev);
+
+	if (id) {
+		i2c_del_adapter(&id->adap);
+		free_irq(id->irq, (void *)id);
+		kfree(id);
+	}
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver sh7760_i2c_drv = {
+	.driver	= {
+		.name	= SH7760_I2C_DEVNAME,
+		.owner	= THIS_MODULE,
+	},
+	.probe		= sh7760_i2c_probe,
+	.remove		= __devexit_p(sh7760_i2c_remove),
+};
+
+static int __init sh7760_i2c_init(void)
+{
+	return platform_driver_register(&sh7760_i2c_drv);
+}
+
+static void __exit sh7760_i2c_exit(void)
+{
+	platform_driver_unregister(&sh7760_i2c_drv);
+}
+
+module_init(sh7760_i2c_init);
+module_exit(sh7760_i2c_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("SH7760 I2C bus driver");
+MODULE_AUTHOR("Manuel Lauss <ma...@ro...>");
diff --git a/include/asm-sh/i2c-sh7760.h b/include/asm-sh/i2c-sh7760.h
new file mode 100644
index 0000000..d2a86bd
--- /dev/null
+++ b/include/asm-sh/i2c-sh7760.h
@@ -0,0 +1,23 @@
+/*
+ * MMIO/IRQ and platform data for SH7760 I2C channels
+ */
+
+#ifndef _I2C_SH7760_H_
+#define _I2C_SH7760_H_
+
+#define SH7760_I2C_DEVNAME	"i2c-sh7760"
+
+#define SH7760_I2C0_MMIO	0xFE140000
+#define SH7760_I2C0_MMIOEND	0xFE14003B
+#define SH7760_I2C0_IRQ		62
+
+#define SH7760_I2C1_MMIO	0xFE150000
+#define SH7760_I2C1_MMIOEND	0xFE15003B
+#define SH7760_I2C1_IRQ		63
+
+struct sh7760_i2c_platdata {
+	unsigned int speed_khz;
+	unsigned int noquick;
+};
+
+#endif
-- 
1.5.3.4

Re: git

[Paul M. <le...@li...>]

On Wed, Oct 24, 2007 at 11:41:38PM +0100, Adrian McMenamin wrote:
> On Wed, 2007-10-24 at 20:35 +0100, Adrian McMenamin wrote:
> > I have been hosting my SH stuff on CVS so far. It is just a place where
> > I can go to when I need to roll back mistakes, though it is also public
> > on the web for a variety of reasons, not least because it allows me to
> > look at the sources in a browser when away from home.
> > 
> > I'd like to move to doing this with git - anyone care to recommend a git
> > web interface as there appear to be a few of them around.
> 
> OK. There is a server now at git://newgolddream.dyndns.info/ though I am
> having a lot of problems getting gitweb to work.
> 
I also have an outdated gitweb on linux-sh.org, I can get that fixed up
if you'd prefer to use that directly.

> As an aside: was really surprised at how hard git hammers on the
> server's resources.
> 
You just need enough RAM to fit the working set in page cache, then the
problem works itself out ;-)

Re: [patch 2/2] Use BOOTMEM_EXCLUSIVE for kdump

[Paul M. <le...@li...>]

On Wed, Oct 24, 2007 at 09:05:33PM -0700, Andrew Morton wrote:
> On Wed, 24 Oct 2007 18:37:35 +0200 Bernhard Walle <bw...@su...> wrote:
> > This patch uses the BOOTMEM_EXCLUSIVE, introduced in the previous patch,
> > to avoid conflicts while reserving the memory for the kdump carpture kernel
> > (crashkernel=).
> > 
> > Signed-off-by: Bernhard Walle <bw...@su...>
> > 
> > ---
> >  arch/sh/kernel/setup.c     |   29 ++++++++++++++++++-----------
> >  arch/x86/kernel/setup_32.c |   28 ++++++++++++++++++----------
> >  arch/x86/kernel/setup_64.c |   35 +++++++++++++++++++++--------------
> 
> ia64 and powerpc support crash dump too?
> 
Not via a reserved bootmem area at least, which is what these patches
touch.

Acked-by: Paul Mundt <le...@li...>