You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(82) |
Jun
(72) |
Jul
(39) |
Aug
(104) |
Sep
(61) |
Oct
(55) |
Nov
(101) |
Dec
(48) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(52) |
Feb
(67) |
Mar
(18) |
Apr
(16) |
May
(33) |
Jun
(12) |
Jul
(102) |
Aug
(168) |
Sep
(65) |
Oct
(60) |
Nov
(43) |
Dec
(121) |
2002 |
Jan
(69) |
Feb
(32) |
Mar
(90) |
Apr
(59) |
May
(45) |
Jun
(43) |
Jul
(33) |
Aug
(21) |
Sep
(11) |
Oct
(20) |
Nov
(26) |
Dec
(3) |
2003 |
Jan
(12) |
Feb
(18) |
Mar
(11) |
Apr
(11) |
May
(41) |
Jun
(76) |
Jul
(77) |
Aug
(15) |
Sep
(38) |
Oct
(56) |
Nov
(19) |
Dec
(39) |
2004 |
Jan
(17) |
Feb
(52) |
Mar
(36) |
Apr
(34) |
May
(48) |
Jun
(85) |
Jul
(38) |
Aug
(42) |
Sep
(41) |
Oct
(77) |
Nov
(27) |
Dec
(19) |
2005 |
Jan
(32) |
Feb
(35) |
Mar
(29) |
Apr
(8) |
May
(7) |
Jun
(31) |
Jul
(46) |
Aug
(93) |
Sep
(65) |
Oct
(85) |
Nov
(219) |
Dec
(47) |
2006 |
Jan
(170) |
Feb
(103) |
Mar
(49) |
Apr
(43) |
May
(45) |
Jun
(29) |
Jul
(77) |
Aug
(82) |
Sep
(43) |
Oct
(45) |
Nov
(26) |
Dec
(85) |
2007 |
Jan
(42) |
Feb
(48) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(53) |
Jul
(175) |
Aug
(212) |
Sep
(91) |
Oct
(103) |
Nov
(110) |
Dec
(5) |
2008 |
Jan
(20) |
Feb
(11) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(3) |
Oct
(12) |
Nov
|
Dec
|
From: Paul M. <le...@li...> - 2007-07-30 22:21:06
|
On Mon, Jul 30, 2007 at 07:38:06PM +0900, Magnus Damm wrote: > sh: simplify board specific interrupt code for solution engine 7780 > > The new intc code handles IRQ3 and IRQ7 in the cpu specific code already, > so there is no reason to duplicate that here. > > Signed-off-by: Magnus Damm <da...@ig...> Looks good, As Iwamatsu-san is probably the only one testing this board at the moment, it would be nice to know if this causes any regressions there. I'll add it to the 2.6.24 queue. |
From: Paul M. <le...@li...> - 2007-07-30 22:18:20
|
On Sun, Jul 29, 2007 at 12:54:36PM +1000, Jamie Lenehan wrote: > On Wed, Jul 25, 2007 at 12:44:04PM +0900, Magnus Damm wrote: > [...] > > Also, the cpu-specific interrupt code has been rewritten for > > 2.6.23-rc1. The new code seems to work just fine on the r2d board, but > > it wouldn't hurt with some testing on other 7750-ish boards. > > I've just tested 2.6.23-rc1-ge8a53af7 (lastest sh-2.6.git) on the > titan 7751R board and everything looks to be working just fine. > > Also the "sh: Add kmap_coherent()/kunmap_coherent() interface for > SH-4" change has fixed the "scheduling while atomic" messages I was > seeing when running from NFS-root. > > boot log: http://twibble.org/dist/misc/titan-boot-ge8a53af7.txt > config: http://twibble.org/dist/misc/titan-config-ge8a53af7.txt > That's good to hear. Thanks for testing, Jamie. |
From: Paul M. <le...@li...> - 2007-07-30 22:05:30
|
On Mon, Jul 30, 2007 at 08:49:27PM +0100, Adrian McMenamin wrote: > On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote: > > On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote: > > > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c > > > index 6334a4c..6f5e9e4 100644 > > > --- a/arch/sh/kernel/process.c > > > +++ b/arch/sh/kernel/process.c > > > @@ -97,6 +97,11 @@ void cpu_idle(void) > > > > > > void machine_restart(char * __unused) > > > { > > > + > > > +#ifdef CONFIG_SH_DREAMCAST > > > + /*reboot the Dreamcast under software control*/ > > > + writel(0x00007611, 0xA05F6890); > > > +#endif > > > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ > > > asm volatile("ldc %0, sr\n\t" > > > "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); > > > > No, if you want to do this, at least use a function pointer and leave > > this as the default implementation. The dreamcast presumably only needs > > this magic write anyways, rather than the SR.BL trick. > > > OK, stupid question time: How does the build process know what to link > with - ie how to overload? > If you look at machine_power_off() you can see how there's a function pointer nested within it that boards can optionally set to their own implementations, or if it's unset, we just go with the default behaviour. Something like that is probably more in line with how we want to go. On the other hand, this isn't crucial for 2.6.23, and if we're going to do this for 2.6.24, we should probably consider something more like the i386 machine_ops for implementing these various bits of functionality, rather than abusing some of the tie-in with the pm ops. I'll take a look at cobbling something together for the 2.6.24 dev tree, and move some of the boards over to it. It should be pretty apparent from this how to wire it up on the dreamcast, with the restart functionality you're after. |
From: Adrian M. <ad...@ne...> - 2007-07-30 19:50:03
|
On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote: > On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote: > > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c > > index 6334a4c..6f5e9e4 100644 > > --- a/arch/sh/kernel/process.c > > +++ b/arch/sh/kernel/process.c > > @@ -97,6 +97,11 @@ void cpu_idle(void) > > > > void machine_restart(char * __unused) > > { > > + > > +#ifdef CONFIG_SH_DREAMCAST > > + /*reboot the Dreamcast under software control*/ > > + writel(0x00007611, 0xA05F6890); > > +#endif > > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ > > asm volatile("ldc %0, sr\n\t" > > "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); > > No, if you want to do this, at least use a function pointer and leave > this as the default implementation. The dreamcast presumably only needs > this magic write anyways, rather than the SR.BL trick. > OK, stupid question time: How does the build process know what to link with - ie how to overload? If I just put a small .c file in /arch/sh/Dreamcast with appropriate exported function will the linker automagically link in my function or will it clash with the other generic or generic-SH4 function? I've tried to work this out from looking at the code but haven't managed it so far. |
From: Magnus D. <mag...@gm...> - 2007-07-30 10:39:01
|
sh: simplify board specific interrupt code for solution engine 7780 The new intc code handles IRQ3 and IRQ7 in the cpu specific code already, so there is no reason to duplicate that here. Signed-off-by: Magnus Damm <da...@ig...> --- arch/sh/Kconfig | 1 - arch/sh/boards/se/7780/irq.c | 28 +--------------------------- 2 files changed, 1 insertion(+), 28 deletions(-) --- 0001/arch/sh/Kconfig +++ work/arch/sh/Kconfig 2007-07-30 12:18:22.000000000 +0900 @@ -258,7 +258,6 @@ config SH_7780_SOLUTION_ENGINE bool "SolutionEngine7780" select SOLUTION_ENGINE select SYS_SUPPORTS_PCI - select CPU_HAS_INTC2_IRQ depends on CPU_SUBTYPE_SH7780 help Select 7780 SolutionEngine if configuring for a Renesas SH7780 --- 0001/arch/sh/boards/se/7780/irq.c +++ work/arch/sh/boards/se/7780/irq.c 2007-07-30 12:16:31.000000000 +0900 @@ -16,32 +16,6 @@ #include <asm/io.h> #include <asm/se7780.h> -static struct intc2_data intc2_irq_table[] = { - { 2, 0, 31, 0, 31, 3 }, /* daughter board EXTINT1 */ - { 4, 0, 30, 0, 30, 3 }, /* daughter board EXTINT2 */ - { 6, 0, 29, 0, 29, 3 }, /* daughter board EXTINT3 */ - { 8, 0, 28, 0, 28, 3 }, /* SMC 91C111 (LAN) */ - { 10, 0, 27, 0, 27, 3 }, /* daughter board EXTINT4 */ - { 4, 0, 30, 0, 30, 3 }, /* daughter board EXTINT5 */ - { 2, 0, 31, 0, 31, 3 }, /* daughter board EXTINT6 */ - { 2, 0, 31, 0, 31, 3 }, /* daughter board EXTINT7 */ - { 2, 0, 31, 0, 31, 3 }, /* daughter board EXTINT8 */ - { 0 , 0, 24, 0, 24, 3 }, /* SM501 */ -}; - -static struct intc2_desc intc2_irq_desc __read_mostly = { - .prio_base = 0, /* N/A */ - .msk_base = 0xffd00044, - .mskclr_base = 0xffd00064, - - .intc2_data = intc2_irq_table, - .nr_irqs = ARRAY_SIZE(intc2_irq_table), - - .chip = { - .name = "INTC2-se7780", - }, -}; - /* * Initialize IRQ setting */ @@ -68,5 +42,5 @@ void __init init_se7780_IRQ(void) /* FPGA + 0x0A */ ctrl_outw((IRQPIN_PCCPW << IRQPOS_PCCPW), FPGA_INTSEL3); - register_intc2_controller(&intc2_irq_desc); + plat_irq_setup_pins(IRQ_MODE_IRQ); /* install handlers for IRQ0-7 */ } |
From: Magnus D. <mag...@gm...> - 2007-07-30 10:31:41
|
sh: intc - add support for SH7760 V2 This patch converts the cpu specific interrupt setup code for sh7760 from ipr + intc2 to intc. New vectors are also added to match the information provided by the datasheet. Vectors for IRQ4-IRQ7 are enabled by default. Use plat_irq_setup_pins() if pins IRL0-3 should be used in IRLM mode. The patch also adds the SIM block to the serial port platform data. Version two of this patch fixes MMCIF problems reported by Manuel Lauss. Signed-off-by: Magnus Damm <da...@ig...> --- arch/sh/kernel/cpu/sh4/setup-sh7760.c | 253 +++++++++++++++++++-------------- arch/sh/mm/Kconfig | 3 2 files changed, 147 insertions(+), 109 deletions(-) --- 0001/arch/sh/kernel/cpu/sh4/setup-sh7760.c +++ work/arch/sh/kernel/cpu/sh4/setup-sh7760.c 2007-07-30 12:15:31.000000000 +0900 @@ -12,6 +12,136 @@ #include <linux/serial.h> #include <asm/sci.h> +enum { + UNUSED = 0, + + /* interrupt sources */ + IRL0, IRL1, IRL2, IRL3, + HUDI, GPIOI, + DMAC_DMTE0, DMAC_DMTE1, DMAC_DMTE2, DMAC_DMTE3, + DMAC_DMTE4, DMAC_DMTE5, DMAC_DMTE6, DMAC_DMTE7, + DMAC_DMAE, + IRQ4, IRQ5, IRQ6, IRQ7, + HCAN20, HCAN21, + SSI0, SSI1, + HAC0, HAC1, + I2C0, I2C1, + USB, LCDC, + DMABRG0, DMABRG1, DMABRG2, + SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI, + SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI, + SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI, + SIM_ERI, SIM_RXI, SIM_TXI, SIM_TEI, + HSPI, + MMCIF0, MMCIF1, MMCIF2, MMCIF3, + MFI, ADC, CMT, + TMU0, TMU1, TMU2_TUNI, TMU2_TICPI, + WDT, + REF_RCMI, REF_ROVI, + + /* interrupt groups */ + DMAC, DMABRG, SCIF0, SCIF1, SCIF2, SIM, MMCIF, TMU2, REF, +}; + +static struct intc_vect vectors[] = { + INTC_VECT(HUDI, 0x600), INTC_VECT(GPIOI, 0x620), + INTC_VECT(DMAC_DMTE0, 0x640), INTC_VECT(DMAC_DMTE1, 0x660), + INTC_VECT(DMAC_DMTE2, 0x680), INTC_VECT(DMAC_DMTE3, 0x6a0), + INTC_VECT(DMAC_DMTE4, 0x780), INTC_VECT(DMAC_DMTE5, 0x7a0), + INTC_VECT(DMAC_DMTE6, 0x7c0), INTC_VECT(DMAC_DMTE7, 0x7e0), + INTC_VECT(DMAC_DMAE, 0x6c0), + INTC_VECT(IRQ4, 0x800), INTC_VECT(IRQ5, 0x820), + INTC_VECT(IRQ6, 0x840), INTC_VECT(IRQ6, 0x860), + INTC_VECT(HCAN20, 0x900), INTC_VECT(HCAN21, 0x920), + INTC_VECT(SSI0, 0x940), INTC_VECT(SSI1, 0x960), + INTC_VECT(HAC0, 0x980), INTC_VECT(HAC1, 0x9a0), + INTC_VECT(I2C0, 0x9c0), INTC_VECT(I2C1, 0x9e0), + INTC_VECT(USB, 0xa00), INTC_VECT(LCDC, 0xa20), + INTC_VECT(DMABRG0, 0xa80), INTC_VECT(DMABRG1, 0xaa0), + INTC_VECT(DMABRG2, 0xac0), + INTC_VECT(SCIF0_ERI, 0x880), INTC_VECT(SCIF0_RXI, 0x8a0), + INTC_VECT(SCIF0_BRI, 0x8c0), INTC_VECT(SCIF0_TXI, 0x8e0), + INTC_VECT(SCIF1_ERI, 0xb00), INTC_VECT(SCIF1_RXI, 0xb20), + INTC_VECT(SCIF1_BRI, 0xb40), INTC_VECT(SCIF1_TXI, 0xb60), + INTC_VECT(SCIF2_ERI, 0xb80), INTC_VECT(SCIF2_RXI, 0xba0), + INTC_VECT(SCIF2_BRI, 0xbc0), INTC_VECT(SCIF2_TXI, 0xbe0), + INTC_VECT(SIM_ERI, 0xc00), INTC_VECT(SIM_RXI, 0xc20), + INTC_VECT(SIM_TXI, 0xc40), INTC_VECT(SIM_TEI, 0xc60), + INTC_VECT(HSPI, 0xc80), + INTC_VECT(MMCIF0, 0xd00), INTC_VECT(MMCIF1, 0xd20), + INTC_VECT(MMCIF2, 0xd40), INTC_VECT(MMCIF3, 0xd60), + INTC_VECT(MFI, 0xe80), /* 0xf80 according to data sheet */ + INTC_VECT(ADC, 0xf80), INTC_VECT(CMT, 0xfa0), + INTC_VECT(TMU0, 0x400), INTC_VECT(TMU1, 0x420), + INTC_VECT(TMU2_TUNI, 0x440), INTC_VECT(TMU2_TICPI, 0x460), + INTC_VECT(WDT, 0x560), + INTC_VECT(REF_RCMI, 0x580), INTC_VECT(REF_ROVI, 0x5a0), +}; + +static struct intc_group groups[] = { + INTC_GROUP(DMAC, DMAC_DMTE0, DMAC_DMTE1, DMAC_DMTE2, + DMAC_DMTE3, DMAC_DMTE4, DMAC_DMTE5, + DMAC_DMTE6, DMAC_DMTE7, DMAC_DMAE), + INTC_GROUP(DMABRG, DMABRG0, DMABRG1, DMABRG2), + INTC_GROUP(SCIF0, SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI), + INTC_GROUP(SCIF1, SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI), + INTC_GROUP(SCIF2, SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI), + INTC_GROUP(SIM, SIM_ERI, SIM_RXI, SIM_TXI, SIM_TEI), + INTC_GROUP(MMCIF, MMCIF0, MMCIF1, MMCIF2, MMCIF3), + INTC_GROUP(TMU2, TMU2_TUNI, TMU2_TICPI), + INTC_GROUP(REF, REF_RCMI, REF_ROVI), +}; + +static struct intc_prio priorities[] = { + INTC_PRIO(SCIF0, 3), + INTC_PRIO(SCIF1, 3), + INTC_PRIO(SCIF2, 3), + INTC_PRIO(SIM, 3), + INTC_PRIO(DMAC, 7), + INTC_PRIO(DMABRG, 13), +}; + +static struct intc_mask_reg mask_registers[] = { + { 0xfe080040, 0xfe080060, 32, /* INTMSK00 / INTMSKCLR00 */ + { IRQ4, IRQ5, IRQ6, IRQ7, 0, 0, HCAN20, HCAN21, + SSI0, SSI1, HAC0, HAC1, I2C0, I2C1, USB, LCDC, + 0, DMABRG0, DMABRG1, DMABRG2, + SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI, + SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI, + SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI, } }, + { 0xfe080044, 0xfe080064, 32, /* INTMSK04 / INTMSKCLR04 */ + { 0, 0, 0, 0, 0, 0, 0, 0, + SIM_ERI, SIM_RXI, SIM_TXI, SIM_TEI, + HSPI, MMCIF0, MMCIF1, MMCIF2, + MMCIF3, 0, 0, 0, 0, 0, 0, 0, + 0, MFI, 0, 0, 0, 0, ADC, CMT, } }, +}; + +static struct intc_prio_reg prio_registers[] = { + { 0xffd00004, 16, 4, /* IPRA */ { TMU0, TMU1, TMU2 } }, + { 0xffd00008, 16, 4, /* IPRB */ { WDT, REF, 0, 0 } }, + { 0xffd0000c, 16, 4, /* IPRC */ { GPIOI, DMAC, 0, HUDI } }, + { 0xffd00010, 16, 4, /* IPRD */ { IRL0, IRL1, IRL2, IRL3 } }, + { 0xfe080000, 32, 4, /* INTPRI00 */ { IRQ4, IRQ5, IRQ6, IRQ7 } }, + { 0xfe080004, 32, 4, /* INTPRI04 */ { HCAN20, HCAN21, SSI0, SSI1, + HAC0, HAC1, I2C0, I2C1 } }, + { 0xfe080008, 32, 4, /* INTPRI08 */ { USB, LCDC, DMABRG, SCIF0, + SCIF1, SCIF2, SIM, HSPI } }, + { 0xfe08000c, 32, 4, /* INTPRI0C */ { 0, 0, MMCIF, 0, + MFI, 0, ADC, CMT } }, +}; + +static DECLARE_INTC_DESC(intc_desc, "sh7760", vectors, groups, + priorities, mask_registers, prio_registers, NULL); + +static struct intc_vect vectors_irq[] = { + INTC_VECT(IRL0, 0x240), INTC_VECT(IRL1, 0x2a0), + INTC_VECT(IRL2, 0x300), INTC_VECT(IRL3, 0x360), +}; + +static DECLARE_INTC_DESC(intc_desc_irq, "sh7760-irq", vectors_irq, groups, + priorities, mask_registers, prio_registers, NULL); + static struct plat_sci_port sci_platform_data[] = { { .mapbase = 0xfe600000, @@ -29,6 +159,11 @@ static struct plat_sci_port sci_platform .type = PORT_SCIF, .irqs = { 76, 77, 79, 78 }, }, { + .mapbase = 0xfe480000, + .flags = UPF_BOOT_AUTOCONF, + .type = PORT_SCI, + .irqs = { 80, 81, 82, 0 }, + }, { .flags = 0, } }; @@ -52,114 +187,18 @@ static int __init sh7760_devices_setup(v } __initcall(sh7760_devices_setup); -static struct intc2_data intc2_irq_table[] = { - {48, 0, 28, 0, 31, 3}, /* IRQ 4 */ - {49, 0, 24, 0, 30, 3}, /* IRQ 3 */ - {50, 0, 20, 0, 29, 3}, /* IRQ 2 */ - {51, 0, 16, 0, 28, 3}, /* IRQ 1 */ - {56, 4, 28, 0, 25, 3}, /* HCAN2_CHAN0 */ - {57, 4, 24, 0, 24, 3}, /* HCAN2_CHAN1 */ - {58, 4, 20, 0, 23, 3}, /* I2S_CHAN0 */ - {59, 4, 16, 0, 22, 3}, /* I2S_CHAN1 */ - {60, 4, 12, 0, 21, 3}, /* AC97_CHAN0 */ - {61, 4, 8, 0, 20, 3}, /* AC97_CHAN1 */ - {62, 4, 4, 0, 19, 3}, /* I2C_CHAN0 */ - {63, 4, 0, 0, 18, 3}, /* I2C_CHAN1 */ - {52, 8, 16, 0, 11, 3}, /* SCIF0_ERI_IRQ */ - {53, 8, 16, 0, 10, 3}, /* SCIF0_RXI_IRQ */ - {54, 8, 16, 0, 9, 3}, /* SCIF0_BRI_IRQ */ - {55, 8, 16, 0, 8, 3}, /* SCIF0_TXI_IRQ */ - {64, 8, 28, 0, 17, 3}, /* USBHI_IRQ */ - {65, 8, 24, 0, 16, 3}, /* LCDC */ - {68, 8, 20, 0, 14, 13}, /* DMABRGI0_IRQ */ - {69, 8, 20, 0, 13, 13}, /* DMABRGI1_IRQ */ - {70, 8, 20, 0, 12, 13}, /* DMABRGI2_IRQ */ - {72, 8, 12, 0, 7, 3}, /* SCIF1_ERI_IRQ */ - {73, 8, 12, 0, 6, 3}, /* SCIF1_RXI_IRQ */ - {74, 8, 12, 0, 5, 3}, /* SCIF1_BRI_IRQ */ - {75, 8, 12, 0, 4, 3}, /* SCIF1_TXI_IRQ */ - {76, 8, 8, 0, 3, 3}, /* SCIF2_ERI_IRQ */ - {77, 8, 8, 0, 2, 3}, /* SCIF2_RXI_IRQ */ - {78, 8, 8, 0, 1, 3}, /* SCIF2_BRI_IRQ */ - {79, 8, 8, 0, 0, 3}, /* SCIF2_TXI_IRQ */ - {80, 8, 4, 4, 23, 3}, /* SIM_ERI */ - {81, 8, 4, 4, 22, 3}, /* SIM_RXI */ - {82, 8, 4, 4, 21, 3}, /* SIM_TXI */ - {83, 8, 4, 4, 20, 3}, /* SIM_TEI */ - {84, 8, 0, 4, 19, 3}, /* HSPII */ - {88, 12, 20, 4, 18, 3}, /* MMCI0 */ - {89, 12, 20, 4, 17, 3}, /* MMCI1 */ - {90, 12, 20, 4, 16, 3}, /* MMCI2 */ - {91, 12, 20, 4, 15, 3}, /* MMCI3 */ - {92, 12, 12, 4, 6, 3}, /* MFI */ - {108,12, 4, 4, 1, 3}, /* ADC */ - {109,12, 0, 4, 0, 3}, /* CMTI */ -}; - -static struct intc2_desc intc2_irq_desc __read_mostly = { - .prio_base = 0xfe080000, - .msk_base = 0xfe080040, - .mskclr_base = 0xfe080060, - - .intc2_data = intc2_irq_table, - .nr_irqs = ARRAY_SIZE(intc2_irq_table), - - .chip = { - .name = "INTC2-sh7760", - }, -}; - -static struct ipr_data ipr_irq_table[] = { - /* IRQ, IPR-idx, shift, priority */ - { 16, 0, 12, 2 }, /* TMU0 TUNI*/ - { 17, 0, 8, 2 }, /* TMU1 TUNI */ - { 18, 0, 4, 2 }, /* TMU2 TUNI */ - { 19, 0, 4, 2 }, /* TMU2 TIPCI */ - { 27, 1, 12, 2 }, /* WDT ITI */ - { 28, 1, 8, 2 }, /* REF RCMI */ - { 29, 1, 8, 2 }, /* REF ROVI */ - { 32, 2, 0, 7 }, /* HUDI */ - { 33, 2, 12, 7 }, /* GPIOI */ - { 34, 2, 8, 7 }, /* DMAC DMTE0 */ - { 35, 2, 8, 7 }, /* DMAC DMTE1 */ - { 36, 2, 8, 7 }, /* DMAC DMTE2 */ - { 37, 2, 8, 7 }, /* DMAC DMTE3 */ - { 38, 2, 8, 7 }, /* DMAC DMAE */ - { 44, 2, 8, 7 }, /* DMAC DMTE4 */ - { 45, 2, 8, 7 }, /* DMAC DMTE5 */ - { 46, 2, 8, 7 }, /* DMAC DMTE6 */ - { 47, 2, 8, 7 }, /* DMAC DMTE7 */ -/* these here are only valid if INTC_ICR bit 7 is set to 1! - * XXX: maybe CONFIG_SH_IRLMODE symbol? SH7751 could use it too */ -#if 0 - { 2, 3, 12, 3 }, /* IRL0 */ - { 5, 3, 8, 3 }, /* IRL1 */ - { 8, 3, 4, 3 }, /* IRL2 */ - { 11, 3, 0, 3 }, /* IRL3 */ -#endif -}; - -static unsigned long ipr_offsets[] = { - 0xffd00004UL, /* 0: IPRA */ - 0xffd00008UL, /* 1: IPRB */ - 0xffd0000cUL, /* 2: IPRC */ - 0xffd00010UL, /* 3: IPRD */ -}; - -static struct ipr_desc ipr_irq_desc = { - .ipr_offsets = ipr_offsets, - .nr_offsets = ARRAY_SIZE(ipr_offsets), - - .ipr_data = ipr_irq_table, - .nr_irqs = ARRAY_SIZE(ipr_irq_table), - - .chip = { - .name = "IPR-sh7760", - }, -}; +void __init plat_irq_setup_pins(int mode) +{ + switch (mode) { + case IRQ_MODE_IRQ: + register_intc_controller(&intc_desc_irq); + break; + default: + BUG(); + } +} void __init plat_irq_setup(void) { - register_intc2_controller(&intc2_irq_desc); - register_ipr_controller(&ipr_irq_desc); + register_intc_controller(&intc_desc); } --- 0002/arch/sh/mm/Kconfig +++ work/arch/sh/mm/Kconfig 2007-07-30 12:15:22.000000000 +0900 @@ -156,8 +156,7 @@ config CPU_SUBTYPE_SH7751R config CPU_SUBTYPE_SH7760 bool "Support SH7760 processor" select CPU_SH4 - select CPU_HAS_INTC2_IRQ - select CPU_HAS_IPR_IRQ + select CPU_HAS_INTC_IRQ config CPU_SUBTYPE_SH4_202 bool "Support SH4-202 processor" |
From: Paul M. <le...@li...> - 2007-07-29 23:26:37
|
On Mon, Jul 30, 2007 at 12:05:31AM +0100, Adrian McMenamin wrote: > On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote: > > On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote: > > > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c > > > index 6334a4c..6f5e9e4 100644 > > > --- a/arch/sh/kernel/process.c > > > +++ b/arch/sh/kernel/process.c > > > @@ -97,6 +97,11 @@ void cpu_idle(void) > > > > > > void machine_restart(char * __unused) > > > { > > > + > > > +#ifdef CONFIG_SH_DREAMCAST > > > + /*reboot the Dreamcast under software control*/ > > > + writel(0x00007611, 0xA05F6890); > > > +#endif > > > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ > > > asm volatile("ldc %0, sr\n\t" > > > "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); > > > > No, if you want to do this, at least use a function pointer and leave > > this as the default implementation. The dreamcast presumably only needs > > this magic write anyways, rather than the SR.BL trick. > > > > Well, when I tested it, it did have a "return" in after the call and it > worked - but I took that out as it looked like code bloat to me :) > > Explain what you mean by using a function pointer and I'll do that. > Look at the other implementations that are overloaded by the boards. machine_power_off, the idle loop, etc. |
From: Adrian M. <ad...@ne...> - 2007-07-29 23:05:58
|
On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote: > On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote: > > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c > > index 6334a4c..6f5e9e4 100644 > > --- a/arch/sh/kernel/process.c > > +++ b/arch/sh/kernel/process.c > > @@ -97,6 +97,11 @@ void cpu_idle(void) > > > > void machine_restart(char * __unused) > > { > > + > > +#ifdef CONFIG_SH_DREAMCAST > > + /*reboot the Dreamcast under software control*/ > > + writel(0x00007611, 0xA05F6890); > > +#endif > > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ > > asm volatile("ldc %0, sr\n\t" > > "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); > > No, if you want to do this, at least use a function pointer and leave > this as the default implementation. The dreamcast presumably only needs > this magic write anyways, rather than the SR.BL trick. > Well, when I tested it, it did have a "return" in after the call and it worked - but I took that out as it looked like code bloat to me :) Explain what you mean by using a function pointer and I'll do that. Adrian |
From: Paul M. <le...@li...> - 2007-07-29 22:51:08
|
On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote: > diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c > index 6334a4c..6f5e9e4 100644 > --- a/arch/sh/kernel/process.c > +++ b/arch/sh/kernel/process.c > @@ -97,6 +97,11 @@ void cpu_idle(void) > > void machine_restart(char * __unused) > { > + > +#ifdef CONFIG_SH_DREAMCAST > + /*reboot the Dreamcast under software control*/ > + writel(0x00007611, 0xA05F6890); > +#endif > /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ > asm volatile("ldc %0, sr\n\t" > "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); No, if you want to do this, at least use a function pointer and leave this as the default implementation. The dreamcast presumably only needs this magic write anyways, rather than the SR.BL trick. |
From: Adrian M. <lkm...@gm...> - 2007-07-29 18:25:25
|
Apologies. I meant to cc: this to the lists first time round and appear to have bcc'ed it instead. ---------- Forwarded message ---------- From: Adrian McMenamin <lkm...@gm...> Date: 29-Jul-2007 19:04 Subject: [PATCH] Reboot Dreamcast under software control To: le...@li... In the light of more up to date technical information I have discovered there is a register at physical address 0x005F6890 on the Dreamcast that if written a magic number (0x00007611) will force a reboot under software control. Presumably a better option than the current catch-all mechanism. Signed-off by: Adrian McMenamin <ad...@mc...> diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c index 6334a4c..6f5e9e4 100644 --- a/arch/sh/kernel/process.c +++ b/arch/sh/kernel/process.c @@ -97,6 +97,11 @@ void cpu_idle(void) void machine_restart(char * __unused) { + +#ifdef CONFIG_SH_DREAMCAST + /*reboot the Dreamcast under software control*/ + writel(0x00007611, 0xA05F6890); +#endif /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ asm volatile("ldc %0, sr\n\t" "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); |
From: Adrian M. <lkm...@gm...> - 2007-07-29 18:04:27
|
In the light of more up to date technical information I have discovered there is a register at physical address 0x005F6890 on the Dreamcast that if written a magic number (0x00007611) will force a reboot under software control. Presumably a better option than the current catch-all mechanism. Signed-off by: Adrian McMenamin <ad...@mc...> diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c index 6334a4c..6f5e9e4 100644 --- a/arch/sh/kernel/process.c +++ b/arch/sh/kernel/process.c @@ -97,6 +97,11 @@ void cpu_idle(void) void machine_restart(char * __unused) { + +#ifdef CONFIG_SH_DREAMCAST + /*reboot the Dreamcast under software control*/ + writel(0x00007611, 0xA05F6890); +#endif /* SR.BL=1 and invoke address error to let CPU reset (manual reset) */ asm volatile("ldc %0, sr\n\t" "mov.l @%1, %0" : : "r" (0x10000000), "r" (0x80000001)); |
From: Adrian M. <lkm...@gm...> - 2007-07-29 10:36:09
|
I sent this patch to lkml, but not the list - it fixes pvr2 video modes - a fair bit of it is Antonio's (see http://lkml.org/lkml/2007/7/28/182 for the full explanation) ---------- Forwarded message ---------- From: Adrian McMenamin <lkm...@gm...> Date: 29-Jul-2007 01:45 Subject: Re: [PATCH] Framebuffer: Consolidated cleanup of pvr2fb.c for Sega Dreamcast To: "Antonino A. Daplas" <ad...@gm...> Cc: le...@li..., lin...@vg..., Ondrej Zajicek <san...@cr...> On 29/07/07, Adrian McMenamin <lkm...@gm...> wrote: > Tony, > > Second time attempt at this and a much better job I think. > Sorry, given I've jsut said this *does* work at 24bpp and 32bpp I'd better clean up the Documentation patch,,, |
From: Jamie L. <le...@tw...> - 2007-07-29 02:54:48
|
On Wed, Jul 25, 2007 at 12:44:04PM +0900, Magnus Damm wrote: [...] > Also, the cpu-specific interrupt code has been rewritten for > 2.6.23-rc1. The new code seems to work just fine on the r2d board, but > it wouldn't hurt with some testing on other 7750-ish boards. I've just tested 2.6.23-rc1-ge8a53af7 (lastest sh-2.6.git) on the titan 7751R board and everything looks to be working just fine. Also the "sh: Add kmap_coherent()/kunmap_coherent() interface for SH-4" change has fixed the "scheduling while atomic" messages I was seeing when running from NFS-root. boot log: http://twibble.org/dist/misc/titan-boot-ge8a53af7.txt config: http://twibble.org/dist/misc/titan-config-ge8a53af7.txt Thanks. -- Jamie Lenehan <le...@tw...> |
From: Manuel L. <ma...@ro...> - 2007-07-27 04:52:57
|
Hi Magnus, > >New behavior -- unless all 4 of the grouped MMCIF irqs are requested, > >none trigger. They show up in /proc/interrupts but count does not change. > > I have two ideas: > > 1. Please try to add MMCIF3 to mask_registers[]. I must have missed > that one. The "0" after MMCIF2 should be replaced with MMCIF3. This is > a pretty obvious miss that I made when I created the tables from the > data sheet. I hope that this fix helps. Yes that fixed it! Thanks, Manuel Lauss |
From: David M. <Dav...@se...> - 2007-07-26 23:26:51
|
Jivin Paul Mundt lays it down ... > On Thu, Jul 26, 2007 at 04:21:01PM +1000, David McCullough wrote: > > Jivin Paul Mundt lays it down ... > > > On Thu, Jul 26, 2007 at 03:27:13PM +1000, David McCullough wrote: > > > > Add support for copying our filesystem out of the way when images are > > > > constructed by concatenating the root filesystem to the end of a linux.bin > > > > which has the BSS removed (to save space). > > > > > > That's an interesting abuse :-) > > > > It's a very old thing, our images from the beginning of time have been > > like this. If you don't like it, no problems, you can get around it > > by making images with the BSS included in the linux.bin. > > Besides the watchdog cruft, I don't particularly have a problem with it. > I'll certainly accept patches for the functionality, although it will be > for 2.6.24. No problems, I'll go through and clean as much as this as I can and keep dropping bits on you. Is the format ok ? Anything perferred ? > > > CONFIG_SH_ROMBOOT is not added by any of your patches, likewise for > > > _mem_start and _rom_store. Presumably this should be sent as a follow up > > > patch if you want this functionality included. > > > > My BAD, the CONFIG_SH_ROMBOOT was contributed by someone else and since > > we don't use it, I didn't need all the other bits to make it go. > > > > I'll fix this if you think the "strange romfs thing" is acceptable in > > some shape or form. > > If there are sufficient users of this feature, then I don't have a > problem with merging it. If you aren't using romboot at all, then just > drop that from the update. I have the code needed to make it work, but we haven't used it at all. I can contact the guy who sent it in and see if they would like to push it in themselves. > > > > + /* copy backwards to avoid writing over ourselves */ > > > > + arch_service_watchdog(); > > > > + while (dp >= ((unsigned char *) (&_end[0]))) { > > > > + *dp-- = *sp--; > > > > + if ((((unsigned long) dp) & 0x7ffff) == 0) > > > > + arch_service_watchdog(); > > > > + } > > > > + arch_service_watchdog(); > > > > +} > > > > > > Can you not simply disable the watchdog in your loader and start it up > > > from the board code? Having to do dummy reads from the thing in this > > > convoluted manner is rather undesirable. > > > > The watchdog is on from poweron, it cannot be disabled in any possible > > way. You have at most 1 second (or less on some versions) to service it or > > it resets the hardware. > > Then perhaps we should just be abstracting out the romfs copy. ie, have > the generic copy_romfs() (possibly renamed to something more reasonable) > take care of extracting all of the various image details, and then kick > the addresses down to a platform-specific symbol to do the actual copy. > This too can be a weak symbol, where the default implementation simply > does the copy without the watchdog noise. > > This way you can keep all of your platform-specific cruft isolated > without making a compromise on functionality. That I can do. So putting all the special cases into the boards/snapgear area is the preferred option ? I'll have a go and see what it looks like. Hopefully some more patches soon ;-) Thanks, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
From: Magnus D. <mag...@gm...> - 2007-07-26 16:56:11
|
Hi again Manuel, On 7/25/07, Manuel Lauss <ma...@ro...> wrote: > On Wed, Jul 25, 2007 at 11:16:39PM +0900, Magnus Damm wrote: > > On 7/25/07, Manuel Lauss <ma...@ro...> wrote: > > > On Wed, Jul 25, 2007 at 10:17:39PM +0900, Magnus Damm wrote: > > > > sh: intc - add support for SH7760 > > > > > > > + INTC_GROUP(MMCIF, MMCIF0, MMCIF1, MMCIF2, MMCIF3), > > > > > > With this patch my mmcif driver not longer works, since no > > > mmcif irq is generated. In the driver I only request > > > MMCIF0-2; MMCIF3 is unused. Does the grouping above mask all > > > grouped IRQs unless all have been enabled/requested? > > > > It should be possible to request a single interrupt only. > > > > The grouping is there because the priority value is shared between all > > MMCIF interrupts. We need some way to tell the intc code which > > interrupt sources that are bundled together, and that's what the > > groups are used for. > > > > The sh7780 device supports both masking with both priorities and > > bitmaps. The common intc code should prefer to use the per-interrupt > > source bitmap for MMCIF0-3 over the priority group to mask and unmask. > > So interrupts should be masked per-interrupt source for MMCIF. > > > > So.. are things working as before, or have i mistakenly introduced > > some new behavior? =) > > New behavior -- unless all 4 of the grouped MMCIF irqs are requested, > none trigger. They show up in /proc/interrupts but count does not change. I have two ideas: 1. Please try to add MMCIF3 to mask_registers[]. I must have missed that one. The "0" after MMCIF2 should be replaced with MMCIF3. This is a pretty obvious miss that I made when I created the tables from the data sheet. I hope that this fix helps. 2. If number 1 above doesn't help, please try replacing all MMCIF0-3 with 0 in mask_registers[]. That should force masking via the priority register. Could you please check if the ideas above help? Number 1 is preferred over 2. Thanks! / magnus |
From: Magnus D. <mag...@gm...> - 2007-07-26 14:53:53
|
sh: add on board ethernet support for r7785rp board This patch glues together various kernel components to get the on board ethernet controller working on a Highlander sh7785 board. The following kernel areas are affected: - Board specific SuperH code - The aX88796 driver - The eeprom_93cx6 driver The patch is not that polished, but my intention with posting it in this condition is to get it out there and let you guys comment. The patch works just fine for me, but if someone else happen to have a Highlander sh7785 please test and report back. Open questions / issues: - Using the eeprom_93cx6 driver seems like a good idea to me. Or? - Is the Kconfig option CONFIG_AX88796_93CX6 the right way to go? - I'd like to add Highlander sh7780 support as well, but need a working board. - readsl() and writesl() already exists, but doesn't use machvec. Hm.. Thanks. Signed-off-by: Magnus Damm <da...@ig...> --- Tested on a Highlander sh7785 board. arch/sh/boards/renesas/r7780rp/setup.c | 39 +++++++++++++++++++++++++ drivers/net/Kconfig | 9 +++++ drivers/net/ax88796.c | 49 ++++++++++++++++++++++++++++++++ include/asm-sh/io.h | 28 ++++++++++++++++++ include/linux/eeprom_93cx6.h | 3 + include/net/ax88796.h | 1 6 files changed, 127 insertions(+), 2 deletions(-) --- 0001/arch/sh/boards/renesas/r7780rp/setup.c +++ work/arch/sh/boards/renesas/r7780rp/setup.c 2007-07-26 20:04:32.000000000 +0900 @@ -20,6 +20,7 @@ #include <asm/r7780rp.h> #include <asm/clock.h> #include <asm/io.h> +#include <net/ax88796.h> static struct resource r8a66597_usb_host_resources[] = { [0] = { @@ -132,11 +133,49 @@ static struct platform_device heartbeat_ .resource = heartbeat_resources, }; +#ifdef CONFIG_SH_R7785RP +static struct ax_plat_data ax88796_platdata = { + .flags = AXFLG_HAS_93CX6, + .wordlength = 2, + .dcr_val = 0x1, + .rcr_val = 0x40, +}; + +static struct resource ax88796_resources[] = { + [0] = { + .start = 0xa4100400, + .end = 0xa4100400 + (0x20 * 0x2) - 1, + .flags = IORESOURCE_MEM, + }, + + [1] = { + .start = 10, + .end = 10, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device ax88796_device = { + .name = "ax88796", + .id = 0, + + .dev = { + .platform_data = &ax88796_platdata, + }, + + .num_resources = ARRAY_SIZE(ax88796_resources), + .resource = ax88796_resources, +}; +#endif + static struct platform_device *r7780rp_devices[] __initdata = { &r8a66597_usb_host_device, &m66592_usb_peripheral_device, &cf_ide_device, &heartbeat_device, +#ifdef CONFIG_SH_R7785RP + &ax88796_device, +#endif }; static int __init r7780rp_devices_setup(void) --- 0001/drivers/net/Kconfig +++ work/drivers/net/Kconfig 2007-07-26 19:59:25.000000000 +0900 @@ -218,13 +218,20 @@ source "drivers/net/arm/Kconfig" config AX88796 tristate "ASIX AX88796 NE2000 clone support" - depends on ARM || MIPS + depends on ARM || MIPS || SUPERH select CRC32 select MII help AX88796 driver, using platform bus to provide chip detection and resources +config AX88796_93CX6 + bool "ASIX AX88796 external 93CX6 eeprom support" + depends on AX88796 + select EEPROM_93CX6 + help + Select this if your platform comes with an external 93CX6 eeprom. + config MACE tristate "MACE (Power Mac ethernet) support" depends on PPC_PMAC && PPC32 --- 0001/drivers/net/ax88796.c +++ work/drivers/net/ax88796.c 2007-07-26 20:02:25.000000000 +0900 @@ -24,6 +24,7 @@ #include <linux/etherdevice.h> #include <linux/ethtool.h> #include <linux/mii.h> +#include <linux/eeprom_93cx6.h> #include <net/ax88796.h> @@ -583,6 +584,37 @@ static const struct ethtool_ops ax_ethto .get_perm_addr = ethtool_op_get_perm_addr, }; +#ifdef CONFIG_AX88796_93CX6 +static void ax_eeprom_register_read(struct eeprom_93cx6 *eeprom) +{ + struct ei_device *ei_local = eeprom->data; + u8 reg = ei_inb(ei_local->mem + AX_MEMR); + + eeprom->reg_data_in = reg & AX_MEMR_EEI; + eeprom->reg_data_out = reg & AX_MEMR_EEO; /* Input pin */ + eeprom->reg_data_clock = reg & AX_MEMR_EECLK; + eeprom->reg_chip_select = reg & AX_MEMR_EECS; +} + +static void ax_eeprom_register_write(struct eeprom_93cx6 *eeprom) +{ + struct ei_device *ei_local = eeprom->data; + u8 reg = ei_inb(ei_local->mem + AX_MEMR); + + reg &= ~(AX_MEMR_EEI | AX_MEMR_EECLK | AX_MEMR_EECS); + + if (eeprom->reg_data_in) + reg |= AX_MEMR_EEI; + if (eeprom->reg_data_clock) + reg |= AX_MEMR_EECLK; + if (eeprom->reg_chip_select) + reg |= AX_MEMR_EECS; + + ei_outb(reg, ei_local->mem + AX_MEMR); + udelay(10); +} +#endif + /* setup code */ static void ax_initial_setup(struct net_device *dev, struct ei_device *ei_local) @@ -641,6 +673,23 @@ static int ax_init_dev(struct net_device memcpy(dev->dev_addr, SA_prom, 6); } +#ifdef CONFIG_AX88796_93CX6 + if (first_init && ax->plat->flags & AXFLG_HAS_93CX6) { + unsigned char mac_addr[6]; + struct eeprom_93cx6 eeprom; + + eeprom.data = ei_local; + eeprom.register_read = ax_eeprom_register_read; + eeprom.register_write = ax_eeprom_register_write; + eeprom.width = PCI_EEPROM_WIDTH_93C56B; + + eeprom_93cx6_multiread(&eeprom, 0, + (__le16 __force *)mac_addr, + sizeof(mac_addr) >> 1); + + memcpy(dev->dev_addr, mac_addr, 6); + } +#endif if (ax->plat->wordlength == 2) { /* We must set the 8390 for word mode. */ ei_outb(ax->plat->dcr_val, ei_local->mem + EN0_DCFG); --- 0001/include/asm-sh/io.h +++ work/include/asm-sh/io.h 2007-07-26 15:07:23.000000000 +0900 @@ -138,6 +138,34 @@ void __raw_readsl(unsigned long addr, vo #define writesl __raw_writesl #define readsl __raw_readsl +#define __BUILD_MEMORY_STRING(bwlq, type) \ + \ +static inline void writes##bwlq(volatile void __iomem *mem, \ + const void *addr, unsigned int count) \ +{ \ + const volatile type *__addr = addr; \ + \ + while (count--) { \ + __raw_write##bwlq(*__addr, mem); \ + __addr++; \ + } \ +} \ + \ +static inline void reads##bwlq(volatile void __iomem *mem, void *addr, \ + unsigned int count) \ +{ \ + volatile type *__addr = addr; \ + \ + while (count--) { \ + *__addr = __raw_read##bwlq(mem); \ + __addr++; \ + } \ +} + +__BUILD_MEMORY_STRING(b, u8) +__BUILD_MEMORY_STRING(w, u16) +//BUILD_MEMORY_STRING(l, u32) + #define readb_relaxed(a) readb(a) #define readw_relaxed(a) readw(a) #define readl_relaxed(a) readl(a) --- 0001/include/linux/eeprom_93cx6.h +++ work/include/linux/eeprom_93cx6.h 2007-07-26 19:55:29.000000000 +0900 @@ -21,13 +21,14 @@ /* Module: eeprom_93cx6 Abstract: EEPROM reader datastructures for 93cx6 chipsets. - Supported chipsets: 93c46 & 93c66. + Supported chipsets: 93c46, 93c56B and 93c66. */ /* * EEPROM operation defines. */ #define PCI_EEPROM_WIDTH_93C46 6 +#define PCI_EEPROM_WIDTH_93C56B 8 #define PCI_EEPROM_WIDTH_93C66 8 #define PCI_EEPROM_WIDTH_OPCODE 3 #define PCI_EEPROM_WRITE_OPCODE 0x05 --- 0001/include/net/ax88796.h +++ work/include/net/ax88796.h 2007-07-26 19:56:58.000000000 +0900 @@ -14,6 +14,7 @@ #define AXFLG_HAS_EEPROM (1<<0) #define AXFLG_MAC_FROMDEV (1<<1) /* device already has MAC */ +#define AXFLG_HAS_93CX6 (1<<2) /* use eeprom_93cx6 driver */ struct ax_plat_data { unsigned int flags; |
From: Magnus D. <mag...@gm...> - 2007-07-26 14:33:58
|
sh: intc - add support for SH7785 This patch converts the cpu specific interrupt setup code for sh7785 from intc2 to intc. New vectors are also added to match the information provided by the datasheet. No IRQ/IRL pin vectors are enabled by default. Use plat_irq_setup_pins() to select between IRL and IRQ mode. Signed-off-by: Magnus Damm <da...@ig...> --- Tested on a Highlander 7785 board. arch/sh/kernel/cpu/sh4a/setup-sh7785.c | 261 +++++++++++++++++++++++++++----- arch/sh/mm/Kconfig | 2 include/asm-sh/hw_irq.h | 3 3 files changed, 228 insertions(+), 38 deletions(-) --- 0001/arch/sh/kernel/cpu/sh4a/setup-sh7785.c +++ work/arch/sh/kernel/cpu/sh4a/setup-sh7785.c 2007-07-26 22:39:27.000000000 +0900 @@ -72,46 +72,235 @@ static int __init sh7785_devices_setup(v } __initcall(sh7785_devices_setup); -static struct intc2_data intc2_irq_table[] = { - { 28, 0, 24, 0, 0, 2 }, /* TMU0 */ +enum { + UNUSED = 0, - { 40, 8, 24, 0, 2, 3 }, /* SCIF0 ERI */ - { 41, 8, 24, 0, 2, 3 }, /* SCIF0 RXI */ - { 42, 8, 24, 0, 2, 3 }, /* SCIF0 BRI */ - { 43, 8, 24, 0, 2, 3 }, /* SCIF0 TXI */ - - { 44, 8, 16, 0, 3, 3 }, /* SCIF1 ERI */ - { 45, 8, 16, 0, 3, 3 }, /* SCIF1 RXI */ - { 46, 8, 16, 0, 3, 3 }, /* SCIF1 BRI */ - { 47, 8, 16, 0, 3, 3 }, /* SCIF1 TXI */ - - { 64, 0x14, 8, 0, 14, 2 }, /* PCIC0 */ - { 65, 0x14, 0, 0, 15, 2 }, /* PCIC1 */ - { 66, 0x18, 24, 0, 16, 2 }, /* PCIC2 */ - { 67, 0x18, 16, 0, 17, 2 }, /* PCIC3 */ - { 68, 0x18, 8, 0, 18, 2 }, /* PCIC4 */ - - { 60, 8, 8, 0, 4, 3 }, /* SCIF2 ERI, RXI, BRI, TXI */ - { 60, 8, 0, 0, 5, 3 }, /* SCIF3 ERI, RXI, BRI, TXI */ - { 60, 12, 24, 0, 6, 3 }, /* SCIF4 ERI, RXI, BRI, TXI */ - { 60, 12, 16, 0, 7, 3 }, /* SCIF5 ERI, RXI, BRI, TXI */ -}; - -static struct intc2_desc intc2_irq_desc __read_mostly = { - .prio_base = 0xffd40000, - .msk_base = 0xffd40038, - .mskclr_base = 0xffd4003c, - - .intc2_data = intc2_irq_table, - .nr_irqs = ARRAY_SIZE(intc2_irq_table), - - .chip = { - .name = "INTC2-sh7785", - }, + /* interrupt sources */ + + IRL0_LLLL, IRL0_LLLH, IRL0_LLHL, IRL0_LLHH, + IRL0_LHLL, IRL0_LHLH, IRL0_LHHL, IRL0_LHHH, + IRL0_HLLL, IRL0_HLLH, IRL0_HLHL, IRL0_HLHH, + IRL0_HHLL, IRL0_HHLH, IRL0_HHHL, + + IRL4_LLLL, IRL4_LLLH, IRL4_LLHL, IRL4_LLHH, + IRL4_LHLL, IRL4_LHLH, IRL4_LHHL, IRL4_LHHH, + IRL4_HLLL, IRL4_HLLH, IRL4_HLHL, IRL4_HLHH, + IRL4_HHLL, IRL4_HHLH, IRL4_HHHL, + + IRQ0, IRQ1, IRQ2, IRQ3, IRQ4, IRQ5, IRQ6, IRQ7, + WDT, + TMU0, TMU1, TMU2, TMU2_TICPI, + HUDI, + DMAC0_DMINT0, DMAC0_DMINT1, DMAC0_DMINT2, DMAC0_DMINT3, + DMAC0_DMINT4, DMAC0_DMINT5, DMAC0_DMAE, + SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI, + SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI, + DMAC1_DMINT6, DMAC1_DMINT7, DMAC1_DMINT8, DMAC1_DMINT9, + DMAC1_DMINT10, DMAC1_DMINT11, DMAC1_DMAE, + HSPI, + SCIF2, SCIF3, SCIF4, SCIF5, + PCISERR, PCIINTA, PCIINTB, PCIINTC, PCIINTD, + PCIERR, PCIPWD3, PCIPWD2, PCIPWD1, PCIPWD0, + SIOF, + MMCIF_FSTAT, MMCIF_TRAN, MMCIF_ERR, MMCIF_FRDY, + DU, + GDTA_GACLI, GDTA_GAMCI, GDTA_GAERI, + TMU3, TMU4, TMU5, + SSI0, SSI1, + HAC0, HAC1, + FLCTL_FLSTE, FLCTL_FLEND, FLCTL_FLTRQ0, FLCTL_FLTRQ1, + GPIOI0, GPIOI1, GPIOI2, GPIOI3, + + /* interrupt groups */ + + TMU012, DMAC0, SCIF0, SCIF1, DMAC1, + PCIC5, MMCIF, GDTA, TMU345, FLCTL, GPIO +}; + +static struct intc_vect vectors[] = { + INTC_VECT(WDT, 0x560), + INTC_VECT(TMU0, 0x580), INTC_VECT(TMU1, 0x5a0), + INTC_VECT(TMU2, 0x5c0), INTC_VECT(TMU2_TICPI, 0x5e0), + INTC_VECT(HUDI, 0x600), + INTC_VECT(DMAC0_DMINT0, 0x620), INTC_VECT(DMAC0_DMINT1, 0x640), + INTC_VECT(DMAC0_DMINT2, 0x660), INTC_VECT(DMAC0_DMINT3, 0x680), + INTC_VECT(DMAC0_DMINT4, 0x6a0), INTC_VECT(DMAC0_DMINT5, 0x6c0), + INTC_VECT(DMAC0_DMAE, 0x6e0), + INTC_VECT(SCIF0_ERI, 0x700), INTC_VECT(SCIF0_RXI, 0x720), + INTC_VECT(SCIF0_BRI, 0x740), INTC_VECT(SCIF0_TXI, 0x760), + INTC_VECT(SCIF1_ERI, 0x780), INTC_VECT(SCIF1_RXI, 0x7a0), + INTC_VECT(SCIF1_BRI, 0x7c0), INTC_VECT(SCIF1_TXI, 0x7e0), + INTC_VECT(DMAC1_DMINT6, 0x880), INTC_VECT(DMAC1_DMINT7, 0x8a0), + INTC_VECT(DMAC1_DMINT8, 0x8c0), INTC_VECT(DMAC1_DMINT9, 0x8e0), + INTC_VECT(DMAC1_DMINT10, 0x900), INTC_VECT(DMAC1_DMINT11, 0x920), + INTC_VECT(DMAC1_DMAE, 0x940), + INTC_VECT(HSPI, 0x960), + INTC_VECT(SCIF2, 0x980), INTC_VECT(SCIF3, 0x9a0), + INTC_VECT(SCIF4, 0x9c0), INTC_VECT(SCIF5, 0x9e0), + INTC_VECT(PCISERR, 0xa00), INTC_VECT(PCIINTA, 0xa20), + INTC_VECT(PCIINTB, 0xa40), INTC_VECT(PCIINTC, 0xa60), + INTC_VECT(PCIINTD, 0xa80), INTC_VECT(PCIERR, 0xaa0), + INTC_VECT(PCIPWD3, 0xac0), INTC_VECT(PCIPWD2, 0xae0), + INTC_VECT(PCIPWD1, 0xb00), INTC_VECT(PCIPWD0, 0xb20), + INTC_VECT(SIOF, 0xc00), + INTC_VECT(MMCIF_FSTAT, 0xd00), INTC_VECT(MMCIF_TRAN, 0xd20), + INTC_VECT(MMCIF_ERR, 0xd40), INTC_VECT(MMCIF_FRDY, 0xd60), + INTC_VECT(DU, 0xd80), + INTC_VECT(GDTA_GACLI, 0xda0), INTC_VECT(GDTA_GAMCI, 0xdc0), + INTC_VECT(GDTA_GAERI, 0xde0), + INTC_VECT(TMU3, 0xe00), INTC_VECT(TMU4, 0xe20), + INTC_VECT(TMU5, 0xe40), + INTC_VECT(SSI0, 0xe80), INTC_VECT(SSI1, 0xea0), + INTC_VECT(HAC0, 0xec0), INTC_VECT(HAC1, 0xee0), + INTC_VECT(FLCTL_FLSTE, 0xf00), INTC_VECT(FLCTL_FLEND, 0xf20), + INTC_VECT(FLCTL_FLTRQ0, 0xf40), INTC_VECT(FLCTL_FLTRQ1, 0xf60), + INTC_VECT(GPIOI0, 0xf80), INTC_VECT(GPIOI1, 0xfa0), + INTC_VECT(GPIOI2, 0xfc0), INTC_VECT(GPIOI3, 0xfe0), +}; + +static struct intc_group groups[] = { + INTC_GROUP(TMU012, TMU0, TMU1, TMU2, TMU2_TICPI), + INTC_GROUP(DMAC0, DMAC0_DMINT0, DMAC0_DMINT1, DMAC0_DMINT2, + DMAC0_DMINT3, DMAC0_DMINT4, DMAC0_DMINT5, DMAC0_DMAE), + INTC_GROUP(SCIF0, SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI), + INTC_GROUP(SCIF1, SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI), + INTC_GROUP(DMAC1, DMAC1_DMINT6, DMAC1_DMINT7, DMAC1_DMINT8, + DMAC1_DMINT9, DMAC1_DMINT10, DMAC1_DMINT11, DMAC1_DMAE), + INTC_GROUP(PCIC5, PCIERR, PCIPWD3, PCIPWD2, PCIPWD1, PCIPWD0), + INTC_GROUP(MMCIF, MMCIF_FSTAT, MMCIF_TRAN, MMCIF_ERR, MMCIF_FRDY), + INTC_GROUP(GDTA, GDTA_GACLI, GDTA_GAMCI, GDTA_GAERI), + INTC_GROUP(TMU345, TMU3, TMU4, TMU5), + INTC_GROUP(FLCTL, FLCTL_FLSTE, FLCTL_FLEND, + FLCTL_FLTRQ0, FLCTL_FLTRQ1), + INTC_GROUP(GPIO, GPIOI0, GPIOI1, GPIOI2, GPIOI3), +}; + +static struct intc_prio priorities[] = { + INTC_PRIO(SCIF0, 3), + INTC_PRIO(SCIF1, 3), + INTC_PRIO(SCIF2, 3), + INTC_PRIO(SCIF3, 3), + INTC_PRIO(SCIF4, 3), + INTC_PRIO(SCIF5, 3), +}; + +static struct intc_mask_reg mask_registers[] = { + { 0xffd00044, 0xffd00064, 32, /* INTMSK0 / INTMSKCLR0 */ + { IRQ0, IRQ1, IRQ2, IRQ3, IRQ4, IRQ5, IRQ6, IRQ7 } }, + + { 0xffd40080, 0xffd40084, 32, /* INTMSK2 / INTMSKCLR2 */ + { IRL0_LLLL, IRL0_LLLH, IRL0_LLHL, IRL0_LLHH, + IRL0_LHLL, IRL0_LHLH, IRL0_LHHL, IRL0_LHHH, + IRL0_HLLL, IRL0_HLLH, IRL0_HLHL, IRL0_HLHH, + IRL0_HHLL, IRL0_HHLH, IRL0_HHHL, 0, + IRL4_LLLL, IRL4_LLLH, IRL4_LLHL, IRL4_LLHH, + IRL4_LHLL, IRL4_LHLH, IRL4_LHHL, IRL4_LHHH, + IRL4_HLLL, IRL4_HLLH, IRL4_HLHL, IRL4_HLHH, + IRL4_HHLL, IRL4_HHLH, IRL4_HHHL, 0, } }, + + { 0xffd40038, 0xffd4003c, 32, /* INT2MSKR / INT2MSKCR */ + { 0, 0, 0, GDTA, DU, SSI0, SSI1, GPIO, + FLCTL, MMCIF, HSPI, SIOF, PCIC5, PCIINTD, PCIINTC, PCIINTB, + PCIINTA, PCISERR, HAC1, HAC0, DMAC1, DMAC0, HUDI, WDT, + SCIF5, SCIF4, SCIF3, SCIF2, SCIF1, SCIF0, TMU345, TMU012 } }, +}; + +static struct intc_prio_reg prio_registers[] = { + { 0xffd00010, 32, 4, /* INTPRI */ { IRQ0, IRQ1, IRQ2, IRQ3, + IRQ4, IRQ5, IRQ6, IRQ7 } }, + { 0xffd40000, 32, 8, /* INT2PRI0 */ { TMU0, TMU1, TMU2, TMU2_TICPI } }, + { 0xffd40004, 32, 8, /* INT2PRI1 */ { TMU3, TMU4, TMU5, } }, + { 0xffd40008, 32, 8, /* INT2PRI2 */ { SCIF0, SCIF1, SCIF2, SCIF3 } }, + { 0xffd4000c, 32, 8, /* INT2PRI3 */ { SCIF4, SCIF5, WDT, } }, + { 0xffd40010, 32, 8, /* INT2PRI4 */ { HUDI, DMAC0, DMAC1, } }, + { 0xffd40014, 32, 8, /* INT2PRI5 */ { HAC0, HAC1, PCISERR, PCIINTA } }, + { 0xffd40018, 32, 8, /* INT2PRI6 */ { PCIINTB, PCIINTC, + PCIINTD, PCIC5 } }, + { 0xffd4001c, 32, 8, /* INT2PRI7 */ { SIOF, HSPI, MMCIF, } }, + { 0xffd40020, 32, 8, /* INT2PRI8 */ { FLCTL, GPIO, SSI0, SSI1, } }, + { 0xffd40024, 32, 8, /* INT2PRI9 */ { DU, GDTA, } }, +}; + +static DECLARE_INTC_DESC(intc_desc, "sh7785", vectors, groups, priorities, + mask_registers, prio_registers, NULL); + + +/* Support for external interrupt pins in IRQ mode */ + +static struct intc_vect vectors_irq0123[] = { + INTC_VECT(IRQ0, 0x240), INTC_VECT(IRQ1, 0x280), + INTC_VECT(IRQ2, 0x2c0), INTC_VECT(IRQ3, 0x300), +}; + +static struct intc_vect vectors_irq4567[] = { + INTC_VECT(IRQ4, 0x340), INTC_VECT(IRQ5, 0x380), + INTC_VECT(IRQ6, 0x3c0), INTC_VECT(IRQ7, 0x200), +}; + +static struct intc_sense_reg sense_registers[] = { + { 0xffd0001c, 32, 2, /* ICR1 */ { IRQ0, IRQ1, IRQ2, IRQ3, + IRQ4, IRQ5, IRQ6, IRQ7 } }, }; +static DECLARE_INTC_DESC(intc_desc_irq0123, "sh7785-irq0123", vectors_irq0123, + NULL, NULL, mask_registers, prio_registers, + sense_registers); + +static DECLARE_INTC_DESC(intc_desc_irq4567, "sh7785-irq4567", vectors_irq4567, + NULL, NULL, mask_registers, prio_registers, + sense_registers); + +/* External interrupt pins in IRL mode */ + +static struct intc_vect vectors_irl0123[] = { + INTC_VECT(IRL0_LLLL, 0x200), INTC_VECT(IRL0_LLLH, 0x220), + INTC_VECT(IRL0_LLHL, 0x240), INTC_VECT(IRL0_LLHH, 0x260), + INTC_VECT(IRL0_LHLL, 0x280), INTC_VECT(IRL0_LHLH, 0x2a0), + INTC_VECT(IRL0_LHHL, 0x2c0), INTC_VECT(IRL0_LHHH, 0x2e0), + INTC_VECT(IRL0_HLLL, 0x300), INTC_VECT(IRL0_HLLH, 0x320), + INTC_VECT(IRL0_HLHL, 0x340), INTC_VECT(IRL0_HLHH, 0x360), + INTC_VECT(IRL0_HHLL, 0x380), INTC_VECT(IRL0_HHLH, 0x3a0), + INTC_VECT(IRL0_HHHL, 0x3c0), +}; + +static struct intc_vect vectors_irl4567[] = { + INTC_VECT(IRL4_LLLL, 0xb00), INTC_VECT(IRL4_LLLH, 0xb20), + INTC_VECT(IRL4_LLHL, 0xb40), INTC_VECT(IRL4_LLHH, 0xb60), + INTC_VECT(IRL4_LHLL, 0xb80), INTC_VECT(IRL4_LHLH, 0xba0), + INTC_VECT(IRL4_LHHL, 0xbc0), INTC_VECT(IRL4_LHHH, 0xbe0), + INTC_VECT(IRL4_HLLL, 0xc00), INTC_VECT(IRL4_HLLH, 0xc20), + INTC_VECT(IRL4_HLHL, 0xc40), INTC_VECT(IRL4_HLHH, 0xc60), + INTC_VECT(IRL4_HHLL, 0xc80), INTC_VECT(IRL4_HHLH, 0xca0), + INTC_VECT(IRL4_HHHL, 0xcc0), +}; + +static DECLARE_INTC_DESC(intc_desc_irl0123, "sh7785-irl0123", vectors_irl0123, + NULL, NULL, mask_registers, NULL, NULL); + +static DECLARE_INTC_DESC(intc_desc_irl4567, "sh7785-irl4567", vectors_irl4567, + NULL, NULL, mask_registers, NULL, NULL); + void __init plat_irq_setup(void) { - register_intc2_controller(&intc2_irq_desc); + register_intc_controller(&intc_desc); } +void __init plat_irq_setup_pins(int mode) +{ + switch (mode) { + case IRQ_MODE_IRQ7654: + register_intc_controller(&intc_desc_irq4567); + break; + case IRQ_MODE_IRQ3210: + register_intc_controller(&intc_desc_irq0123); + break; + case IRQ_MODE_IRL7654: + register_intc_controller(&intc_desc_irl4567); + break; + case IRQ_MODE_IRL3210: + register_intc_controller(&intc_desc_irl0123); + break; + default: + BUG(); + } +} --- 0002/arch/sh/mm/Kconfig +++ work/arch/sh/mm/Kconfig 2007-07-26 22:34:17.000000000 +0900 @@ -192,7 +192,7 @@ config CPU_SUBTYPE_SH7785 bool "Support SH7785 processor" select CPU_SH4A select CPU_SHX2 - select CPU_HAS_INTC2_IRQ + select CPU_HAS_INTC_IRQ config CPU_SUBTYPE_SHX3 bool "Support SH-X3 processor" --- 0001/include/asm-sh/hw_irq.h +++ work/include/asm-sh/hw_irq.h 2007-07-26 22:28:15.000000000 +0900 @@ -115,7 +115,8 @@ void __init register_intc_controller(str void __init plat_irq_setup(void); -enum { IRQ_MODE_IRQ, IRQ_MODE_IRL7654, IRQ_MODE_IRL3210 }; +enum { IRQ_MODE_IRQ, IRQ_MODE_IRQ7654, IRQ_MODE_IRQ3210, + IRQ_MODE_IRL7654, IRQ_MODE_IRL3210 }; void __init plat_irq_setup_pins(int mode); #endif /* __ASM_SH_HW_IRQ_H */ |
From: Paul M. <le...@li...> - 2007-07-26 14:27:03
|
On Thu, Jul 26, 2007 at 11:20:30PM +0900, Magnus Damm wrote: > Hi David, > > Thanks for your patches! > > On 7/26/07, David McCullough <Dav...@se...> wrote: > > > > Fix up the IPR/IRQ defines and do a few small cleanups > > > > Signed-off-by: David McCullough <dav...@se...> > > > > --- > > commit 729cc761ccd442364de93b5af0e8f40d649d1878 > > tree a022252f2182a5aa6a19101859af0b5a8b135aa0 > > parent 5b55e21c48d5ab697c007781d7b7718293e59e0d > > author David McCullough <dav...@se...> Thu, 26 Jul 2007 14:11:17 +1000 > > committer David McCullough <davidm@beast.(none)> Thu, 26 Jul 2007 14:11:17 +1000 > > > > include/asm-sh/snapgear.h | 31 +++++++++++++++++++++++++++++++ > > 1 files changed, 31 insertions(+), 0 deletions(-) > > > > diff --git a/include/asm-sh/snapgear.h b/include/asm-sh/snapgear.h > > index 3554e3a..a9df1a6 100644 > > --- a/include/asm-sh/snapgear.h > > +++ b/include/asm-sh/snapgear.h > > @@ -18,22 +18,46 @@ > > * depending on the priority for the interrupt. In fact the priority > > * is the interrupt :-) > > */ > > +#define INTC_IPRA 0xffd00004 > > +#define INTC_IPRB 0xffd00008 > > +#define INTC_IPRC 0xffd0000c > > +#define INTC_IPRD 0xffd00010 > > Uhm, these registers are processor specific. The board-specific code > should not need to poke around with them. There are several boards > that do this unfortunately - I suspect the code is there for > historical reasons. These days the vectors should be installed and > handled by the cpu specific code. > > It should be possible for you to just use ipr_irq_enable_irlm() in > your board specific code and then request irqs. It looks like no > board-specific irq handling is needed - you only use IRQ pins for > external devices, right? No funky FPGA:s with interrupt masks and > things I hope. =) > > So if you have time - try ripping it all out and check if it still > works. And I'd be happy to help you to move towards using the intc > code instead of ipr if board specific code is needed after all. > This should be done incrementally. The INTC conversions are too late for 2.6.23 now that the merge window is closed, but the IPR fixups we can still merge. It would be worthwhile at least getting the minimal fixes needed to get the board working for 2.6.23, and leave the restructuring for 2.6.24. I've also opened up the 2.6.24 tree already in light of all of the other INTC work, SH7720 support, etc. so patches for that are of course welcome at any time, too. The 2.6.24 stuff will be automatically pulled in to -mm, so the sooner this is done, the more testing it can get before the next merge window. |
From: Magnus D. <mag...@gm...> - 2007-07-26 14:20:32
|
Hi David, Thanks for your patches! On 7/26/07, David McCullough <Dav...@se...> wrote: > > Fix up the IPR/IRQ defines and do a few small cleanups > > Signed-off-by: David McCullough <dav...@se...> > > --- > commit 729cc761ccd442364de93b5af0e8f40d649d1878 > tree a022252f2182a5aa6a19101859af0b5a8b135aa0 > parent 5b55e21c48d5ab697c007781d7b7718293e59e0d > author David McCullough <dav...@se...> Thu, 26 Jul 2007 14:11:17 +1000 > committer David McCullough <davidm@beast.(none)> Thu, 26 Jul 2007 14:11:17 +1000 > > include/asm-sh/snapgear.h | 31 +++++++++++++++++++++++++++++++ > 1 files changed, 31 insertions(+), 0 deletions(-) > > diff --git a/include/asm-sh/snapgear.h b/include/asm-sh/snapgear.h > index 3554e3a..a9df1a6 100644 > --- a/include/asm-sh/snapgear.h > +++ b/include/asm-sh/snapgear.h > @@ -18,22 +18,46 @@ > * depending on the priority for the interrupt. In fact the priority > * is the interrupt :-) > */ > +#define INTC_IPRA 0xffd00004 > +#define INTC_IPRB 0xffd00008 > +#define INTC_IPRC 0xffd0000c > +#define INTC_IPRD 0xffd00010 Uhm, these registers are processor specific. The board-specific code should not need to poke around with them. There are several boards that do this unfortunately - I suspect the code is there for historical reasons. These days the vectors should be installed and handled by the cpu specific code. It should be possible for you to just use ipr_irq_enable_irlm() in your board specific code and then request irqs. It looks like no board-specific irq handling is needed - you only use IRQ pins for external devices, right? No funky FPGA:s with interrupt masks and things I hope. =) So if you have time - try ripping it all out and check if it still works. And I'd be happy to help you to move towards using the intc code instead of ipr if board specific code is needed after all. Thanks! / magnus |
From: Paul M. <le...@li...> - 2007-07-26 08:54:09
|
On Thu, Jul 26, 2007 at 04:21:01PM +1000, David McCullough wrote: > Jivin Paul Mundt lays it down ... > > On Thu, Jul 26, 2007 at 03:27:13PM +1000, David McCullough wrote: > > > Add support for copying our filesystem out of the way when images are > > > constructed by concatenating the root filesystem to the end of a linux.bin > > > which has the BSS removed (to save space). > > > > That's an interesting abuse :-) > > It's a very old thing, our images from the beginning of time have been > like this. If you don't like it, no problems, you can get around it > by making images with the BSS included in the linux.bin. > Besides the watchdog cruft, I don't particularly have a problem with it. I'll certainly accept patches for the functionality, although it will be for 2.6.24. > > CONFIG_SH_ROMBOOT is not added by any of your patches, likewise for > > _mem_start and _rom_store. Presumably this should be sent as a follow up > > patch if you want this functionality included. > > My BAD, the CONFIG_SH_ROMBOOT was contributed by someone else and since > we don't use it, I didn't need all the other bits to make it go. > > I'll fix this if you think the "strange romfs thing" is acceptable in > some shape or form. > If there are sufficient users of this feature, then I don't have a problem with merging it. If you aren't using romboot at all, then just drop that from the update. > > > + /* copy backwards to avoid writing over ourselves */ > > > + arch_service_watchdog(); > > > + while (dp >= ((unsigned char *) (&_end[0]))) { > > > + *dp-- = *sp--; > > > + if ((((unsigned long) dp) & 0x7ffff) == 0) > > > + arch_service_watchdog(); > > > + } > > > + arch_service_watchdog(); > > > +} > > > > Can you not simply disable the watchdog in your loader and start it up > > from the board code? Having to do dummy reads from the thing in this > > convoluted manner is rather undesirable. > > The watchdog is on from poweron, it cannot be disabled in any possible > way. You have at most 1 second (or less on some versions) to service it or > it resets the hardware. > Then perhaps we should just be abstracting out the romfs copy. ie, have the generic copy_romfs() (possibly renamed to something more reasonable) take care of extracting all of the various image details, and then kick the addresses down to a platform-specific symbol to do the actual copy. This too can be a weak symbol, where the default implementation simply does the copy without the watchdog noise. This way you can keep all of your platform-specific cruft isolated without making a compromise on functionality. |
From: David M. <Dav...@se...> - 2007-07-26 06:19:18
|
Jivin Paul Mundt lays it down ... > On Thu, Jul 26, 2007 at 03:27:13PM +1000, David McCullough wrote: > > Add support for copying our filesystem out of the way when images are > > constructed by concatenating the root filesystem to the end of a linux.bin > > which has the BSS removed (to save space). > > That's an interesting abuse :-) It's a very old thing, our images from the beginning of time have been like this. If you don't like it, no problems, you can get around it by making images with the BSS included in the linux.bin. > > --- a/arch/sh/kernel/setup.c > > +++ b/arch/sh/kernel/setup.c > > @@ -399,3 +399,66 @@ struct seq_operations cpuinfo_op = { > > .show = show_cpuinfo, > > }; > > #endif /* CONFIG_PROC_FS */ > > + > > +#if defined(CONFIG_SH_CONCAT_FS) > > +/* > > + * do not call printk in here, bad things will happen, the kernel isn't > > + * actually up yet, we are called from head.S before BSS is cleared. > > + */ > > + > > +void __init __attribute__ ((weak)) > > +arch_service_watchdog(void) > > +{ > > +} > > + > > I'm not sure if I like this watchdog thing.. What was there before was all ifdef'd, I figured this might be more acceptable, I can go back to ifdef's if you like. > > +extern void copy_romfs(void); > > +void __init copy_romfs() > > +{ > > + unsigned char *sp, *dp; > > + unsigned long len; > > + > > + /* > > + * we used to use __bss_start, but that is padded to 4K now and doesn't > > + * work, basically we need the last non-padded symbol before __bss_start > > + * and that is now __machvec_end > > + */ > > +#define CURRENT_ROMFS_LOC ((unsigned long)(&__machvec_end)) > > + > > Please just add a non-padded symbol (ie, __davidms_strange_romfs_thing) > for this instead. Otherwise someone, most likely me, will forget that > there's some special bit of code that reads far too much in to what > __machvec_end really means. ok. > > +#ifdef CONFIG_SH_ROMBOOT > > + extern int _mem_start, _rom_store; > > + sp = (unsigned char *) CURRENT_ROMFS_LOC - ((_mem_start - _rom_store) / 4); > > +#else > > + sp = (unsigned char *) CURRENT_ROMFS_LOC; > > +#endif > > CONFIG_SH_ROMBOOT is not added by any of your patches, likewise for > _mem_start and _rom_store. Presumably this should be sent as a follow up > patch if you want this functionality included. My BAD, the CONFIG_SH_ROMBOOT was contributed by someone else and since we don't use it, I didn't need all the other bits to make it go. I'll fix this if you think the "strange romfs thing" is acceptable in some shape or form. > > + /* copy backwards to avoid writing over ourselves */ > > + arch_service_watchdog(); > > + while (dp >= ((unsigned char *) (&_end[0]))) { > > + *dp-- = *sp--; > > + if ((((unsigned long) dp) & 0x7ffff) == 0) > > + arch_service_watchdog(); > > + } > > + arch_service_watchdog(); > > +} > > Can you not simply disable the watchdog in your loader and start it up > from the board code? Having to do dummy reads from the thing in this > convoluted manner is rather undesirable. The watchdog is on from poweron, it cannot be disabled in any possible way. You have at most 1 second (or less on some versions) to service it or it resets the hardware. Again, if it's no good we'll just carry the needed changes in our tree. Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
From: Paul M. <le...@li...> - 2007-07-26 06:02:11
|
On Thu, Jul 26, 2007 at 03:33:23PM +1000, David McCullough wrote: > Fixes for the mtd plat-ram driver: > - no need to request_mem_region(), the platform driver does that automatically > - fix partition handling when probes is not set > - fix error checking for add_mtd_device() > - optionally set ROOT_DEV to the mtd device > > Signed-off-by: Philip Craig <phi...@se...> > Signed-off-by: David McCullough <dav...@se...> > Please send this to dwmw2 separately. He's subscribed, but probably not paying attention :-) |
From: Paul M. <le...@li...> - 2007-07-26 06:01:30
|
On Thu, Jul 26, 2007 at 03:31:58PM +1000, David McCullough wrote: > @@ -37,7 +40,12 @@ static irqreturn_t eraseconfig_interrupt(int irq, void *dev_id) > { > volatile char dummy __attribute__((unused)) = * (volatile char *) 0xb8000000; > > +#ifdef CONFIG_LEDMAN > + extern void ledman_signalreset(void); > + ledman_signalreset(); > +#else > printk("SnapGear: erase switch interrupt!\n"); > +#endif > > return IRQ_HANDLED; > } You guys should really try to hammer this in to drivers/leds so it can be generically supported, if you don't have equivalent functionality there already. > + * This is set up by the setup-routine at boot-time > + */ > +#define PARAM ((unsigned char *)empty_zero_page) > + > +#define LOADER_TYPE (*(unsigned long *) (PARAM+0x00c)) > +#define INITRD_START (*(unsigned long *) (PARAM+0x010)) > +#define INITRD_SIZE (*(unsigned long *) (PARAM+0x014)) > + This is really not something we want board code poking at. > +static struct resource sg_mtd_ram_resource = { > + .flags = IORESOURCE_MEM, > +}; > + > +static struct platdata_mtd_ram sg_mtd_ram_data = { > + .mapname = "Romfs", > + .bankwidth = 1, > + .root_dev = 1, > +}; > + > +static struct platform_device sg_mtd_ram_device = { > + .name = "mtd-ram", > + .id = 0, > + .dev.platform_data = &sg_mtd_ram_data, > + .num_resources = 1, > + .resource = &sg_mtd_ram_resource, > +}; > + This seems like it might be generally useful, perhaps it's worth having some system-wide platform devices and just make this conditional on your concatenated romfs thing (or some similar config option). The driver model isn't available until late in the boot anyways, so we'll already have parsed all of the INITRD settings by then (where we just don't bother registering the driver if there's nothing present). > +static int __init sg_devices_setup(void) > +{ > + int ret = 0, ret2 = 0; > + > + if (sg_mtd_ram_resource.start) > + ret = platform_device_register(&sg_mtd_ram_device); > + > +#ifdef CONFIG_RTC_DRV_DS1302 > + ret2 = platform_device_register(&sg_rtc_device); > + if (ret2) > +#endif > + { > +#ifdef CONFIG_RTC_DRV_SH > + ret2 = platform_device_register(&sh_rtc_device); > +#endif > + } > + return ret ? ret : ret2; > +} > + > +__initcall(sg_devices_setup); > + Do the RTC devices really need to be ifdef'ed? You should simply have a devices array flagged as initdata and register it all in one shot. If support for the devices hasn't been built in to the kernel, the device will never be claimed, and it will be freed automatically anyways. This also illustrates why platform_add_devices() is a good thing. Take a look at arch/sh/boards/renesas/r7780rp/setup.c. |
From: Paul M. <le...@li...> - 2007-07-26 05:54:32
|
On Thu, Jul 26, 2007 at 03:27:13PM +1000, David McCullough wrote: > Add support for copying our filesystem out of the way when images are > constructed by concatenating the root filesystem to the end of a linux.bin > which has the BSS removed (to save space). > That's an interesting abuse :-) > --- a/arch/sh/kernel/setup.c > +++ b/arch/sh/kernel/setup.c > @@ -399,3 +399,66 @@ struct seq_operations cpuinfo_op = { > .show = show_cpuinfo, > }; > #endif /* CONFIG_PROC_FS */ > + > +#if defined(CONFIG_SH_CONCAT_FS) > +/* > + * do not call printk in here, bad things will happen, the kernel isn't > + * actually up yet, we are called from head.S before BSS is cleared. > + */ > + > +void __init __attribute__ ((weak)) > +arch_service_watchdog(void) > +{ > +} > + I'm not sure if I like this watchdog thing.. > +extern void copy_romfs(void); > +void __init copy_romfs() > +{ > + unsigned char *sp, *dp; > + unsigned long len; > + > + /* > + * we used to use __bss_start, but that is padded to 4K now and doesn't > + * work, basically we need the last non-padded symbol before __bss_start > + * and that is now __machvec_end > + */ > +#define CURRENT_ROMFS_LOC ((unsigned long)(&__machvec_end)) > + Please just add a non-padded symbol (ie, __davidms_strange_romfs_thing) for this instead. Otherwise someone, most likely me, will forget that there's some special bit of code that reads far too much in to what __machvec_end really means. > +#ifdef CONFIG_SH_ROMBOOT > + extern int _mem_start, _rom_store; > + sp = (unsigned char *) CURRENT_ROMFS_LOC - ((_mem_start - _rom_store) / 4); > +#else > + sp = (unsigned char *) CURRENT_ROMFS_LOC; > +#endif CONFIG_SH_ROMBOOT is not added by any of your patches, likewise for _mem_start and _rom_store. Presumably this should be sent as a follow up patch if you want this functionality included. > + /* copy backwards to avoid writing over ourselves */ > + arch_service_watchdog(); > + while (dp >= ((unsigned char *) (&_end[0]))) { > + *dp-- = *sp--; > + if ((((unsigned long) dp) & 0x7ffff) == 0) > + arch_service_watchdog(); > + } > + arch_service_watchdog(); > +} Can you not simply disable the watchdog in your loader and start it up from the board code? Having to do dummy reads from the thing in this convoluted manner is rather undesirable. |