support for edosk7760 board
Subsystems (2)
PATCH 1/1 support for edosk7760 board
this is against vanilla 2.6.26;
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
- flash support?
- ...
remember to change commandline according your needs (nfs, /dev/ram...)
arch/sh/boards/renesas/edosk7760/Makefile +9 -0
@@ -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
arch/sh/boards/renesas/edosk7760/setup.c +177 -0
177 lines not on this page · raw message
arch/sh/configs/edosk7760_defconfig +1050 -0
1,050 lines not on this page · raw message
arch/sh/Kconfig +6 -0
@@ -553,6 +553,12 @@ depends on CPU_SUBTYPE_SH5_101 || CPU_SUBTYPE_SH5_103 select SYS_SUPPORTS_PCI +config SH_EDOSK7760 + bool "edosk7760" + help + "SPES support for edosk7760 board" + + endmenu source "arch/sh/boards/renesas/rts7751r2d/Kconfig"
I file binari a/arch/sh/lib/lib.a e b/arch/sh/lib/lib.a differiscono
arch/sh/Makefile +1 -0
@@ -130,6 +130,7 @@ machdir-$(CONFIG_SH_LBOX_RE2) += lboxre2 machdir-$(CONFIG_SH_MAGIC_PANEL_R2) += magicpanelr2 machdir-$(CONFIG_SH_CAYMAN) += cayman +machdir-$(CONFIG_SH_EDOSK7760) += renesas/edosk7760 incdir-y := $(notdir $(machdir-y))
Hi Luca,
Quoted 9 lines · Luca Santini
currently you have (defconfig) :
- ramdisk support
- ethernet support
- nfs support
- ext2/ext3 support
- i2c support
- fb support (M)
Quoted 4 lines
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.)
Quoted 1 line
- flash support?
look e.g. at the ap325rxa boards' use of the physmap-flash driver.
arch/sh/boards/renesas/edosk7760/Makefile line 9
Quoted 13 lines
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
arch/sh/boards/renesas/edosk7760/Makefile +9
-0@@ -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
Quoted 26 lines
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.cb/arch/sh/boards/renesas/edosk7760/setup.carch/sh/boards/renesas/edosk7760/setup.c +22
-0@@ -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 +
arch/sh/boards/renesas/edosk7760/setup.c line 32
Quoted 10 lines
arch/sh/boards/renesas/edosk7760/setup.c +10
-0+#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/.
arch/sh/boards/renesas/edosk7760/setup.c line 33
Quoted 1 line
arch/sh/boards/renesas/edosk7760/setup.c +1
-0+#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).
Quoted 46 lines
arch/sh/boards/renesas/edosk7760/setup.c +46
-0+/* 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 ,
arch/sh/boards/renesas/edosk7760/setup.c line 90
Quoted 10 lines
arch/sh/boards/renesas/edosk7760/setup.c +10
-0+ .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.
Quoted 25 lines
arch/sh/boards/renesas/edosk7760/setup.c +25
-0+/* 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,
arch/sh/boards/renesas/edosk7760/setup.c line 126
Quoted 10 lines
arch/sh/boards/renesas/edosk7760/setup.c +10
-0+ .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.
Quoted 8 lines
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+ &sh7760_i2c0_dev, + &sh7760_i2c1_dev, +#endif + +#if defined(CONFIG_SMC91X ) || defined(CONFIG_SMC91X_MODULE ) + &smc91x_dev, +#endif +
arch/sh/boards/renesas/edosk7760/setup.c line 144
Quoted 10 lines
arch/sh/boards/renesas/edosk7760/setup.c +10
-0+}; + +#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).
Quoted 22 lines
arch/sh/boards/renesas/edosk7760/setup.c +22
-0+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); +
arch/sh/boards/renesas/edosk7760/setup.c line 177
Quoted 10 lines
arch/sh/boards/renesas/edosk7760/setup.c +10
-0+/* +* 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
A few notes in addition to what Manuel said:
Quoted 9 lines · Manuel Lauss
Quoted 9 lines
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.cb/arch/sh/boards/renesas/edosk7760/setup.carch/sh/boards/renesas/edosk7760/setup.c +5
-0@@ -0,0 +1,177 @@ +/* +* linux/arch/sh/edosk7760/setup.c +* +* Copyright (C) 2000 Kazumoto Kojima +*
Quoted 8 lines
arch/sh/boards/renesas/edosk7760/setup.c line 13
Quoted 8 lines
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+* +* 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.
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c line 97
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c +4
-0+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.
Quoted 1 line
arch/sh/boards/renesas/edosk7760/setup.c line 146
Quoted 1 line
arch/sh/boards/renesas/edosk7760/setup.c +1
-0+static int __init init_edosk7760_devices (void ){
The { should be on a line by itself.
Quoted 2 lines
arch/sh/boards/renesas/edosk7760/setup.c line 20
Quoted 2 lines
arch/sh/boards/renesas/edosk7760/setup.c +2
-0+int ret =-1 ; +
Pointless initialization and unused variable.
Quoted 1 line
arch/sh/boards/renesas/edosk7760/setup.c line 172
Quoted 1 line
arch/sh/boards/renesas/edosk7760/setup.c +1
-0+/// 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.
Quoted 5 lines
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.cfile, I suggest you rename it tomach-edosk7760.cand wire it up inarch/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.
Quoted 30 lines · Luca Santini
Quoted 19 lines · Paul Mundt
Quoted 18 lines · Manuel Lauss
Quoted 18 lines
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.cb/arch/sh/boards/renesas/edosk7760/setup.c
---a/arch/sh/boards/renesas/edosk7760/setup.c1970-01-01
01:00:00.000000000 +0100
+++b/arch/sh/boards/renesas/edosk7760/setup.c2008-08-27
12:01:58.000000000 +0200arch/sh/boards/renesas/edosk7760/setup.c +9
-0@@ -0,0 +1,177 @@ +/* +* linux/arch/sh/edosk7760/setup.c +* +* Copyright (C) 2000 Kazumoto Kojima +* +* +* Modified for EDOSK7760 by +* Richard Bister +* Quoted 9 lines
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c line 13
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c +4
-0+* 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.
Quoted 2 lines
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.
Quoted 14 lines
Quoted 11 lines
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c line 97
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c +4
-0+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
Quoted 8 lines
#define
SMC_IO_SHIFT1but using the platdata flag
SMC91X_IO_SHIFT_1doesn't work.
Ok, so that's a real bug then. Magnus, can you take a look at this?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 17 lines · Paul Mundt
Quoted 16 lines · Luca Santini
Quoted 11 lines
Quoted 4 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+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_SHIFT1
Quoted 7 lines
Quoted 6 lines
but using the platdata flag
SMC91X_IO_SHIFT_1doesn'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
drivers/net/smc91x.h +2 -0
@@ -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))
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
Quoted 31 lines · Magnus Damm
Quoted 16 lines · Paul Mundt
Quoted 15 lines · Luca Santini
Quoted 11 lines
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c line 97
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c +4
-0+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_SHIFT1Quoted 7 lines
Quoted 6 lines
but using the platdata flag
SMC91X_IO_SHIFT_1doesn'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
Quoted 12 lines · Luca Santini
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.coutputs[ 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
Quoted 8 lines
[ 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 09something 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
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!
Quoted 37 lines · Magnus Damm
Quoted 12 lines · Luca Santini
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.coutputs[ 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 ofQuoted 8 lines
[ 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 09something 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Luca Santini
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.
Quoted 15 lines
trying to debug a little
kernel/irq/manage.ci found that in 2.6.26 in functionsetup_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
Quoted 6 lines
i tried (for debug) to force in
smc91x.h#define SMC_IRQ_FLAGS 0to 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
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?
Quoted 39 lines · Magnus Damm
Hi Luca,
Quoted 21 lines · Magnus Damm
Quoted 20 lines · Paul Mundt
Quoted 19 lines · Luca Santini
Quoted 11 lines
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c line 97
Quoted 4 lines
arch/sh/boards/renesas/edosk7760/setup.c +4
-0+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_SHIFT1but using the platdata flag
SMC91X_IO_SHIFT_1Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
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
Quoted 22 lines · Magnus Damm
Quoted 2 lines · Luca Santini
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:
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+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?
Quoted 5 lines
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[] insetup-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
Hi Luca,
Quoted 2 lines · Luca Santini
Hi Magnus,
sorry for my late...
No worries!
Quoted 9 lines
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 inkernel/irq/manage.ccompat_irq_chip_set_default_handler()is called; otherwise in .27 the function called is__irq_set_trigger(), but withchip->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!
Quoted 7 lines
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
Quoted 7 lines
it asks for a password.... ???
currently, i pull from
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.gitis it the same?
I'm not sure. I always use the git:// myself.
/ magnus
Hi Magnus,
Quoted 16 lines · Magnus Damm
Quoted 2 lines · Luca Santini
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:
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+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 );
Quoted 5 lines
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
Quoted 21 lines · Manuel Lauss
Hi Magnus,
Quoted 18 lines · Magnus Damm
Quoted 2 lines · Luca Santini
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:
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+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?
Quoted 7 lines
Quoted 3 lines
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
Quoted 7 lines · Luca Santini
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
Quoted 8 lines
it asks for a password.... ???
currently, i pull from
git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.gitis 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.
Quoted 31 lines · Magnus Damm
Quoted 21 lines · Manuel Lauss
Hi Magnus,
Quoted 18 lines · Magnus Damm
Quoted 2 lines · Luca Santini
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:
arch/sh/boards/renesas/edosk7760/setup.c +8
-0+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?
Quoted 7 lines
Quoted 3 lines
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).
Quoted 1 line
Ok, thank you. That's disgusting.
Yes, yes it is...
Quoted 3 lines
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.
Quoted 6 lines
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
Quoted 35 lines · Magnus Damm
Hi again Luca!
Quoted 8 lines · Luca Santini
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
__initsh_edosk7760_init_irq(void)
{
}Quoted 8 lines
static int
__initinit_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!
Quoted 11 lines
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)
Quoted 2 lines
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..
Quoted 3 lines
/ magnus
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
arch/sh/boards/Kconfig +7 -0
@@ -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
arch/sh/boards/Makefile +1 -0
@@ -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
(quoted diff) +0 -0
b/arch/sh/boards/board-edosk7760.c
new file mode 100644
index 0000000..82f76d1
arch/sh/boards/board-edosk7760.c new file +19 -0
@@ -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 <[email protected]>
+ *
+ */
+
+/* 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,
+};
(quoted diff) +0 -0
b/arch/sh/kernel/cpu/sh4/setup-sh7760.c
index 254c5c5..cccd9a3 100644
arch/sh/kernel/cpu/sh4/setup-sh7760.c +6 -0
@@ -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 :
drivers/net/smc91x.h +0 -0
@@ -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))
Hi again Luca,
Quoted 1 line · Luca Santini
I finally made eth work with these changes...
Great news!
Quoted 2 lines
Paul please check if my changes to
setup-sh7760.care 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
Quoted 16 lines · Magnus Damm
Hi again Luca,
Quoted 1 line · Luca Santini
I finally made eth work with these changes...
Great news!
Quoted 2 lines
Paul please check if my changes to
setup-sh7760.care 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
Quoted 6 lines
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?
Quoted 17 lines · Paul Mundt
Quoted 16 lines · Magnus Damm
Hi again Luca,
Quoted 1 line · Luca Santini
I finally made eth work with these changes...
Great news!
Quoted 2 lines
Paul please check if my changes to
setup-sh7760.care 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
Quoted 8 lines
Quoted 6 lines
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.
Quoted 17 lines · Paul Mundt
Quoted 16 lines · Magnus Damm
Hi again Luca,
Quoted 1 line · Luca Santini
I finally made eth work with these changes...
Great news!
Quoted 2 lines
Paul please check if my changes to
setup-sh7760.care 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
Quoted 8 lines
Quoted 6 lines
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