* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
@ 2008-08-27 11:12 ` Manuel Lauss
2008-08-27 14:55 ` Paul Mundt
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Manuel Lauss @ 2008-08-27 11:12 UTC (permalink / raw)
To: linux-sh
Hi Luca,
On Wed, Aug 27, 2008 at 12:34:48PM +0200, Luca Santini wrote:
> currently you have (defconfig) :
>
> - ramdisk support
> - ethernet support
> - nfs support
> - ext2/ext3 support
> - i2c support
> - fb support (M)
>
> and haven't:
>
> - usb support
> - mmc support
I have drivers for both, although the USB part is definitely NOT mainline
material at all (it's basically a duplication of the OHCI stack with a few
adjustments and a memory manager for the 7760 ohci ram.)
> - flash support?
look e.g. at the ap325rxa boards' use of the physmap-flash driver.
> diff -uNr -x '*.mod.c' -x '*.o' -x '*.cmd' -x '*.d' -x 'built-in.*' -x '*.S' -x '*.s' -x 'vmlinux*' -x zImage -x '*syscall*' a/arch/sh/boards/renesas/edosk7760/Makefile b/arch/sh/boards/renesas/edosk7760/Makefile
> --- a/arch/sh/boards/renesas/edosk7760/Makefile 1970-01-01 01:00:00.000000000 +0100
> +++ b/arch/sh/boards/renesas/edosk7760/Makefile 2008-08-27 11:45:29.000000000 +0200
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for HMSE EDOSK7760 board specific parts of the kernel
> +#
> +# Note! Dependencies are done automagically by 'make dep', which also
> +# removes any old dependencies. DON'T put your own dependencies here
> +# unless it's something special (ie not a .c file).
> +#
> +
> +obj-y := setup.o
as long as the code consists of a single setup.c file, just rename it to
> diff -uNr -x '*.mod.c' -x '*.o' -x '*.cmd' -x '*.d' -x 'built-in.*' -x '*.S' -x '*.s' -x 'vmlinux*' -x zImage -x '*syscall*' a/arch/sh/boards/renesas/edosk7760/setup.c b/arch/sh/boards/renesas/edosk7760/setup.c
> --- a/arch/sh/boards/renesas/edosk7760/setup.c 1970-01-01 01:00:00.000000000 +0100
> +++ b/arch/sh/boards/renesas/edosk7760/setup.c 2008-08-27 12:01:58.000000000 +0200
> @@ -0,0 +1,177 @@
> +/*
> + * linux/arch/sh/edosk7760/setup.c
> + *
> + * Copyright (C) 2000 Kazumoto Kojima
> + *
> + *
> + * Modified for EDOSK7760 by
> + * Richard Bister
> + *
> + * Port to 2.6.26 by
> + * Luca Santini www.spesonline.com
> + */
> +
> +/* Bus state controller registers for CS4 area */
> +#define BSC_CS4BCR 0xA4FD0010
> +#define BSC_CS4WCR 0xA4FD0030
> +
> +#define SMC_IOBASE 0xA2000000
> +#define SMC_IO_OFFSET 0x300
> +#define SMC_IOADDR SMC_IOBASE + SMC_IO_OFFSET
> +#define ETHERNET_IRQ 0x9
> +
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/platform_device.h>
> +#include <asm/machvec.h>
> +#include <asm/io.h>
> +#include <asm/addrspace.h>
> +#include <asm/delay.h>
> +#include <linux/smc91x.h>
> +#include <linux/i2c.h>
> +#include <asm/i2c-sh7760.h>
Please reorder the includes: lines with linux/ come first, followed by
asm/.
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
should not be necessary. If the driver is not selected, the resources won't
do any harm (consume a few bytes of ram maybe).
> +/* i2c initialization functions */
> +
> +static struct sh7760_i2c_platdata i2c_pd = {
> + .speed_khz = 400,
> +};
> +
> +static struct resource sh7760_i2c1_res[] = {
> + {
> + .start = SH7760_I2C1_MMIO,
> + .end = SH7760_I2C1_MMIOEND,
> + .flags = IORESOURCE_MEM,
> + },{
> + .start = SH7760_I2C1_IRQ,
> + .end = SH7760_I2C1_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device sh7760_i2c1_dev = {
> + .dev = {
> + .platform_data = &i2c_pd,
> + },
> + .name = SH7760_I2C_DEVNAME,
> + .id = 1,
> + .resource = sh7760_i2c1_res,
> + .num_resources = ARRAY_SIZE(sh7760_i2c1_res),
> +};
> +
> +
> +static struct resource sh7760_i2c0_res[] = {
> + {
> + .start = SH7760_I2C0_MMIO,
> + .end = SH7760_I2C0_MMIOEND,
> + .flags = IORESOURCE_MEM,
> + },{
> + .start = SH7760_I2C0_IRQ,
> + .end = SH7760_I2C0_IRQ,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device sh7760_i2c0_dev = {
> + .dev = {
> + .platform_data = &i2c_pd,
> + },
> + .name = SH7760_I2C_DEVNAME,
> + .id = 0,
> + .resource = sh7760_i2c0_res,
> + .num_resources = ARRAY_SIZE(sh7760_i2c0_res),
> +};
> +#endif
> +
> +static void __init sh_edosk7760_init_irq(void)
> +{
> +
> +}
Empty function -- get rid of it.
> +/* eth initialization functions */
> +
> +static struct smc91x_platdata smc91x_info = {
> + .flags = SMC91X_USE_16BIT,
> +};
> +
> +static struct resource smc91x_res[] = {
> + [0] = {
> + .start = SMC_IOADDR,
> + .end = SMC_IOADDR + 0x1f,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = ETHERNET_IRQ,
> + .end = ETHERNET_IRQ,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
> +
> +static struct platform_device smc91x_dev = {
> +
> + .name = "smc91x",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(smc91x_res),
> + .resource = smc91x_res,
> + .dev = {
> + .platform_data = &smc91x_info,
> + },
> +
> +};
> +
> +/* platform init code */
> +
> +static struct platform_device *edosk7760_devices[] __initdata = {
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
These checks are unnecessary, remove them.
> + &sh7760_i2c0_dev,
> + &sh7760_i2c1_dev,
> +#endif
> +
> +#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
> + &smc91x_dev,
> +#endif
> +
> +};
> +
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> +/*these are custom-board specific: here you can add your I2C_BOARD_INFO devices*/
> +static struct i2c_board_info __initdata edosk7760_i2c_devices0[] = {
> +};
> +
> +static struct i2c_board_info __initdata edosk7760_i2c_devices1[] = {
> +};
> +#endif
As long as they're empty, remove them. You can add them back later when you
have the WM8731 working ;) (incidentally, Jean Delvare posted a patch to
alsa-devel with converts the wm8731 codec to new-style i2c probing on
080826).
> +static int __init init_edosk7760_devices(void){
> + int ret = -1;
> +
> + /* This is the Ethernet interrupt */
> + make_imask_irq(ETHERNET_IRQ);
> +
> + /* This is the IntelStrata Flash interrupt */
> + make_imask_irq(0x0A);
> +
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> + /* i2c setup */
> + i2c_register_board_info(0, edosk7760_i2c_devices0,
> + ARRAY_SIZE(edosk7760_i2c_devices0));
> + i2c_register_board_info(1, edosk7760_i2c_devices1,
> + ARRAY_SIZE(edosk7760_i2c_devices1));
> +#endif
> +
> + ret = platform_add_devices(edosk7760_devices, ARRAY_SIZE(edosk7760_devices));
> + return ret;
> +}
> +__initcall(init_edosk7760_devices);
> +
> +/*
> + * The Machine Vector
> + */
> +
> +/// have a look to include/asm-sh/machvec.h
> +struct sh_machine_vector mv_edosk7760 __initmv = {
> + mv_name: "EDOSK7760",
> + mv_nr_irqs: 128,
> + mv_init_irq: sh_edosk7760_init_irq,
> +};
Please use the new initializer syntax:
.mv_name = "EDOSK7760",
.mv_nr_irqs = 128,
.mv_init_irq = edosk7760_init_irq,
Also, please rediff against a more current linux source tree.
Since 2.6.27-rc2 or so, the board file organization has changed slightly; as
long as you only have the setup.c file, I suggest you rename it to
mach-edosk7760.c and wire it up in arch/sh/boards/Makefile.
Best regards,
Manuel Lauss
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
2008-08-27 11:12 ` Manuel Lauss
@ 2008-08-27 14:55 ` Paul Mundt
2008-08-28 3:00 ` Paul Mundt
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Paul Mundt @ 2008-08-27 14:55 UTC (permalink / raw)
To: linux-sh
A few notes in addition to what Manuel said:
On Wed, Aug 27, 2008 at 01:12:29PM +0200, Manuel Lauss wrote:
> > diff -uNr -x '*.mod.c' -x '*.o' -x '*.cmd' -x '*.d' -x 'built-in.*' -x '*.S' -x '*.s' -x 'vmlinux*' -x zImage -x '*syscall*' a/arch/sh/boards/renesas/edosk7760/setup.c b/arch/sh/boards/renesas/edosk7760/setup.c
> > --- a/arch/sh/boards/renesas/edosk7760/setup.c 1970-01-01 01:00:00.000000000 +0100
> > +++ b/arch/sh/boards/renesas/edosk7760/setup.c 2008-08-27 12:01:58.000000000 +0200
> > @@ -0,0 +1,177 @@
> > +/*
> > + * linux/arch/sh/edosk7760/setup.c
> > + *
> > + * Copyright (C) 2000 Kazumoto Kojima
> > + *
> > + *
> > + * Modified for EDOSK7760 by
> > + * Richard Bister
> > + *
> > + * Port to 2.6.26 by
> > + * Luca Santini www.spesonline.com
> > + */
> > +
Please get your copyright notices fixed, and actually toss a license stub
in there. I can gaurantee you that Kojima-san had nothing to do with this
platform in 2000, especially as Camelot silicon didn't begin sampling
before Q1 2003.
Also, drop the path from the comment. Even now it's not even accurate,
which goes to show how useful that bit of information is.
> > +static struct smc91x_platdata smc91x_info = {
> > + .flags = SMC91X_USE_16BIT,
> > +};
> > +
For some reason your flags here and your later smc91x patch for edosk7760
have absolutely nothing in common. This leads me to believe that you
either couldn't get the dynamic configuration working, in which case this
bit of code is useless, or that it works fine and there's no need for the
changes to smc91x.h. If you need both, you are doing something very
wrong.
> > +static int __init init_edosk7760_devices(void){
The { should be on a line by itself.
> > + int ret = -1;
> > +
Pointless initialization and unused variable.
> > +/// have a look to include/asm-sh/machvec.h
C++ comments have no place in the kernel. Just because C99 dropped the
ball doesn't mean we have to perpetuate this idiocy in-tree. The header
location is also different these days, and the comment itself is of
questionable use. If someone can't work out to look at machvec.h for
these definitions, they probably shouldn't be touching the machine vector
in the first place.
> Also, please rediff against a more current linux source tree.
> Since 2.6.27-rc2 or so, the board file organization has changed slightly; as
> long as you only have the setup.c file, I suggest you rename it to
> mach-edosk7760.c and wire it up in arch/sh/boards/Makefile.
>
Indeed. Please always diff against a current kernel. diffing against
2.6.26 at this late in the 2.6.27 cycle is an act of futility.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
2008-08-27 11:12 ` Manuel Lauss
2008-08-27 14:55 ` Paul Mundt
@ 2008-08-28 3:00 ` Paul Mundt
2008-08-28 11:50 ` Magnus Damm
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Paul Mundt @ 2008-08-28 3:00 UTC (permalink / raw)
To: linux-sh
On Wed, Aug 27, 2008 at 06:32:02PM +0200, Luca Santini wrote:
> Paul Mundt wrote:
> >On Wed, Aug 27, 2008 at 01:12:29PM +0200, Manuel Lauss wrote:
> >>>diff -uNr -x '*.mod.c' -x '*.o' -x '*.cmd' -x '*.d' -x 'built-in.*' -x
> >>>'*.S' -x '*.s' -x 'vmlinux*' -x zImage -x '*syscall*'
> >>>a/arch/sh/boards/renesas/edosk7760/setup.c
> >>>b/arch/sh/boards/renesas/edosk7760/setup.c
> >>>--- a/arch/sh/boards/renesas/edosk7760/setup.c 1970-01-01
> >>>01:00:00.000000000 +0100
> >>>+++ b/arch/sh/boards/renesas/edosk7760/setup.c 2008-08-27
> >>>12:01:58.000000000 +0200
> >>>@@ -0,0 +1,177 @@
> >>>+/*
> >>>+ * linux/arch/sh/edosk7760/setup.c
> >>>+ *
> >>>+ * Copyright (C) 2000 Kazumoto Kojima
> >>>+ *
> >>>+ *
> >>>+ * Modified for EDOSK7760 by
> >>>+ * Richard Bister
> >>>+ *
> >>>+ * Port to 2.6.26 by
> >>>+ * Luca Santini www.spesonline.com
> >>>+ */
> >>>+
> >Please get your copyright notices fixed, and actually toss a license stub
> >in there. I can gaurantee you that Kojima-san had nothing to do with this
> >platform in 2000, especially as Camelot silicon didn't begin sampling
> >before Q1 2003.
> >
>
> i've no idea what to write here....
>
What does your company usually use as a copyright?
Look at things like arch/sh/boards/mach-rsk7203.c as an example.
> >>>+static struct smc91x_platdata smc91x_info = {
> >>>+ .flags = SMC91X_USE_16BIT,
> >>>+};
> >>>+
> >For some reason your flags here and your later smc91x patch for edosk7760
> >have absolutely nothing in common. This leads me to believe that you
> >either couldn't get the dynamic configuration working, in which case this
> >bit of code is useless, or that it works fine and there's no need for the
> >changes to smc91x.h. If you need both, you are doing something very
> >wrong.
> >
>
> you're right; what i really need is
>
> #define SMC_IO_SHIFT 1
>
> but using the platdata flag
>
> SMC91X_IO_SHIFT_1
>
> doesn't work.
>
Ok, so that's a real bug then. Magnus, can you take a look at this?
> >Indeed. Please always diff against a current kernel. diffing against
> >2.6.26 at this late in the 2.6.27 cycle is an act of futility.
>
> i'm cloning current git repository.
> i was thinking the "current" kernel was 2.6.26
>
Current git is always preferable for patches, as the rate of change is
very high during the initial merge window.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (2 preceding siblings ...)
2008-08-28 3:00 ` Paul Mundt
@ 2008-08-28 11:50 ` Magnus Damm
2008-08-29 8:35 ` Luca Santini
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-08-28 11:50 UTC (permalink / raw)
To: linux-sh
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On Thu, Aug 28, 2008 at 12:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Wed, Aug 27, 2008 at 06:32:02PM +0200, Luca Santini wrote:
>> >>>+static struct smc91x_platdata smc91x_info = {
>> >>>+ .flags = SMC91X_USE_16BIT,
>> >>>+};
>> >>>+
>> >For some reason your flags here and your later smc91x patch for edosk7760
>> >have absolutely nothing in common. This leads me to believe that you
>> >either couldn't get the dynamic configuration working, in which case this
>> >bit of code is useless, or that it works fine and there's no need for the
>> >changes to smc91x.h. If you need both, you are doing something very
>> >wrong.
>> >
>>
>> you're right; what i really need is
>>
>> #define SMC_IO_SHIFT 1
>>
>> but using the platdata flag
>>
>> SMC91X_IO_SHIFT_1
>>
>> doesn't work.
>>
> Ok, so that's a real bug then. Magnus, can you take a look at this?
The io shift platform data configuration should be generic, but it
looks like it has been fully hooked in by some ARM platforms only at
this point. Someone forgot to fix the generic case. Try the attached
patch, that should get you going. Let me know if it solves your issue.
/ magnus
[-- Attachment #2: linux-2.6.27-rc-smc91x-platform-data-io-shift-20080828.patch --]
[-- Type: application/octet-stream, Size: 374 bytes --]
--- 0001/drivers/net/smc91x.h
+++ work/drivers/net/smc91x.h 2008-08-28 20:43:03.000000000 +0900
@@ -446,6 +446,8 @@ static inline void LPD7_SMC_outsw (unsig
#define SMC_CAN_USE_32BIT 1
#define SMC_NOWAIT 1
+#define SMC_IO_SHIFT (lp->io_shift)
+
#define SMC_inb(a, r) readb((a) + (r))
#define SMC_inw(a, r) readw((a) + (r))
#define SMC_inl(a, r) readl((a) + (r))
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (3 preceding siblings ...)
2008-08-28 11:50 ` Magnus Damm
@ 2008-08-29 8:35 ` Luca Santini
2008-09-01 1:24 ` Magnus Damm
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Luca Santini @ 2008-08-29 8:35 UTC (permalink / raw)
To: linux-sh
For some reason,
i have trouble in switching from .26 to .27-rc4;
it seems i have problems in irq masking (for the smc eth chip);
now kernel/irq/manage.c outputs
[ 1.462932] No set_type function for IRQ 9 (SR.IMASK)
and after initialization, when nfs boot starts
([ 3.105886] Looking up port of RPC 100003/2 on 10.193.101.100)
i get a seems-infinite loop of
[ 3.115338] irq 9, desc: 8c238aec, depth: 0, count: 0, unhandled: 0
[ 3.117228] ->handle_irq(): 8c0361d8, handle_bad_irq+0x0/0x1ac
[ 3.123100] ->chip(): 8c236318, imask_irq_type+0x0/0x40
[ 3.128284] ->action(): 8f9307e0
[ 3.131482] ->action->handler(): 8c10dc98, smc_interrupt+0x0/0xbe4
[ 3.137620] unexpected IRQ trap at vector 09
something has changed in .27 in irq management?
Luca Santini
Magnus Damm wrote:
> On Thu, Aug 28, 2008 at 12:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>> On Wed, Aug 27, 2008 at 06:32:02PM +0200, Luca Santini wrote:
>>>>>> +static struct smc91x_platdata smc91x_info = {
>>>>>> + .flags = SMC91X_USE_16BIT,
>>>>>> +};
>>>>>> +
>>>> For some reason your flags here and your later smc91x patch for edosk7760
>>>> have absolutely nothing in common. This leads me to believe that you
>>>> either couldn't get the dynamic configuration working, in which case this
>>>> bit of code is useless, or that it works fine and there's no need for the
>>>> changes to smc91x.h. If you need both, you are doing something very
>>>> wrong.
>>>>
>>> you're right; what i really need is
>>>
>>> #define SMC_IO_SHIFT 1
>>>
>>> but using the platdata flag
>>>
>>> SMC91X_IO_SHIFT_1
>>>
>>> doesn't work.
>>>
>> Ok, so that's a real bug then. Magnus, can you take a look at this?
>
> The io shift platform data configuration should be generic, but it
> looks like it has been fully hooked in by some ARM platforms only at
> this point. Someone forgot to fix the generic case. Try the attached
> patch, that should get you going. Let me know if it solves your issue.
>
> / magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (4 preceding siblings ...)
2008-08-29 8:35 ` Luca Santini
@ 2008-09-01 1:24 ` Magnus Damm
2008-09-01 8:11 ` Luca Santini
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-01 1:24 UTC (permalink / raw)
To: linux-sh
On Fri, Aug 29, 2008 at 5:35 PM, Luca Santini
<luca.santini@spesonline.com> wrote:
> For some reason,
> i have trouble in switching from .26 to .27-rc4;
>
> it seems i have problems in irq masking (for the smc eth chip);
> now kernel/irq/manage.c outputs
>
> [ 1.462932] No set_type function for IRQ 9 (SR.IMASK)
>
> and after initialization, when nfs boot starts
> ([ 3.105886] Looking up port of RPC 100003/2 on 10.193.101.100)
> i get a seems-infinite loop of
>
> [ 3.115338] irq 9, desc: 8c238aec, depth: 0, count: 0, unhandled: 0
> [ 3.117228] ->handle_irq(): 8c0361d8, handle_bad_irq+0x0/0x1ac
> [ 3.123100] ->chip(): 8c236318, imask_irq_type+0x0/0x40
> [ 3.128284] ->action(): 8f9307e0
> [ 3.131482] ->action->handler(): 8c10dc98, smc_interrupt+0x0/0xbe4
> [ 3.137620] unexpected IRQ trap at vector 09
>
> something has changed in .27 in irq management?
I don't think so. Are you sure about the value 9 for IRQ?
Since there is no external interrupt controller code I assume the SMC
chip is connected directly to the processor. I would guess using pin
IRQ4, IRQ5, IRQ6 or IRQ7. Try using interrupt numbers from 48 (IRQ4)
to 51 (IRQ7) and see if that helps!
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (5 preceding siblings ...)
2008-09-01 1:24 ` Magnus Damm
@ 2008-09-01 8:11 ` Luca Santini
2008-09-05 8:14 ` Magnus Damm
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Luca Santini @ 2008-09-01 8:11 UTC (permalink / raw)
To: linux-sh
thanks for reply Magnus,
in 2.6.26 everything works fine with irq 9;
trying to debug a little kernel/irq/manage.c i found that
in 2.6.26 in function setup_irq()
compat_irq_chip_set_default_handler(desc);
is called;
otherwise in 2.6.27-rc4 :
__irq_set_trigger()
is called with
chip->set_type = NULL
i tried (for debug) to force in smc91x.h
#define SMC_IRQ_FLAGS 0
to force using compat_irq_chip_set_default_handler(desc);
but what i get is a loop of
"Unable to handle kernel NULL pointer dereference..."
i'll try your suggestion!
Magnus Damm wrote:
> On Fri, Aug 29, 2008 at 5:35 PM, Luca Santini
> <luca.santini@spesonline.com> wrote:
>> For some reason,
>> i have trouble in switching from .26 to .27-rc4;
>>
>> it seems i have problems in irq masking (for the smc eth chip);
>> now kernel/irq/manage.c outputs
>>
>> [ 1.462932] No set_type function for IRQ 9 (SR.IMASK)
>>
>> and after initialization, when nfs boot starts
>> ([ 3.105886] Looking up port of RPC 100003/2 on 10.193.101.100)
>> i get a seems-infinite loop of
>>
>> [ 3.115338] irq 9, desc: 8c238aec, depth: 0, count: 0, unhandled: 0
>> [ 3.117228] ->handle_irq(): 8c0361d8, handle_bad_irq+0x0/0x1ac
>> [ 3.123100] ->chip(): 8c236318, imask_irq_type+0x0/0x40
>> [ 3.128284] ->action(): 8f9307e0
>> [ 3.131482] ->action->handler(): 8c10dc98, smc_interrupt+0x0/0xbe4
>> [ 3.137620] unexpected IRQ trap at vector 09
>>
>> something has changed in .27 in irq management?
>
> I don't think so. Are you sure about the value 9 for IRQ?
>
> Since there is no external interrupt controller code I assume the SMC
> chip is connected directly to the processor. I would guess using pin
> IRQ4, IRQ5, IRQ6 or IRQ7. Try using interrupt numbers from 48 (IRQ4)
> to 51 (IRQ7) and see if that helps!
>
> / magnus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (6 preceding siblings ...)
2008-09-01 8:11 ` Luca Santini
@ 2008-09-05 8:14 ` Magnus Damm
2008-09-05 8:14 ` Luca Santini
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-05 8:14 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 1, 2008 at 5:11 PM, Luca Santini
<luca.santini@spesonline.com> wrote:
> thanks for reply Magnus,
> in 2.6.26 everything works fine with irq 9;
I see that you install imask handlers for the flash and the ethernet:
+static int __init init_edosk7760_devices(void){
+ int ret = -1;
+
+ /* This is the Ethernet interrupt */
+ make_imask_irq(ETHERNET_IRQ);
+
+ /* This is the IntelStrata Flash interrupt */
+ make_imask_irq(0x0A);
Is the flash interrupt tested?
I suspect that the chips are connected straight to the IRL pins of the
processor. Using "individual interrupt mode" would make sense then. Do
you have access to schematics?
I recommend you to enable "individual interrupt mode" calling
plat_irq_setup_pins(IRQ_MODE_IRQ) from your board code. Try using
interrupt number 2 for IRL0 pin, 5 for IRL1, 8 for IRL2 and 11 for
IRL3. These values are calculated from vectors_irq[] in
setup-sh7760.c.
> trying to debug a little kernel/irq/manage.c i found that
> in 2.6.26 in function setup_irq()
>
> compat_irq_chip_set_default_handler(desc);
>
> is called;
>
> otherwise in 2.6.27-rc4 :
>
> __irq_set_trigger()
>
> is called with
> chip->set_type = NULL
>
>
> i tried (for debug) to force in smc91x.h
> #define SMC_IRQ_FLAGS 0
> to force using compat_irq_chip_set_default_handler(desc);
> but what i get is a loop of
>
> "Unable to handle kernel NULL pointer dereference..."
This may be because the imask interrupt controller code doesn't
support interrupt type or something. I'm not sure.
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (7 preceding siblings ...)
2008-09-05 8:14 ` Magnus Damm
@ 2008-09-05 8:14 ` Luca Santini
2008-09-05 8:17 ` Magnus Damm
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Luca Santini @ 2008-09-05 8:14 UTC (permalink / raw)
To: linux-sh
Hi Magnus,
sorry for my late...
Yes, i think the patch works in 2.6.27-rcX kernel (addresses are fine
and the chip detected) but i have the irq masking problem that i'm
unable to resolve(my ignorance... i can't imagine what else to use than
make_imask_irq() - i tried your suggestion masking ALSO irqs from 48
to 52 but with no result; i repeat, in .26 masking irq 9 works and in
kernel/irq/manage.c compat_irq_chip_set_default_handler() is called;
otherwise in .27 the function called is __irq_set_trigger(), but with
chip->set_type = NULL), so my .27 kernel won't work in NFS and i can't
say i'm 100% sure it works completely.
(in .26 it don't work because of the lack of 'lp' structure... )
p.s.: a little question git-related... (i'm moving my first steps with
git..) :
if i pull from
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
it asks for a password.... ???
currently, i pull from
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git
is it the same?
Magnus Damm wrote:
> Hi Luca,
>
> On Thu, Aug 28, 2008 at 8:50 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>> On Thu, Aug 28, 2008 at 12:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
>>> On Wed, Aug 27, 2008 at 06:32:02PM +0200, Luca Santini wrote:
>>>>>>> +static struct smc91x_platdata smc91x_info = {
>>>>>>> + .flags = SMC91X_USE_16BIT,
>>>>>>> +};
>>>>>>> +
>>>>> For some reason your flags here and your later smc91x patch for edosk7760
>>>>> have absolutely nothing in common. This leads me to believe that you
>>>>> either couldn't get the dynamic configuration working, in which case this
>>>>> bit of code is useless, or that it works fine and there's no need for the
>>>>> changes to smc91x.h. If you need both, you are doing something very
>>>>> wrong.
>>>>>
>>>> you're right; what i really need is
>>>>
>>>> #define SMC_IO_SHIFT 1
>>>>
>>>> but using the platdata flag
>>>>
>>>> SMC91X_IO_SHIFT_1
>>>>
>>>> doesn't work.
>>>>
>>> Ok, so that's a real bug then. Magnus, can you take a look at this?
>> The io shift platform data configuration should be generic, but it
>> looks like it has been fully hooked in by some ARM platforms only at
>> this point. Someone forgot to fix the generic case. Try the attached
>> patch, that should get you going. Let me know if it solves your issue.
>
> Did the patch help?
>
> Thanks,
>
> / magnus
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (8 preceding siblings ...)
2008-09-05 8:14 ` Luca Santini
@ 2008-09-05 8:17 ` Magnus Damm
2008-09-05 8:30 ` Magnus Damm
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-05 8:17 UTC (permalink / raw)
To: linux-sh
On Fri, Sep 5, 2008 at 5:14 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Mon, Sep 1, 2008 at 5:11 PM, Luca Santini
> <luca.santini@spesonline.com> wrote:
>> thanks for reply Magnus,
>> in 2.6.26 everything works fine with irq 9;
>
> I see that you install imask handlers for the flash and the ethernet:
>
> +static int __init init_edosk7760_devices(void){
> + int ret = -1;
> +
> + /* This is the Ethernet interrupt */
> + make_imask_irq(ETHERNET_IRQ);
> +
> + /* This is the IntelStrata Flash interrupt */
> + make_imask_irq(0x0A);
>
> Is the flash interrupt tested?
>
> I suspect that the chips are connected straight to the IRL pins of the
> processor. Using "individual interrupt mode" would make sense then. Do
> you have access to schematics?
>
> I recommend you to enable "individual interrupt mode" calling
> plat_irq_setup_pins(IRQ_MODE_IRQ) from your board code. Try using
> interrupt number 2 for IRL0 pin, 5 for IRL1, 8 for IRL2 and 11 for
> IRL3. These values are calculated from vectors_irq[] in
> setup-sh7760.c.
I forgot to mention that you should remove the make_imask_irq() calls
if you want to try "individual interrupt mode" using
plat_irq_setup_pins()...
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (9 preceding siblings ...)
2008-09-05 8:17 ` Magnus Damm
@ 2008-09-05 8:30 ` Magnus Damm
2008-09-05 8:33 ` Manuel Lauss
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-05 8:30 UTC (permalink / raw)
To: linux-sh
Hi Luca,
On Fri, Sep 5, 2008 at 5:14 PM, Luca Santini
<luca.santini@spesonline.com> wrote:
> Hi Magnus,
> sorry for my late...
No worries!
> Yes, i think the patch works in 2.6.27-rcX kernel (addresses are fine and
> the chip detected) but i have the irq masking problem that i'm unable to
> resolve(my ignorance... i can't imagine what else to use than
> make_imask_irq() - i tried your suggestion masking ALSO irqs from 48 to 52
> but with no result; i repeat, in .26 masking irq 9 works and in
> kernel/irq/manage.c compat_irq_chip_set_default_handler() is called;
> otherwise in .27 the function called is __irq_set_trigger(), but with
> chip->set_type = NULL), so my .27 kernel won't work in NFS and i can't say
> i'm 100% sure it works completely.
Good that the smc91x-patch seems to work. Regarding the irq masking
stuff, sorry for not being more clear. I'm sure you could spend some
time and fix up the imask handler, but I wonder if you really want to
do that.
We should already support your processor out-of-the box (i think, i'm
still not sure how the interrupts are connected to your board) and
that without the need for any special imask handling code. I suspect
the imask handling code is just based on older kernels where we didn't
have the interrupt configuration that the intc controller and tables
provide today.
So, please begin with remove all calls to make_imask_irq(). Then, try
IRQ4 to IRQ7. If that doesn't work, enable "individual interrupt mode"
for IRL0 to IRL3. That makes them behave like individual interrupt
pins which is a good thing.
The folliwing sh7760-specific table shows which interrupt numbers you
should pass to request_irq() or use with IORESOURCE_IRQ.
IRL0 2
IRL1 5
IRL2 8
IRL3 11
IRQ4 48
IRQ5 49
IRQ6 50
IRQ7 51
Hope this helps!
> p.s.: a little question git-related... (i'm moving my first steps with
> git..) :
>
> if i pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
>
> it asks for a password.... ???
>
> currently, i pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git
>
> is it the same?
I'm not sure. I always use the git:// myself.
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (10 preceding siblings ...)
2008-09-05 8:30 ` Magnus Damm
@ 2008-09-05 8:33 ` Manuel Lauss
2008-09-05 8:46 ` Magnus Damm
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Manuel Lauss @ 2008-09-05 8:33 UTC (permalink / raw)
To: linux-sh
Hi Magnus,
On Fri, Sep 05, 2008 at 05:14:34PM +0900, Magnus Damm wrote:
> On Mon, Sep 1, 2008 at 5:11 PM, Luca Santini
> <luca.santini@spesonline.com> wrote:
> > thanks for reply Magnus,
> > in 2.6.26 everything works fine with irq 9;
>
> I see that you install imask handlers for the flash and the ethernet:
>
> +static int __init init_edosk7760_devices(void){
> + int ret = -1;
> +
> + /* This is the Ethernet interrupt */
> + make_imask_irq(ETHERNET_IRQ);
> +
> + /* This is the IntelStrata Flash interrupt */
> + make_imask_irq(0x0A);
>
> Is the flash interrupt tested?
>
> I suspect that the chips are connected straight to the IRL pins of the
> processor. Using "individual interrupt mode" would make sense then. Do
> you have access to schematics?
According to the schematics, 15 irqs are connected to a CPLD which creates
the 4bit IRL value. Unfortunately there is no way to individually mask them
in the CPLD itself (it has no databus connection).
MfG,
Manuel Lauss
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (11 preceding siblings ...)
2008-09-05 8:33 ` Manuel Lauss
@ 2008-09-05 8:46 ` Magnus Damm
2008-09-05 8:48 ` Paul Mundt
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-05 8:46 UTC (permalink / raw)
To: linux-sh
On Fri, Sep 5, 2008 at 5:33 PM, Manuel Lauss
<mano@roarinelk.homelinux.net> wrote:
> Hi Magnus,
>
> On Fri, Sep 05, 2008 at 05:14:34PM +0900, Magnus Damm wrote:
>> On Mon, Sep 1, 2008 at 5:11 PM, Luca Santini
>> <luca.santini@spesonline.com> wrote:
>> > thanks for reply Magnus,
>> > in 2.6.26 everything works fine with irq 9;
>>
>> I see that you install imask handlers for the flash and the ethernet:
>>
>> +static int __init init_edosk7760_devices(void){
>> + int ret = -1;
>> +
>> + /* This is the Ethernet interrupt */
>> + make_imask_irq(ETHERNET_IRQ);
>> +
>> + /* This is the IntelStrata Flash interrupt */
>> + make_imask_irq(0x0A);
>>
>> Is the flash interrupt tested?
>>
>> I suspect that the chips are connected straight to the IRL pins of the
>> processor. Using "individual interrupt mode" would make sense then. Do
>> you have access to schematics?
>
> According to the schematics, 15 irqs are connected to a CPLD which creates
> the 4bit IRL value. Unfortunately there is no way to individually mask them
> in the CPLD itself (it has no databus connection).
Ok, thank you. That's disgusting.
Are all 15 irqs in use? If we only plan on using the ethernet and the
flash, then maybe we can use "individual interrupt mode". Then we can
mask using the cpu.
The code seems to use interrupt number 9 and 10, so maybe the ethernet
controller can use IRL0 (interrupt number 2) and flash IRL1 (interrupt
number 5). The interrupts may of course block each other but there's
nothing we can do about that...
Or as a last resort we may have to fix up the imask controller. =)
Thanks!
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (12 preceding siblings ...)
2008-09-05 8:46 ` Magnus Damm
@ 2008-09-05 8:48 ` Paul Mundt
2008-09-05 9:01 ` Manuel Lauss
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Paul Mundt @ 2008-09-05 8:48 UTC (permalink / raw)
To: linux-sh
On Fri, Sep 05, 2008 at 10:14:43AM +0200, Luca Santini wrote:
> p.s.: a little question git-related... (i'm moving my first steps with
> git..) :
>
> if i pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
>
> it asks for a password.... ???
>
> currently, i pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git
>
> is it the same?
>
The first one is for people who have SSH accounts on kernel.org, and is
usually what I include in my pull requests to Linus. This is due to the
fact that the git:// data used to lag behind a bit, so if I pushed the
updates wouldn't be immediately visible through anonymous access.
The time gap between updates between the two these days has mostly been
fixed, and indeed, Linus rewrites the pull requests to go through git://
these days anyways, I've just been too lazy to update my scripts.
In any event, you should always use the git:// URLs.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (13 preceding siblings ...)
2008-09-05 8:48 ` Paul Mundt
@ 2008-09-05 9:01 ` Manuel Lauss
2008-09-05 10:16 ` Luca Santini
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Manuel Lauss @ 2008-09-05 9:01 UTC (permalink / raw)
To: linux-sh
On Fri, Sep 05, 2008 at 05:46:08PM +0900, Magnus Damm wrote:
> On Fri, Sep 5, 2008 at 5:33 PM, Manuel Lauss
> <mano@roarinelk.homelinux.net> wrote:
> > Hi Magnus,
> >
> > On Fri, Sep 05, 2008 at 05:14:34PM +0900, Magnus Damm wrote:
> >> On Mon, Sep 1, 2008 at 5:11 PM, Luca Santini
> >> <luca.santini@spesonline.com> wrote:
> >> > thanks for reply Magnus,
> >> > in 2.6.26 everything works fine with irq 9;
> >>
> >> I see that you install imask handlers for the flash and the ethernet:
> >>
> >> +static int __init init_edosk7760_devices(void){
> >> + int ret = -1;
> >> +
> >> + /* This is the Ethernet interrupt */
> >> + make_imask_irq(ETHERNET_IRQ);
> >> +
> >> + /* This is the IntelStrata Flash interrupt */
> >> + make_imask_irq(0x0A);
> >>
> >> Is the flash interrupt tested?
> >>
> >> I suspect that the chips are connected straight to the IRL pins of the
> >> processor. Using "individual interrupt mode" would make sense then. Do
> >> you have access to schematics?
> >
> > According to the schematics, 15 irqs are connected to a CPLD which creates
> > the 4bit IRL value. Unfortunately there is no way to individually mask them
> > in the CPLD itself (it has no databus connection).
>
> Ok, thank you. That's disgusting.
Yes, yes it is...
> Are all 15 irqs in use? If we only plan on using the ethernet and the
> flash, then maybe we can use "individual interrupt mode". Then we can
> mask using the cpu.
All except the ethernet and flash irqs are connected to "buffered expasion"
connectors for daughtercards. So there's really only 1 interesting source.
> The code seems to use interrupt number 9 and 10, so maybe the ethernet
> controller can use IRL0 (interrupt number 2) and flash IRL1 (interrupt
> number 5). The interrupts may of course block each other but there's
> nothing we can do about that...
>
> Or as a last resort we may have to fix up the imask controller. =)
Heh, I'd rather shame the board vendor into fixing this, but your idea
has a far greater chance of success ;-)
MfG,
Manuel Lauss
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (14 preceding siblings ...)
2008-09-05 9:01 ` Manuel Lauss
@ 2008-09-05 10:16 ` Luca Santini
2008-09-05 14:14 ` Luca Santini
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Luca Santini @ 2008-09-05 10:16 UTC (permalink / raw)
To: linux-sh
Magnus Damm wrote:
> Hi again Luca!
>
> On Fri, Sep 5, 2008 at 6:50 PM, Luca Santini
> <luca.santini@spesonline.com> wrote:
>> I think i'm misunderstanding something.....
>> if i try to setup eth on irq 2 (or 5 or 8 or 11...)
>> and set the platform like this
>>
>> static void __init sh_edosk7760_init_irq(void)
>> {
>> }
>>
>> static int __init init_edosk7760_devices(void)
>> {
>> plat_irq_setup_pins(IRQ_MODE_IRQ);
>>
>> return platform_add_devices(edosk7760_devices,
>> ARRAY_SIZE(edosk7760_devices));
>> }
>> __initcall(init_edosk7760_devices);
>
> Ok, looking good!
>
>> i have the well known
>>
>> ...
>> [ 1.474095] eth0: SMC91C94 (rev 9) at a2000300 IRQ 2 [nowait]
>> ... (label:)
>> [ 3.112795] irq 9, desc: 8c228978, depth: 1, count: 0, unhandled: 0
>> [ 3.116471] ->handle_irq(): 8c0361d8, handle_bad_irq+0x0/0x1ac
>> [ 3.122343] ->chip(): 8c228740, no_irq_chip+0x0/0x40
>> [ 3.127267] ->action(): 00000000
>> [ 3.130464] IRQ_DISABLED set
>> ... (goto label)
>
> It still says "irq 9", is that a coding or copy-paste mistake?
>
No, it's a fresh grab ! Very strange.....
Trying the IORESOURCE_IRQ_HIGHLEVEL flag and irq 2 the chip isn't
detected (-19) so of course i have no nfs transfer and no irq problems;
i tried also IORESOURCE_IRQ_LOWLEVEL instead and i get the same
[ 6.893332] unexpected IRQ trap at vector 09
[ 6.897576] irq 9, desc: 8c228978, depth: 1, count: 0, unhandled: 0
etc..
> / magnus
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (15 preceding siblings ...)
2008-09-05 10:16 ` Luca Santini
@ 2008-09-05 14:14 ` Luca Santini
2008-09-08 2:26 ` Magnus Damm
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Luca Santini @ 2008-09-05 14:14 UTC (permalink / raw)
To: linux-sh
I finally made eth work with these changes...
Paul please check if my changes to setup-sh7760.c are ok,
many thanks to Magnus and Manuel.
Luca Santini
diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig
index ae19486..8a84c18 100644
--- a/arch/sh/boards/Kconfig
+++ b/arch/sh/boards/Kconfig
@@ -180,6 +180,13 @@ config SH_SH7763RDP
Select SH7763RDP if configuring for a Renesas SH7763
evaluation board.
+config SH_EDOSK7760
+ bool "EDOSK7760"
+ depends on CPU_SUBTYPE_SH7760
+ help
+ Select if configuring for a Renesas edosk7760
+ evaluation board.
+
config SH_EDOSK7705
bool "EDOSK7705"
depends on CPU_SUBTYPE_SH7705
diff --git a/arch/sh/boards/Makefile b/arch/sh/boards/Makefile
index 463022c..d9efa39 100644
--- a/arch/sh/boards/Makefile
+++ b/arch/sh/boards/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_SH_MAGIC_PANEL_R2) += board-magicpanelr2.o
obj-$(CONFIG_SH_RSK7203) += board-rsk7203.o
obj-$(CONFIG_SH_SH7785LCR) += board-sh7785lcr.o
obj-$(CONFIG_SH_SHMIN) += board-shmin.o
+obj-$(CONFIG_SH_EDOSK7760) += board-edosk7760.o
diff --git a/arch/sh/boards/board-edosk7760.c
b/arch/sh/boards/board-edosk7760.c
new file mode 100644
index 0000000..82f76d1
--- /dev/null
+++ b/arch/sh/boards/board-edosk7760.c
@@ -0,0 +1,184 @@
+/*
+ *
+ * Renesas Europe EDOSK7760 Board Support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * Copyright (C) 2008 SPES Societa' Progettazione Elettronica e
Software Ltd.
+ * Author: Luca Santini <luca.santini@spesonline.com>
+ *
+ */
+
+/* Bus state controller registers for CS4 area */
+#define BSC_CS4BCR 0xA4FD0010
+#define BSC_CS4WCR 0xA4FD0030
+
+#define SMC_IOBASE 0xA2000000
+#define SMC_IO_OFFSET 0x300
+#define SMC_IOADDR SMC_IOBASE + SMC_IO_OFFSET
+#define ETHERNET_IRQ 5
+
+#include <linux/init.h>
+#include <linux/types.h>
+#include <linux/platform_device.h>
+#include <linux/smc91x.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <asm/machvec.h>
+#include <asm/io.h>
+#include <asm/addrspace.h>
+#include <asm/delay.h>
+#include <asm/i2c-sh7760.h>
+
+
+/* i2c initialization functions */
+
+static struct sh7760_i2c_platdata i2c_pd = {
+ .speed_khz = 400,
+};
+
+static struct resource sh7760_i2c1_res[] = {
+ {
+ .start = SH7760_I2C1_MMIO,
+ .end = SH7760_I2C1_MMIOEND,
+ .flags = IORESOURCE_MEM,
+ },{
+ .start = SH7760_I2C1_IRQ,
+ .end = SH7760_I2C1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device sh7760_i2c1_dev = {
+ .dev = {
+ .platform_data = &i2c_pd,
+ },
+ .name = SH7760_I2C_DEVNAME,
+ .id = 1,
+ .resource = sh7760_i2c1_res,
+ .num_resources = ARRAY_SIZE(sh7760_i2c1_res),
+};
+
+
+static struct resource sh7760_i2c0_res[] = {
+ {
+ .start = SH7760_I2C0_MMIO,
+ .end = SH7760_I2C0_MMIOEND,
+ .flags = IORESOURCE_MEM,
+ },{
+ .start = SH7760_I2C0_IRQ,
+ .end = SH7760_I2C0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device sh7760_i2c0_dev = {
+ .dev = {
+ .platform_data = &i2c_pd,
+ },
+ .name = SH7760_I2C_DEVNAME,
+ .id = 0,
+ .resource = sh7760_i2c0_res,
+ .num_resources = ARRAY_SIZE(sh7760_i2c0_res),
+};
+
+/* eth initialization functions */
+
+static struct smc91x_platdata smc91x_info = {
+ .flags = SMC91X_USE_16BIT | SMC91X_IO_SHIFT_1 | IORESOURCE_IRQ_LOWLEVEL,
+};
+
+static struct resource smc91x_res[] = {
+ [0] = {
+ .start = SMC_IOADDR,
+ .end = SMC_IOADDR + 0x1f,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = ETHERNET_IRQ,
+ .end = ETHERNET_IRQ,
+ .flags = IORESOURCE_IRQ ,
+ }
+};
+
+static struct platform_device smc91x_dev = {
+
+ .name = "smc91x",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(smc91x_res),
+ .resource = smc91x_res,
+ .dev = {
+ .platform_data = &smc91x_info,
+ },
+
+};
+
+/* platform init code */
+
+static struct platform_device *edosk7760_devices[] __initdata = {
+ &sh7760_i2c0_dev,
+ &sh7760_i2c1_dev,
+#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
+ &smc91x_dev,
+#endif
+
+};
+
+static int __init init_edosk7760_devices(void)
+{
+ plat_irq_setup_pins(IRQ_MODE_IRQ);
+ return platform_add_devices(edosk7760_devices,
ARRAY_SIZE(edosk7760_devices));
+}
+__initcall(init_edosk7760_devices);
+
+/*
+ * The Machine Vector
+ */
+struct sh_machine_vector mv_edosk7760 __initmv = {
+ .mv_name = "EDOSK7760",
+ .mv_nr_irqs = 128,
+};
diff --git a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
index 254c5c5..cccd9a3 100644
--- a/arch/sh/kernel/cpu/sh4/setup-sh7760.c
+++ b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
@@ -9,6 +9,7 @@
*/
#include <linux/platform_device.h>
#include <linux/init.h>
+#include <linux/io.h>
#include <linux/serial.h>
#include <linux/serial_sci.h>
@@ -178,10 +179,15 @@ static int __init sh7760_devices_setup(void)
}
__initcall(sh7760_devices_setup);
+#define INTC_ICR 0xffd00000UL
+#define INTC_ICR_IRLM (1<<7)
+
+
void __init plat_irq_setup_pins(int mode)
{
switch (mode) {
case IRQ_MODE_IRQ:
+ ctrl_outw(ctrl_inw(INTC_ICR) | INTC_ICR_IRLM, INTC_ICR);
register_intc_controller(&intc_desc_irq);
break;
default:
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 997e7f1..edea073 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -446,6 +446,8 @@ static inline void LPD7_SMC_outsw (unsigned char* a,
int r,
#define SMC_CAN_USE_32BIT 1
#define SMC_NOWAIT 1
+#define SMC_IO_SHIFT (lp->io_shift)
+
#define SMC_inb(a, r) readb((a) + (r))
#define SMC_inw(a, r) readw((a) + (r))
#define SMC_inl(a, r) readl((a) + (r))
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (16 preceding siblings ...)
2008-09-05 14:14 ` Luca Santini
@ 2008-09-08 2:26 ` Magnus Damm
2008-09-08 2:30 ` Paul Mundt
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: Magnus Damm @ 2008-09-08 2:26 UTC (permalink / raw)
To: linux-sh
Hi again Luca,
On Fri, Sep 5, 2008 at 11:14 PM, Luca Santini
<luca.santini@spesonline.com> wrote:
> I finally made eth work with these changes...
Great news!
> Paul please check if my changes to setup-sh7760.c are ok,
> many thanks to Magnus and Manuel.
I think you should split your patch into three parts:
1) smc91x specific code
2) sh7760 specific code
3) edos7760 specific code
I'm planning on submitting patch 1) upstream myself, so you don't have
to do anything about that. Just excluded that part. As for 2) and 3),
you should definitely resend them.
Also, please send them to a new thread. Thank you!
/ magnus
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (17 preceding siblings ...)
2008-09-08 2:26 ` Magnus Damm
@ 2008-09-08 2:30 ` Paul Mundt
2008-09-08 2:52 ` Paul Mundt
2008-09-08 5:41 ` Manuel Lauss
20 siblings, 0 replies; 22+ messages in thread
From: Paul Mundt @ 2008-09-08 2:30 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 08, 2008 at 11:26:54AM +0900, Magnus Damm wrote:
> Hi again Luca,
>
> On Fri, Sep 5, 2008 at 11:14 PM, Luca Santini
> <luca.santini@spesonline.com> wrote:
> > I finally made eth work with these changes...
>
> Great news!
>
> > Paul please check if my changes to setup-sh7760.c are ok,
> > many thanks to Magnus and Manuel.
>
> I think you should split your patch into three parts:
> 1) smc91x specific code
> 2) sh7760 specific code
> 3) edos7760 specific code
>
> I'm planning on submitting patch 1) upstream myself, so you don't have
> to do anything about that. Just excluded that part. As for 2) and 3),
> you should definitely resend them.
>
> Also, please send them to a new thread. Thank you!
>
No worries, I'll split out 2 and 3 manually, it's not that big of a deal.
The SH7760 bits look fine to me anyways. Manuel?
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (18 preceding siblings ...)
2008-09-08 2:30 ` Paul Mundt
@ 2008-09-08 2:52 ` Paul Mundt
2008-09-08 5:41 ` Manuel Lauss
20 siblings, 0 replies; 22+ messages in thread
From: Paul Mundt @ 2008-09-08 2:52 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 08, 2008 at 11:30:11AM +0900, Paul Mundt wrote:
> On Mon, Sep 08, 2008 at 11:26:54AM +0900, Magnus Damm wrote:
> > Hi again Luca,
> >
> > On Fri, Sep 5, 2008 at 11:14 PM, Luca Santini
> > <luca.santini@spesonline.com> wrote:
> > > I finally made eth work with these changes...
> >
> > Great news!
> >
> > > Paul please check if my changes to setup-sh7760.c are ok,
> > > many thanks to Magnus and Manuel.
> >
> > I think you should split your patch into three parts:
> > 1) smc91x specific code
> > 2) sh7760 specific code
> > 3) edos7760 specific code
> >
> > I'm planning on submitting patch 1) upstream myself, so you don't have
> > to do anything about that. Just excluded that part. As for 2) and 3),
> > you should definitely resend them.
> >
> > Also, please send them to a new thread. Thank you!
> >
> No worries, I'll split out 2 and 3 manually, it's not that big of a deal.
> The SH7760 bits look fine to me anyways. Manuel?
Luca, please also send an edosk7760_defconfig so that we are able to tie
this in to the daily builds.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH] support for edosk7760 board
2008-08-27 10:34 [PATCH] support for edosk7760 board Luca Santini
` (19 preceding siblings ...)
2008-09-08 2:52 ` Paul Mundt
@ 2008-09-08 5:41 ` Manuel Lauss
20 siblings, 0 replies; 22+ messages in thread
From: Manuel Lauss @ 2008-09-08 5:41 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 08, 2008 at 11:30:11AM +0900, Paul Mundt wrote:
> On Mon, Sep 08, 2008 at 11:26:54AM +0900, Magnus Damm wrote:
> > Hi again Luca,
> >
> > On Fri, Sep 5, 2008 at 11:14 PM, Luca Santini
> > <luca.santini@spesonline.com> wrote:
> > > I finally made eth work with these changes...
> >
> > Great news!
> >
> > > Paul please check if my changes to setup-sh7760.c are ok,
> > > many thanks to Magnus and Manuel.
> >
> > I think you should split your patch into three parts:
> > 1) smc91x specific code
> > 2) sh7760 specific code
> > 3) edos7760 specific code
> >
> > I'm planning on submitting patch 1) upstream myself, so you don't have
> > to do anything about that. Just excluded that part. As for 2) and 3),
> > you should definitely resend them.
> >
> > Also, please send them to a new thread. Thank you!
> >
> No worries, I'll split out 2 and 3 manually, it's not that big of a deal.
> The SH7760 bits look fine to me anyways. Manuel?
No runtime problems here; the change is required for non-IRL mode to work.
Best regards,
Manuel Lauss
^ permalink raw reply [flat|nested] 22+ messages in thread