Menu
▾
▴
linuxsh-dev
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-26 05:44:14
|
On Thu, Jul 26, 2007 at 03:25:37PM +1000, David McCullough wrote:
> unsigned long get_wchan(struct task_struct *p)
> {
> - unsigned long schedule_frame;
> unsigned long pc;
>
> if (!p || p == current || p->state == TASK_RUNNING)
The removal of schedule_frame will break CONFIG_FRAME_POINTER=y.
> @@ -484,11 +483,12 @@ unsigned long get_wchan(struct task_struct *p)
> * The same comment as on the Alpha applies here, too ...
> */
> pc = thread_saved_pc(p);
> +#ifdef CONFIG_FRAME_POINTER
> if (in_sched_functions(pc)) {
> schedule_frame = (unsigned long)p->thread.sp;
> return ((unsigned long *)schedule_frame)[21];
> }
> -
> +#endif
> return pc;
> }
>
I'll fix it up.
|
|
From: Paul M. <le...@li...> - 2007-07-26 05:40:23
|
On Thu, Jul 26, 2007 at 03:23:56PM +1000, David McCullough wrote: > > If HOTPLUG is not defined the kernel fails to build due to a missing > kobject_actions. > > Signed-off-by: David McCullough <dav...@au...> > Already reported and a fix has been queued: http://marc.info/?l=linux-kernel&m=118515490812669&w=2 |
|
From: Paul M. <le...@li...> - 2007-07-26 00:35:45
|
On Wed, Jul 25, 2007 at 10:01:26PM -0700, Kristoffer Ericson wrote: > I would like to keep the layout as we've had before (individual files > for each cpu). Nothing against Magnus idea which seems quite valid. > Its more of an experience that merging stuff tend to mess it up rather > than make it easier (which is the goal). Trying to keep all cpu's in > order and regulate this by ifdef's looks ugly and would atleast > increase the chance of a patch for CPU x that would break CPU y. > I was leaning towards this as well, but they are a well structured superset. To split these out would lead to a lot of duplication, and there wouldn't really be any point unless someone was going to throw some other stuff in the setup code for that subtype that diverged from the common one. > The final word is of course Paul's. > Given the relatively few number of people working on these parts, I think the converged 770x setup makes sense. It's fairly trivial to copy out to a new subtype-specific file and hack up if there is to be something specific added that isn't shared across the others. However, we shouldn't prematurely try and abstract for this if it's going to be a non-issue. > On a different note, I can take the maintainer role for HP6xx platform > (or SH7709) since thats the only thing I got/touch. Im not the most > advanced programmer but Im very persistant :) I see it as doing my best > to test that the platform works and try to fix if it breaks (otherwise > run and whine to Paul), so its not that much different from what I do > now. > I'll start compiling a list then of supported boards and contacts and toss it in a MAINTAINERS update some time before 2.6.23. |
|
From: Paul M. <le...@li...> - 2007-07-25 22:28:11
|
On Wed, Jul 25, 2007 at 10:32:40PM -0700, Kristoffer Ericson wrote: > Paul, should I adjust scan_keyb or try and write something different? > Any other platforms using scan_keyb? No, scan_keyb is not used by anyone else. In any event, please work directly with Dmitry on this, if he's suggesting you look at input_polldev, that's the place to start. If you want anything to happen in drivers/input anyways. |
|
From: Kristoffer E. <kri...@gm...> - 2007-07-25 20:27:32
|
Paul, should I adjust scan_keyb or try and write something different? Any other platforms using scan_keyb? On Sun, 22 Jul 2007 01:45:10 -0400 Dmitry Torokhov <dt...@in...> wrote: > On Saturday 21 July 2007 21:15, Kristoffer Ericson wrote: > > Greetings, > > > > Here we go again with another keyboard patch (this time for hp6xx). > > It consists of three files, where one contains the generic scan_keyb > > routines with needed header and the third is the specific hp6xx driver. > > Please do not use scan_keyb. It goes around input core and directly into > legacy keyboard driver. For drivers that periodically poll/scan their > device input_polldev might be of interest. > > -- > Dmitry -- Kristoffer Ericson <Kri...@Gm...> |
|
From: Kristoffer E. <kri...@gm...> - 2007-07-25 19:56:23
|
Greetings, In reply to Paul's feedback request. I would like to keep the layout as we've had before (individual files for each cpu). Nothing against Magnus idea which seems quite valid. Its more of an experience that merging stuff tend to mess it up rather than make it easier (which is the goal). Trying to keep all cpu's in order and regulate this by ifdef's looks ugly and would atleast increase the chance of a patch for CPU x that would break CPU y. The final word is of course Paul's. On a different note, I can take the maintainer role for HP6xx platform (or SH7709) since thats the only thing I got/touch. Im not the most advanced programmer but Im very persistant :) I see it as doing my best to test that the platform works and try to fix if it breaks (otherwise run and whine to Paul), so its not that much different from what I do now. -- Kristoffer Ericson <Kri...@Gm...> |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 14:31:40
|
Hi Markus, Nice work with the sh7720 patch. On 7/24/07, Markus Brunner <sup...@go...> wrote: > thanks for the comments. > I will tidy up the patch, but I'm really short of time in July, so I will do that in early august. Ping me at that time if you need any help with the interrupt stuff. I should hopefully have better pint implementation ready then that you can hook up to your code. All in-tree SH3 processors are now using the intc controller, so your patch needs to be updated somehow as well. Thanks! / magnus |
|
From: Manuel L. <ma...@ro...> - 2007-07-25 14:26:49
|
On Wed, Jul 25, 2007 at 11:16:39PM +0900, Magnus Damm wrote: > Hi Manuel, > > Thanks for the feedback! > > On 7/25/07, Manuel Lauss <ma...@ro...> wrote: > > Hi Magnus, > > > > 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. Thanks, Manuel Lauss |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 14:16:41
|
Hi Manuel, Thanks for the feedback! On 7/25/07, Manuel Lauss <ma...@ro...> wrote: > Hi Magnus, > > 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? =) Thanks! / magnus |
|
From: Manuel L. <ma...@ro...> - 2007-07-25 13:53:08
|
Hi Magnus, > 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? Nevermind, figured it out already. Yes, all 4 have to be requested. Thanks, Manuel Lauss |
|
From: Manuel L. <ma...@ro...> - 2007-07-25 13:43:27
|
Hi Magnus, 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? Thanks, Manuel Lauss |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 13:29:20
|
sh: sh-sci - fix SH7708 support
This patch makes sure the sci serial port driver compiles for sh7708. The
approach taken is to treat the sh7708 as a subset of sh7706, sh7707, sh7709.
sh7708 is very similar to sh7706, sh7707, sh7709, but only equipped with
a single sci port. The platform data in setup-sh770x.c already limits the
number of serial ports for sh7708 to a single one, so the non-existing scif
ports pointed out in sh-sci.h will remain unused in case of sh7708.
Signed-off-by: Magnus Damm <da...@ig...>
---
drivers/serial/sh-sci.h | 25 ++++++++-----------------
1 file changed, 8 insertions(+), 17 deletions(-)
--- 0001/drivers/serial/sh-sci.h
+++ work/drivers/serial/sh-sci.h 2007-07-25 21:35:47.000000000 +0900
@@ -24,13 +24,10 @@
#endif
#endif
-#if defined(CONFIG_CPU_SUBTYPE_SH7708)
-# define SCSPTR 0xffffff7c /* 8 bit */
-# define SCSCR_INIT(port) 0x30 /* TIE=0,RIE=0,TE=1,RE=1 */
-# define SCI_ONLY
-#elif defined(CONFIG_CPU_SUBTYPE_SH7707) || \
- defined(CONFIG_CPU_SUBTYPE_SH7709) || \
- defined(CONFIG_CPU_SUBTYPE_SH7706)
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7708) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
# define SCPCR 0xA4000116 /* 16 bit SCI and SCIF */
# define SCPDR 0xA4000136 /* 8 bit SCI and SCIF */
# define SCSCR_INIT(port) 0x30 /* TIE=0,RIE=0,TE=1,RE=1 */
@@ -473,16 +470,10 @@ static const struct __attribute__((packe
};
#endif
-#if defined(CONFIG_CPU_SUBTYPE_SH7708)
-static inline int sci_rxd_in(struct uart_port *port)
-{
- if (port->mapbase == 0xfffffe80)
- return ctrl_inb(SCSPTR)&0x01 ? 1 : 0; /* SCI */
- return 1;
-}
-#elif defined(CONFIG_CPU_SUBTYPE_SH7707) || \
- defined(CONFIG_CPU_SUBTYPE_SH7709) || \
- defined(CONFIG_CPU_SUBTYPE_SH7706)
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7708) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
static inline int sci_rxd_in(struct uart_port *port)
{
if (port->mapbase == 0xfffffe80)
|
|
From: Magnus D. <mag...@gm...> - 2007-07-25 13:19:13
|
sh: intc - add support for SH7760
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.
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-25 20:54:20.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,
+ 0, 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);
}
--- 0001/arch/sh/mm/Kconfig
+++ work/arch/sh/mm/Kconfig 2007-07-25 20:54:43.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: Magnus D. <mag...@gm...> - 2007-07-25 13:11:26
|
sh: intc - avoid SH7710 specific vector on SH7712
This patch makes sure that the sh7710 specific ipsec vector is missing
if building for a sh7712. All according to the datasheet.
Signed-off-by: Magnus Damm <da...@ig...>
---
arch/sh/kernel/cpu/sh3/setup-sh7710.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- 0001/arch/sh/kernel/cpu/sh3/setup-sh7710.c
+++ work/arch/sh/kernel/cpu/sh3/setup-sh7710.c 2007-07-25 18:48:52.000000000 +0900
@@ -1,5 +1,5 @@
/*
- * SH7710 Setup
+ * SH3 Setup code for SH7710, SH7712
*
* Copyright (C) 2006 Paul Mundt
* Copyright (C) 2007 Nobuhiro Iwamatsu
@@ -45,7 +45,9 @@ static struct intc_vect vectors[] = {
INTC_VECT(SCIF1_ERI, 0x900), INTC_VECT(SCIF1_RXI, 0x920),
INTC_VECT(SCIF1_BRI, 0x940), INTC_VECT(SCIF1_TXI, 0x960),
INTC_VECT(DMAC_DEI4, 0xb80), INTC_VECT(DMAC_DEI5, 0xba0),
+#ifdef CONFIG_CPU_SUBTYPE_SH7710
INTC_VECT(IPSEC, 0xbe0),
+#endif
INTC_VECT(EDMAC0, 0xc00), INTC_VECT(EDMAC1, 0xc20),
INTC_VECT(EDMAC2, 0xc40),
INTC_VECT(SIOF0_ERI, 0xe00), INTC_VECT(SIOF0_TXI, 0xe20),
@@ -88,7 +90,10 @@ static struct intc_prio_reg prio_registe
{ 0xa4000016, 16, 4, /* IPRC */ { IRQ3, IRQ2, IRQ1, IRQ0 } },
{ 0xa4000018, 16, 4, /* IPRD */ { 0, 0, IRQ4, IRQ5 } },
{ 0xa400001a, 16, 4, /* IPRE */ { DMAC1, SCIF0, SCIF1 } },
- { 0xa4080000, 16, 4, /* IPRF */ { IPSEC, DMAC2 } },
+ { 0xa4080000, 16, 4, /* IPRF */ { 0, DMAC2 } },
+#ifdef CONFIG_CPU_SUBTYPE_SH7710
+ { 0xa4080000, 16, 4, /* IPRF */ { IPSEC } },
+#endif
{ 0xa4080002, 16, 4, /* IPRG */ { EDMAC0, EDMAC1, EDMAC2 } },
{ 0xa4080004, 16, 4, /* IPRH */ { 0, 0, 0, SIOF0 } },
{ 0xa4080006, 16, 4, /* IPRI */ { 0, 0, SIOF1 } },
|
|
From: Magnus D. <mag...@gm...> - 2007-07-25 13:02:14
|
sh: intc - add missing vectors for SH7707
This patch adds a few missing vectors for sh7707. The only interrupt
controller differences between sh7707 and sh7709 seem to be added vectors
for one LCD controller and two PCMCIA slots.
Signed-off-by: Magnus Damm <da...@ig...>
---
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- 0001/arch/sh/kernel/cpu/sh3/setup-sh770x.c
+++ work/arch/sh/kernel/cpu/sh3/setup-sh770x.c 2007-07-25 18:39:34.000000000 +0900
@@ -29,6 +29,7 @@ enum {
SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI,
SCI_ERI, SCI_RXI, SCI_TXI, SCI_TEI,
ADC_ADI,
+ LCDC, PCC0, PCC1,
TMU0, TMU1, TMU2_TUNI, TMU2_TICPI,
RTC_ATI, RTC_PRI, RTC_CUI,
WDT,
@@ -64,6 +65,10 @@ static struct intc_vect vectors[] = {
INTC_VECT(SCIF0_ERI, 0x880), INTC_VECT(SCIF0_RXI, 0x8a0),
INTC_VECT(SCIF0_BRI, 0x8c0), INTC_VECT(SCIF0_TXI, 0x8e0),
#endif
+#if defined(CONFIG_CPU_SUBTYPE_SH7707)
+ INTC_VECT(LCDC, 0x9a0),
+ INTC_VECT(PCC0, 0x9c0), INTC_VECT(PCC1, 0x9e0),
+#endif
};
static struct intc_group groups[] = {
@@ -98,6 +103,9 @@ static struct intc_prio_reg prio_registe
{ 0xa4000018, 16, 4, /* IPRD */ { PINT07, PINT815, } },
{ 0xa400001a, 16, 4, /* IPRE */ { 0, SCIF0 } },
#endif
+#if defined(CONFIG_CPU_SUBTYPE_SH7707)
+ { 0xa400001c, 16, 4, /* IPRF */ { 0, LCDC, PCC0, PCC1, } },
+#endif
};
static DECLARE_INTC_DESC(intc_desc, "sh770x", vectors, groups,
|
|
From: Paul M. <le...@li...> - 2007-07-25 08:51:42
|
On Wed, Jul 25, 2007 at 05:19:21PM +0900, Magnus Damm wrote: > sh: intc - add support for SH7710 V2 On Wed, Jul 25, 2007 at 05:39:09PM +0900, Magnus Damm wrote: > sh: intc - add support for SH7706, SH7707, SH7708, SH7709 V2 Applied, thanks. |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 08:40:56
|
sh: intc - add support for SH7706, SH7707, SH7708, SH7709 V2
This patch unifies the cpu specific interrupt setup code for sh7706, sh7707,
sh7708 and sh7709 and moves the code into a new file called setup-sh770x.c.
It makes sense to share the setup code between these processors because most
hardware blocks are identical from a software point of view. With this patch
the sh770x processors now have a complete set of vectors that match with the
information provided by the data sheets. This is a big improvement for sh7708.
Vectors for IRQ4 and IRQ5 are enabled by default. Use plat_irq_setup_pins() if
pins IRQ0-3 should be used in IRQ mode.
This patch also unifies the platform device setup code which means that the
rtc driver now has platform data for all sh770x processors.
Version two of this patch cleans up the ifdefs in setup-sh770x.c.
Signed-off-by: Magnus Damm <da...@ig...>
---
The code is untested but compiles.
arch/sh/kernel/cpu/sh3/Makefile | 8 -
arch/sh/kernel/cpu/sh3/setup-sh7708.c | 43 ------
arch/sh/kernel/cpu/sh3/setup-sh7709.c | 145 ----------------------
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 212 +++++++++++++++++++++++++++++++++
arch/sh/mm/Kconfig | 6
5 files changed, 220 insertions(+), 194 deletions(-)
--- 0001/arch/sh/kernel/cpu/sh3/Makefile
+++ work/arch/sh/kernel/cpu/sh3/Makefile 2007-07-25 17:18:33.000000000 +0900
@@ -6,10 +6,10 @@ obj-y := ex.o probe.o entry.o
# CPU subtype setup
obj-$(CONFIG_CPU_SUBTYPE_SH7705) += setup-sh7705.o
-obj-$(CONFIG_CPU_SUBTYPE_SH7706) += setup-sh7709.o
-obj-$(CONFIG_CPU_SUBTYPE_SH7707) += setup-sh7709.o
-obj-$(CONFIG_CPU_SUBTYPE_SH7708) += setup-sh7708.o
-obj-$(CONFIG_CPU_SUBTYPE_SH7709) += setup-sh7709.o
+obj-$(CONFIG_CPU_SUBTYPE_SH7706) += setup-sh770x.o
+obj-$(CONFIG_CPU_SUBTYPE_SH7707) += setup-sh770x.o
+obj-$(CONFIG_CPU_SUBTYPE_SH7708) += setup-sh770x.o
+obj-$(CONFIG_CPU_SUBTYPE_SH7709) += setup-sh770x.o
obj-$(CONFIG_CPU_SUBTYPE_SH7710) += setup-sh7710.o
obj-$(CONFIG_CPU_SUBTYPE_SH7712) += setup-sh7710.o
--- 0001/arch/sh/kernel/cpu/sh3/setup-sh7708.c
+++ /dev/null 2007-07-17 09:16:46.626928230 +0900
@@ -1,43 +0,0 @@
-/*
- * SH7708 Setup
- *
- * Copyright (C) 2006 Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-#include <linux/platform_device.h>
-#include <linux/init.h>
-#include <linux/serial.h>
-#include <asm/sci.h>
-
-static struct plat_sci_port sci_platform_data[] = {
- {
- .mapbase = 0xfffffe80,
- .flags = UPF_BOOT_AUTOCONF,
- .type = PORT_SCI,
- .irqs = { 23, 24, 25, 0 },
- }, {
- .flags = 0,
- }
-};
-
-static struct platform_device sci_device = {
- .name = "sh-sci",
- .id = -1,
- .dev = {
- .platform_data = sci_platform_data,
- },
-};
-
-static struct platform_device *sh7708_devices[] __initdata = {
- &sci_device,
-};
-
-static int __init sh7708_devices_setup(void)
-{
- return platform_add_devices(sh7708_devices,
- ARRAY_SIZE(sh7708_devices));
-}
-__initcall(sh7708_devices_setup);
--- 0001/arch/sh/kernel/cpu/sh3/setup-sh7709.c
+++ /dev/null 2007-07-17 09:16:46.626928230 +0900
@@ -1,145 +0,0 @@
-/*
- * SH7707/SH7709 Setup
- *
- * Copyright (C) 2006 Paul Mundt
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-#include <linux/platform_device.h>
-#include <linux/init.h>
-#include <linux/serial.h>
-#include <asm/sci.h>
-
-static struct resource rtc_resources[] = {
- [0] = {
- .start = 0xfffffec0,
- .end = 0xfffffec0 + 0x1e,
- .flags = IORESOURCE_IO,
- },
- [1] = {
- .start = 20,
- .flags = IORESOURCE_IRQ,
- },
- [2] = {
- .start = 21,
- .flags = IORESOURCE_IRQ,
- },
- [3] = {
- .start = 22,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct plat_sci_port sci_platform_data[] = {
- {
- .mapbase = 0xfffffe80,
- .flags = UPF_BOOT_AUTOCONF,
- .type = PORT_SCI,
- .irqs = { 23, 24, 25, 0 },
- }, {
- .mapbase = 0xa4000150,
- .flags = UPF_BOOT_AUTOCONF,
- .type = PORT_SCIF,
- .irqs = { 56, 57, 59, 58 },
- }, {
- .mapbase = 0xa4000140,
- .flags = UPF_BOOT_AUTOCONF,
- .type = PORT_IRDA,
- .irqs = { 52, 53, 55, 54 },
- }, {
- .flags = 0,
- }
-};
-
-static struct platform_device sci_device = {
- .name = "sh-sci",
- .id = -1,
- .dev = {
- .platform_data = sci_platform_data,
- },
-};
-
-static struct platform_device rtc_device = {
- .name = "sh-rtc",
- .id = -1,
- .num_resources = ARRAY_SIZE(rtc_resources),
- .resource = rtc_resources,
-};
-
-static struct platform_device *sh7709_devices[] __initdata = {
- &sci_device,
- &rtc_device,
-};
-
-static int __init sh7709_devices_setup(void)
-{
- return platform_add_devices(sh7709_devices,
- ARRAY_SIZE(sh7709_devices));
-}
-__initcall(sh7709_devices_setup);
-
-static struct ipr_data ipr_irq_table[] = {
- { 16, 0, 12, 2 }, /* TMU TUNI0 */
- { 17, 0, 8, 4 }, /* TMU TUNI1 */
- { 18, 0, 4, 1 }, /* TMU TUNI1 */
- { 19, 0, 4, 1 }, /* TMU TUNI1 */
- { 20, 0, 0, 2 }, /* RTC CUI */
- { 21, 0, 0, 2 }, /* RTC CUI */
- { 22, 0, 0, 2 }, /* RTC CUI */
-
- { 23, 1, 4, 3 }, /* SCI */
- { 24, 1, 4, 3 }, /* SCI */
- { 25, 1, 4, 3 }, /* SCI */
- { 26, 1, 4, 3 }, /* SCI */
- { 27, 1, 12, 3 }, /* WDT ITI */
-
- { 32, 2, 0, 1 }, /* IRQ 0 */
- { 33, 2, 4, 1 }, /* IRQ 1 */
- { 34, 2, 8, 1 }, /* IRQ 2 APM */
- { 35, 2, 12, 1 }, /* IRQ 3 TOUCHSCREEN */
-
- { 36, 3, 0, 1 }, /* IRQ 4 */
- { 37, 3, 4, 1 }, /* IRQ 5 */
-
- { 48, 4, 12, 7 }, /* DMA */
- { 49, 4, 12, 7 }, /* DMA */
- { 50, 4, 12, 7 }, /* DMA */
- { 51, 4, 12, 7 }, /* DMA */
-
- { 52, 4, 8, 3 }, /* IRDA */
- { 53, 4, 8, 3 }, /* IRDA */
- { 54, 4, 8, 3 }, /* IRDA */
- { 55, 4, 8, 3 }, /* IRDA */
-
- { 56, 4, 4, 3 }, /* SCIF */
- { 57, 4, 4, 3 }, /* SCIF */
- { 58, 4, 4, 3 }, /* SCIF */
- { 59, 4, 4, 3 }, /* SCIF */
-};
-
-static unsigned long ipr_offsets[] = {
- 0xfffffee2, /* 0: IPRA */
- 0xfffffee4, /* 1: IPRB */
- 0xa4000016, /* 2: IPRC */
- 0xa4000018, /* 3: IPRD */
- 0xa400001a, /* 4: IPRE */
-};
-
-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-sh7709",
- },
-};
-
-void __init plat_irq_setup(void)
-{
- register_ipr_controller(&ipr_irq_desc);
-}
--- /dev/null
+++ work/arch/sh/kernel/cpu/sh3/setup-sh770x.c 2007-07-25 17:24:52.000000000 +0900
@@ -0,0 +1,212 @@
+/*
+ * SH3 Setup code for SH7706, SH7707, SH7708, SH7709
+ *
+ * Copyright (C) 2007 Magnus Damm
+ *
+ * Based on setup-sh7709.c
+ *
+ * Copyright (C) 2006 Paul Mundt
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <asm/sci.h>
+
+enum {
+ UNUSED = 0,
+
+ /* interrupt sources */
+ IRQ0, IRQ1, IRQ2, IRQ3, IRQ4, IRQ5,
+ PINT07, PINT815,
+ DMAC_DEI0, DMAC_DEI1, DMAC_DEI2, DMAC_DEI3,
+ SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI,
+ SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI,
+ SCI_ERI, SCI_RXI, SCI_TXI, SCI_TEI,
+ ADC_ADI,
+ TMU0, TMU1, TMU2_TUNI, TMU2_TICPI,
+ RTC_ATI, RTC_PRI, RTC_CUI,
+ WDT,
+ REF_RCMI, REF_ROVI,
+
+ /* interrupt groups */
+ RTC, REF, TMU2, DMAC, SCI, SCIF2, SCIF0,
+};
+
+static struct intc_vect vectors[] = {
+ INTC_VECT(TMU0, 0x400), INTC_VECT(TMU1, 0x420),
+ INTC_VECT(TMU2_TUNI, 0x440), INTC_VECT(TMU2_TICPI, 0x460),
+ INTC_VECT(RTC_ATI, 0x480), INTC_VECT(RTC_PRI, 0x4a0),
+ INTC_VECT(RTC_CUI, 0x4c0),
+ INTC_VECT(SCI_ERI, 0x4e0), INTC_VECT(SCI_RXI, 0x500),
+ INTC_VECT(SCI_TXI, 0x520), INTC_VECT(SCI_TEI, 0x540),
+ INTC_VECT(WDT, 0x560),
+ INTC_VECT(REF_RCMI, 0x580),
+ INTC_VECT(REF_ROVI, 0x5a0),
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ INTC_VECT(IRQ4, 0x680), INTC_VECT(IRQ5, 0x6a0),
+ INTC_VECT(DMAC_DEI0, 0x800), INTC_VECT(DMAC_DEI1, 0x820),
+ INTC_VECT(DMAC_DEI2, 0x840), INTC_VECT(DMAC_DEI3, 0x860),
+ INTC_VECT(ADC_ADI, 0x980),
+ INTC_VECT(SCIF2_ERI, 0x900), INTC_VECT(SCIF2_RXI, 0x920),
+ INTC_VECT(SCIF2_BRI, 0x940), INTC_VECT(SCIF2_TXI, 0x960),
+#endif
+#if defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ INTC_VECT(PINT07, 0x700), INTC_VECT(PINT815, 0x720),
+ INTC_VECT(SCIF0_ERI, 0x880), INTC_VECT(SCIF0_RXI, 0x8a0),
+ INTC_VECT(SCIF0_BRI, 0x8c0), INTC_VECT(SCIF0_TXI, 0x8e0),
+#endif
+};
+
+static struct intc_group groups[] = {
+ INTC_GROUP(RTC, RTC_ATI, RTC_PRI, RTC_CUI),
+ INTC_GROUP(TMU2, TMU2_TUNI, TMU2_TICPI),
+ INTC_GROUP(REF, REF_RCMI, REF_ROVI),
+ INTC_GROUP(DMAC, DMAC_DEI0, DMAC_DEI1, DMAC_DEI2, DMAC_DEI3),
+ INTC_GROUP(SCI, SCI_ERI, SCI_RXI, SCI_TXI, SCI_TEI),
+ INTC_GROUP(SCIF0, SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI),
+ INTC_GROUP(SCIF2, SCIF2_ERI, SCIF2_RXI, SCIF2_BRI, SCIF2_TXI),
+};
+
+static struct intc_prio priorities[] = {
+ INTC_PRIO(DMAC, 7),
+ INTC_PRIO(SCI, 3),
+ INTC_PRIO(SCIF2, 3),
+ INTC_PRIO(SCIF0, 3),
+};
+
+static struct intc_prio_reg prio_registers[] = {
+ { 0xfffffee2, 16, 4, /* IPRA */ { TMU0, TMU1, TMU2, RTC } },
+ { 0xfffffee4, 16, 4, /* IPRB */ { WDT, REF, SCI, 0 } },
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ { 0xa4000016, 16, 4, /* IPRC */ { IRQ3, IRQ2, IRQ1, IRQ0 } },
+ { 0xa4000018, 16, 4, /* IPRD */ { 0, 0, IRQ4, IRQ5 } },
+ { 0xa400001a, 16, 4, /* IPRE */ { DMAC, 0, SCIF2, ADC_ADI } },
+#endif
+#if defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ { 0xa4000018, 16, 4, /* IPRD */ { PINT07, PINT815, } },
+ { 0xa400001a, 16, 4, /* IPRE */ { 0, SCIF0 } },
+#endif
+};
+
+static DECLARE_INTC_DESC(intc_desc, "sh770x", vectors, groups,
+ priorities, NULL, prio_registers, NULL);
+
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+static struct intc_vect vectors_irq[] = {
+ INTC_VECT(IRQ0, 0x600), INTC_VECT(IRQ1, 0x620),
+ INTC_VECT(IRQ2, 0x640), INTC_VECT(IRQ3, 0x660),
+};
+
+static DECLARE_INTC_DESC(intc_desc_irq, "sh770x-irq", vectors_irq, NULL,
+ priorities, NULL, prio_registers, NULL);
+#endif
+
+static struct resource rtc_resources[] = {
+ [0] = {
+ .start = 0xfffffec0,
+ .end = 0xfffffec0 + 0x1e,
+ .flags = IORESOURCE_IO,
+ },
+ [1] = {
+ .start = 20,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = 21,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .start = 22,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device rtc_device = {
+ .name = "sh-rtc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(rtc_resources),
+ .resource = rtc_resources,
+};
+
+static struct plat_sci_port sci_platform_data[] = {
+ {
+ .mapbase = 0xfffffe80,
+ .flags = UPF_BOOT_AUTOCONF,
+ .type = PORT_SCI,
+ .irqs = { 23, 24, 25, 0 },
+ },
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ {
+ .mapbase = 0xa4000150,
+ .flags = UPF_BOOT_AUTOCONF,
+ .type = PORT_SCIF,
+ .irqs = { 56, 57, 59, 58 },
+ },
+#endif
+#if defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ {
+ .mapbase = 0xa4000140,
+ .flags = UPF_BOOT_AUTOCONF,
+ .type = PORT_IRDA,
+ .irqs = { 52, 53, 55, 54 },
+ },
+#endif
+ {
+ .flags = 0,
+ }
+};
+
+static struct platform_device sci_device = {
+ .name = "sh-sci",
+ .id = -1,
+ .dev = {
+ .platform_data = sci_platform_data,
+ },
+};
+
+static struct platform_device *sh770x_devices[] __initdata = {
+ &sci_device,
+ &rtc_device,
+};
+
+static int __init sh770x_devices_setup(void)
+{
+ return platform_add_devices(sh770x_devices,
+ ARRAY_SIZE(sh770x_devices));
+}
+__initcall(sh770x_devices_setup);
+
+void __init plat_irq_setup_pins(int mode)
+{
+ if (mode == IRQ_MODE_IRQ) {
+#if defined(CONFIG_CPU_SUBTYPE_SH7706) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7707) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7709)
+ register_intc_controller(&intc_desc_irq);
+ return;
+#endif
+ }
+ BUG();
+}
+
+void __init plat_irq_setup(void)
+{
+ register_intc_controller(&intc_desc);
+}
--- 0002/arch/sh/mm/Kconfig
+++ work/arch/sh/mm/Kconfig 2007-07-25 17:18:33.000000000 +0900
@@ -71,19 +71,21 @@ config CPU_SUBTYPE_SH7705
config CPU_SUBTYPE_SH7706
bool "Support SH7706 processor"
select CPU_SH3
- select CPU_HAS_IPR_IRQ
+ select CPU_HAS_INTC_IRQ
help
Select SH7706 if you have a 133 Mhz SH-3 HD6417706 CPU.
config CPU_SUBTYPE_SH7707
bool "Support SH7707 processor"
select CPU_SH3
+ select CPU_HAS_INTC_IRQ
help
Select SH7707 if you have a 60 Mhz SH-3 HD6417707 CPU.
config CPU_SUBTYPE_SH7708
bool "Support SH7708 processor"
select CPU_SH3
+ select CPU_HAS_INTC_IRQ
help
Select SH7708 if you have a 60 Mhz SH-3 HD6417708S or
if you have a 100 Mhz SH-3 HD6417708R CPU.
@@ -91,7 +93,7 @@ config CPU_SUBTYPE_SH7708
config CPU_SUBTYPE_SH7709
bool "Support SH7709 processor"
select CPU_SH3
- select CPU_HAS_IPR_IRQ
+ select CPU_HAS_INTC_IRQ
help
Select SH7709 if you have a 80 Mhz SH-3 HD6417709 CPU.
|
|
From: Magnus D. <mag...@gm...> - 2007-07-25 08:20:50
|
sh: intc - add support for SH7710 V2
This patch converts the cpu specific interrupt setup code for sh7710 from
ipr to intc. While at it new vectors are added to match the information
provided by the datasheet. Version two simplifies the Kconfig part.
Vectors for IRQ4 and IRQ5 are enabled by default. Use plat_irq_setup_pins() if
pins IRQ0-3 should be used in IRQ mode.
This patch also adds sh7710 specific platform data for the rtc driver.
The base address of SCIF1 is adjusted to match the datasheet.
Signed-off-by: Magnus Damm <da...@ig...>
---
The code compiles but is untested.
arch/sh/kernel/cpu/sh3/setup-sh7710.c | 183 +++++++++++++++++++++++----------
arch/sh/mm/Kconfig | 4
2 files changed, 132 insertions(+), 55 deletions(-)
--- 0001/arch/sh/kernel/cpu/sh3/setup-sh7710.c
+++ work/arch/sh/kernel/cpu/sh3/setup-sh7710.c 2007-07-25 16:56:29.000000000 +0900
@@ -10,9 +10,128 @@
*/
#include <linux/platform_device.h>
#include <linux/init.h>
+#include <linux/irq.h>
#include <linux/serial.h>
#include <asm/sci.h>
+enum {
+ UNUSED = 0,
+
+ /* interrupt sources */
+ IRQ0, IRQ1, IRQ2, IRQ3, IRQ4, IRQ5,
+ DMAC_DEI0, DMAC_DEI1, DMAC_DEI2, DMAC_DEI3,
+ SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI,
+ SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI,
+ DMAC_DEI4, DMAC_DEI5,
+ IPSEC,
+ EDMAC0, EDMAC1, EDMAC2,
+ SIOF0_ERI, SIOF0_TXI, SIOF0_RXI, SIOF0_CCI,
+ SIOF1_ERI, SIOF1_TXI, SIOF1_RXI, SIOF1_CCI,
+ TMU0, TMU1, TMU2,
+ RTC_ATI, RTC_PRI, RTC_CUI,
+ WDT,
+ REF,
+
+ /* interrupt groups */
+ RTC, DMAC1, SCIF0, SCIF1, DMAC2, SIOF0, SIOF1,
+};
+
+static struct intc_vect vectors[] = {
+ INTC_VECT(IRQ4, 0x680), INTC_VECT(IRQ5, 0x6a0),
+ INTC_VECT(DMAC_DEI0, 0x800), INTC_VECT(DMAC_DEI1, 0x820),
+ INTC_VECT(DMAC_DEI2, 0x840), INTC_VECT(DMAC_DEI3, 0x860),
+ INTC_VECT(SCIF0_ERI, 0x880), INTC_VECT(SCIF0_RXI, 0x8a0),
+ INTC_VECT(SCIF0_BRI, 0x8c0), INTC_VECT(SCIF0_TXI, 0x8e0),
+ INTC_VECT(SCIF1_ERI, 0x900), INTC_VECT(SCIF1_RXI, 0x920),
+ INTC_VECT(SCIF1_BRI, 0x940), INTC_VECT(SCIF1_TXI, 0x960),
+ INTC_VECT(DMAC_DEI4, 0xb80), INTC_VECT(DMAC_DEI5, 0xba0),
+ INTC_VECT(IPSEC, 0xbe0),
+ INTC_VECT(EDMAC0, 0xc00), INTC_VECT(EDMAC1, 0xc20),
+ INTC_VECT(EDMAC2, 0xc40),
+ INTC_VECT(SIOF0_ERI, 0xe00), INTC_VECT(SIOF0_TXI, 0xe20),
+ INTC_VECT(SIOF0_RXI, 0xe40), INTC_VECT(SIOF0_CCI, 0xe60),
+ INTC_VECT(SIOF1_ERI, 0xe80), INTC_VECT(SIOF1_TXI, 0xea0),
+ INTC_VECT(SIOF1_RXI, 0xec0), INTC_VECT(SIOF1_CCI, 0xee0),
+ INTC_VECT(TMU0, 0x400), INTC_VECT(TMU1, 0x420),
+ INTC_VECT(TMU2, 0x440),
+ INTC_VECT(RTC_ATI, 0x480), INTC_VECT(RTC_PRI, 0x4a0),
+ INTC_VECT(RTC_CUI, 0x4c0),
+ INTC_VECT(WDT, 0x560),
+ INTC_VECT(REF, 0x580),
+};
+
+static struct intc_group groups[] = {
+ INTC_GROUP(RTC, RTC_ATI, RTC_PRI, RTC_CUI),
+ INTC_GROUP(DMAC1, DMAC_DEI0, DMAC_DEI1, DMAC_DEI2, DMAC_DEI3),
+ INTC_GROUP(SCIF0, SCIF0_ERI, SCIF0_RXI, SCIF0_BRI, SCIF0_TXI),
+ INTC_GROUP(SCIF1, SCIF1_ERI, SCIF1_RXI, SCIF1_BRI, SCIF1_TXI),
+ INTC_GROUP(DMAC2, DMAC_DEI4, DMAC_DEI5),
+ INTC_GROUP(SIOF0, SIOF0_ERI, SIOF0_TXI, SIOF0_RXI, SIOF0_CCI),
+ INTC_GROUP(SIOF1, SIOF1_ERI, SIOF1_TXI, SIOF1_RXI, SIOF1_CCI),
+};
+
+static struct intc_prio priorities[] = {
+ INTC_PRIO(DMAC1, 7),
+ INTC_PRIO(DMAC2, 7),
+ INTC_PRIO(SCIF0, 3),
+ INTC_PRIO(SCIF1, 3),
+ INTC_PRIO(SIOF0, 3),
+ INTC_PRIO(SIOF1, 3),
+ INTC_PRIO(EDMAC0, 5),
+ INTC_PRIO(EDMAC1, 5),
+ INTC_PRIO(EDMAC2, 5),
+};
+
+static struct intc_prio_reg prio_registers[] = {
+ { 0xfffffee2, 16, 4, /* IPRA */ { TMU0, TMU1, TMU2, RTC } },
+ { 0xfffffee4, 16, 4, /* IPRB */ { WDT, REF, 0, 0 } },
+ { 0xa4000016, 16, 4, /* IPRC */ { IRQ3, IRQ2, IRQ1, IRQ0 } },
+ { 0xa4000018, 16, 4, /* IPRD */ { 0, 0, IRQ4, IRQ5 } },
+ { 0xa400001a, 16, 4, /* IPRE */ { DMAC1, SCIF0, SCIF1 } },
+ { 0xa4080000, 16, 4, /* IPRF */ { IPSEC, DMAC2 } },
+ { 0xa4080002, 16, 4, /* IPRG */ { EDMAC0, EDMAC1, EDMAC2 } },
+ { 0xa4080004, 16, 4, /* IPRH */ { 0, 0, 0, SIOF0 } },
+ { 0xa4080006, 16, 4, /* IPRI */ { 0, 0, SIOF1 } },
+};
+
+static DECLARE_INTC_DESC(intc_desc, "sh7710", vectors, groups,
+ priorities, NULL, prio_registers, NULL);
+
+static struct intc_vect vectors_irq[] = {
+ INTC_VECT(IRQ0, 0x600), INTC_VECT(IRQ1, 0x620),
+ INTC_VECT(IRQ2, 0x640), INTC_VECT(IRQ3, 0x660),
+};
+
+static DECLARE_INTC_DESC(intc_desc_irq, "sh7710-irq", vectors_irq, NULL,
+ priorities, NULL, prio_registers, NULL);
+
+static struct resource rtc_resources[] = {
+ [0] = {
+ .start = 0xa413fec0,
+ .end = 0xa413fec0 + 0x1e,
+ .flags = IORESOURCE_IO,
+ },
+ [1] = {
+ .start = 20,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = 21,
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ .start = 22,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device rtc_device = {
+ .name = "sh-rtc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(rtc_resources),
+ .resource = rtc_resources,
+};
+
static struct plat_sci_port sci_platform_data[] = {
{
.mapbase = 0xa4400000,
@@ -20,7 +139,7 @@ static struct plat_sci_port sci_platform
.type = PORT_SCIF,
.irqs = { 52, 53, 55, 54 },
}, {
- .mapbase = 0xa4420000,
+ .mapbase = 0xa4410000,
.flags = UPF_BOOT_AUTOCONF,
.type = PORT_SCIF,
.irqs = { 56, 57, 59, 58 },
@@ -40,6 +159,7 @@ static struct platform_device sci_device
static struct platform_device *sh7710_devices[] __initdata = {
&sci_device,
+ &rtc_device,
};
static int __init sh7710_devices_setup(void)
@@ -49,59 +169,16 @@ static int __init sh7710_devices_setup(v
}
__initcall(sh7710_devices_setup);
-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 */
- { 27, 1, 12, 2 }, /* WDT ITI */
- { 20, 0, 0, 2 }, /* RTC ATI (alarm) */
- { 21, 0, 0, 2 }, /* RTC PRI (period) */
- { 22, 0, 0, 2 }, /* RTC CUI (carry) */
- { 48, 4, 12, 7 }, /* DMAC DMTE0 */
- { 49, 4, 12, 7 }, /* DMAC DMTE1 */
- { 50, 4, 12, 7 }, /* DMAC DMTE2 */
- { 51, 4, 12, 7 }, /* DMAC DMTE3 */
- { 52, 4, 8, 3 }, /* SCIF0 ERI */
- { 53, 4, 8, 3 }, /* SCIF0 RXI */
- { 54, 4, 8, 3 }, /* SCIF0 BRI */
- { 55, 4, 8, 3 }, /* SCIF0 TXI */
- { 56, 4, 4, 3 }, /* SCIF1 ERI */
- { 57, 4, 4, 3 }, /* SCIF1 RXI */
- { 58, 4, 4, 3 }, /* SCIF1 BRI */
- { 59, 4, 4, 3 }, /* SCIF1 TXI */
- { 76, 5, 8, 7 }, /* DMAC DMTE4 */
- { 77, 5, 8, 7 }, /* DMAC DMTE5 */
- { 80, 6, 12, 5 }, /* EDMAC EINT0 */
- { 81, 6, 8, 5 }, /* EDMAC EINT1 */
- { 82, 6, 4, 5 }, /* EDMAC EINT2 */
-};
-
-static unsigned long ipr_offsets[] = {
- 0xA414FEE2, /* 0: IPRA */
- 0xA414FEE4, /* 1: IPRB */
- 0xA4140016, /* 2: IPRC */
- 0xA4140018, /* 3: IPRD */
- 0xA414001A, /* 4: IPRE */
- 0xA4080000, /* 5: IPRF */
- 0xA4080002, /* 6: IPRG */
- 0xA4080004, /* 7: IPRH */
- 0xA4080006, /* 8: IPRI */
-};
-
-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-sh7710",
- },
-};
+void __init plat_irq_setup_pins(int mode)
+{
+ if (mode == IRQ_MODE_IRQ) {
+ register_intc_controller(&intc_desc_irq);
+ return;
+ }
+ BUG();
+}
void __init plat_irq_setup(void)
{
- register_ipr_controller(&ipr_irq_desc);
+ register_intc_controller(&intc_desc);
}
--- 0001/arch/sh/mm/Kconfig
+++ work/arch/sh/mm/Kconfig 2007-07-25 17:10:50.000000000 +0900
@@ -98,7 +98,7 @@ config CPU_SUBTYPE_SH7709
config CPU_SUBTYPE_SH7710
bool "Support SH7710 processor"
select CPU_SH3
- select CPU_HAS_IPR_IRQ
+ select CPU_HAS_INTC_IRQ
select CPU_HAS_DSP
help
Select SH7710 if you have a SH3-DSP SH7710 CPU.
@@ -106,7 +106,7 @@ config CPU_SUBTYPE_SH7710
config CPU_SUBTYPE_SH7712
bool "Support SH7712 processor"
select CPU_SH3
- select CPU_HAS_IPR_IRQ
+ select CPU_HAS_INTC_IRQ
select CPU_HAS_DSP
help
Select SH7712 if you have a SH3-DSP SH7712 CPU.
|
|
From: Paul M. <le...@li...> - 2007-07-25 04:10:16
|
On Wed, Jul 25, 2007 at 02:01:40PM +1000, David McCullough wrote: > > Jivin Magnus Damm lays it down ... > > On 7/25/07, David McCullough <Dav...@se...> wrote: > > > > > >Jivin Paul Mundt lays it down ... > > >> On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote: > > >> Since we're in the purging mood, perhaps it's also worth looking at some > > >> others: > > >> > > >> - snapgear boards are also unlikely to be revitalized, so that's > > >> probably another good candidate. > > > > > >How bad is it ? I am running 2.6.22 here on the snapgear boards and > > >it seems ok. I can send you some diffs if you want ? > > > > As of 2.6.23-rc1: > > > > The snapgear_defconfig seems to be out of sync with the rest of the > > Kconfig - both SH7751 and SH7751R are defined in the defconfig - this > > leads to that only SH7751 is selected which in turn leads to that > > CONFIG_SH_SECUREEDGE5410 never gets set. So the defconfig doesn't > > select the right board. I sent patches fixing a similar issue on r2d > > this a while ago. > > The CONFIG_SH_SECUREEDGE5410 define can (well used to) handle both > 7751 and 7751R CPU's and the kernel adjusted according to whatever HW it > booted on. > > Is this still possible ? > Yes, though at the moment it just expects 7751R. You can add 7751 to the depends on, though. > Ok, then I guess I need to be on 2.6.23-rc1, where is the git tree I > should clone to make patches against (yes I should check for the doc :-) > You can either use Linus's tree directly or sh-2.6.git: git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6.git I usually have Linus pull once a week or so, so either one is fine. There are a few things there that will be bound for -rc2 already. In any event, we'll certainly keep the board around now that we know what the intent is, which is usually what these sorts of board removal suggestions aim to stir up :-) |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 04:08:21
|
On 7/25/07, David McCullough <Dav...@se...> wrote: > Jivin Magnus Damm lays it down ... > > On 7/25/07, David McCullough <Dav...@se...> wrote: > > > > > >Jivin Paul Mundt lays it down ... > > >> On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote: > > >> Since we're in the purging mood, perhaps it's also worth looking at some > > >> others: > > >> > > >> - snapgear boards are also unlikely to be revitalized, so that's > > >> probably another good candidate. > > > > > >How bad is it ? I am running 2.6.22 here on the snapgear boards and > > >it seems ok. I can send you some diffs if you want ? > > > > As of 2.6.23-rc1: > > > > The snapgear_defconfig seems to be out of sync with the rest of the > > Kconfig - both SH7751 and SH7751R are defined in the defconfig - this > > leads to that only SH7751 is selected which in turn leads to that > > CONFIG_SH_SECUREEDGE5410 never gets set. So the defconfig doesn't > > select the right board. I sent patches fixing a similar issue on r2d > > this a while ago. > > The CONFIG_SH_SECUREEDGE5410 define can (well used to) handle both > 7751 and 7751R CPU's and the kernel adjusted according to whatever HW it > booted on. > > Is this still possible ? According to arch/sh/Kconfig, only 7751R is supported as of 2.6.23-rc1. So if the board can be populated with 7751 or 7751R, then the Kconfig needs to be updated. And maybe we should have two defconfigs to make sure that both combinations build... > > 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. > > Ok, then I guess I need to be on 2.6.23-rc1, where is the git tree I > should clone to make patches against (yes I should check for the doc :-) I built my stuff on top of 2.6.23-rc1 yesterday, but since then a few patches have been accepted by Paul. So use the sh-2.6 tree: http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=summary / magnus |
|
From: Paul M. <le...@li...> - 2007-07-25 03:51:55
|
On Wed, Jul 25, 2007 at 12:44:04PM +0900, Magnus Damm wrote: > On 7/25/07, David McCullough <Dav...@se...> wrote: > >Jivin Paul Mundt lays it down ... > >> On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote: > >> Since we're in the purging mood, perhaps it's also worth looking at some > >> others: > >> > >> - snapgear boards are also unlikely to be revitalized, so that's > >> probably another good candidate. > > > >How bad is it ? I am running 2.6.22 here on the snapgear boards and > >it seems ok. I can send you some diffs if you want ? > > As of 2.6.23-rc1: > > The snapgear_defconfig seems to be out of sync with the rest of the > Kconfig - both SH7751 and SH7751R are defined in the defconfig - this > leads to that only SH7751 is selected which in turn leads to that > CONFIG_SH_SECUREEDGE5410 never gets set. So the defconfig doesn't > select the right board. I sent patches fixing a similar issue on r2d > this a while ago. > > If the right board is selected using menuconfig, then > arch/sh/boards/snapgear/setup.c doesn't compile... > > So patches for defconfig and board support are more than welcome. =) > The defconfig parts are my fault, due to a lot of reordering for the machvec tidying. So people do need to make sure there are no surprises (a simple make oldconfig on -rc1 will leave quite a few boards in a not entirely expected state). > 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. > Yes, it's basically just the board bits and some other stuff that are out of sync. The rtc stubs have been broken for some time, and there hasn't been any feedback on this, either. If folks are actually using this board in recent kernels, then patches bringing it back in sync are certainly welcome ;-) I'd also like to add defacto board maintainers to MAINTAINERS so it's more obvious who to hassle when the board stops working. Stuff that's actively being used, we can roll in to the nightly builds so we can watch out for regressions and keep folks notified as to the status of their board in current git kernels. |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 03:44:07
|
On 7/25/07, David McCullough <Dav...@se...> wrote: > > Jivin Paul Mundt lays it down ... > > On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote: > > Since we're in the purging mood, perhaps it's also worth looking at some > > others: > > > > - snapgear boards are also unlikely to be revitalized, so that's > > probably another good candidate. > > How bad is it ? I am running 2.6.22 here on the snapgear boards and > it seems ok. I can send you some diffs if you want ? As of 2.6.23-rc1: The snapgear_defconfig seems to be out of sync with the rest of the Kconfig - both SH7751 and SH7751R are defined in the defconfig - this leads to that only SH7751 is selected which in turn leads to that CONFIG_SH_SECUREEDGE5410 never gets set. So the defconfig doesn't select the right board. I sent patches fixing a similar issue on r2d this a while ago. If the right board is selected using menuconfig, then arch/sh/boards/snapgear/setup.c doesn't compile... So patches for defconfig and board support are more than welcome. =) 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. Thanks! / magnus |
|
From: Magnus D. <mag...@gm...> - 2007-07-25 03:23:20
|
Hi Kristoffer, On 7/25/07, Kristoffer Ericson <kri...@gm...> wrote: > On Mon, 23 Jul 2007 15:00:54 +0900 > "Magnus Damm" <mag...@gm...> wrote: > > I'd be happy to convert the 7709 setup code to work with the new intc > > handler. And after that I can build pint support on top of intc as > > well. This needs to be tested though and I don't have any 7709 > > hardware around. So if anyone could help out testing things that would > > be great. That would at least solve the issue of converting the 7709 > > setup code to intc. > > Ive already started but sounds great. I'll post what Ive done so far. I have machines/people to test it. Thanks for posting your work. I spent part of yesterday unifying sh7706, sh7707, sh7708 and sh7709 support into sh770x.c, and this work unfortunately conflicts with your patch. Funny that we happen to hack on irq support simultaneously for this ancient processor. =) Your latest patch looks very similar to my sh770x stuff, but with prio_regs and IRQ pins as exceptions. Each enum_id element in the prio_regs array should map to a set of bits (4 bits in this case) that represent the priority that is defined by the data sheet. So for instance, the RTC-related interrupt sources all share the same priority using the enum_id RTC which is defined in the list of groups with RTC_ATI, RTC_PRI and RTC_CUI as members. The order of the elements in the prio_regs array may seem confusing - LSB is in [0] - this allows us to input information directly from the data sheet. For intc, enum_id 0 must be unused (you do the right thing) because it is used as a special case in the generic intc code to mark pieces of registers as unused (and to terminate the group list, see the INTC_GROUP() macro). Regarding the IRQ pins, IRQ0-IRQ3 can be used in IRL mode. So my sh770x patch doesn't register these pins by default to allow each board to select whatever mode they like. Great that you have people and hardware to test things. A while there I was thinking of trying to get my hands on a hp620, but if you can test then that's a much better solution. I have many things I need to hack on, and hp620 is just one of zillion platforms unfortunately. > > The only board-specific irq constants that i can find being used on > > hp6xx seem to be located in hp6xx.h except for the IRQ number for > > hd644661 which is located in the config file as CONFIG_HD64461_IRQ=36. > > These values all seem to map to IRQ pins. The irq number 93 otoh, it > > is associated with the pata_platform setup data in > > arch/sh/boards/hp6xx/setup.c and that is pretty close to PINT_IRQ_BASE > > which seems to be set to 86. So maybe we have a pint interrupt there > > after all... > > IRQ 0 is used to drive both PCMCIA/CF it maps against 94->95 and uses demux. Good that you know things about this. I'm confused though, do you mean that the CF is connected to the IRQ0 pin? hp6xx.h says something about a BTN_IRQ mapped on IRQ0. I suspect that the CF interrupt is connected to bit 7 in the PINTER register. This bit should be associated with Port C bit 7 if I've done my 7709 pintc homework correctly. =) You are talking about 94 and 95 too, are these other card detect interrupts for pccard hotplug? Are they connected to Port C bit 5 and 6? Thanks for your help! / magnus |
|
From: Paul M. <le...@li...> - 2007-07-25 03:10:43
|
On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote: > On Tue, Jul 24, 2007 at 11:46:52PM +0900, Magnus Damm wrote: > > sh: remove support for sh73180 and solution engine 73180 > > > > This patch removes old dead code: > > - kill off sh73180 cpu support > > - get rid of broken solution engine 73180 board support > > > > Signed-off-by: Magnus Damm <da...@ig...> > > Looks fine, thanks. > Since we're in the purging mood, perhaps it's also worth looking at some others: - edosk7705 and systemh can likely go, people have had the opportunity to speak up about these, but they seem intent to simply poke away at these out-of-tree. - mpc1211 and sh03 are a bit worrying. These used to see regular maintenance, but have since fallen off. Perhaps the vendor just needs some prodding to wake up, however. - snapgear boards are also unlikely to be revitalized, so that's probably another good candidate. With those out of the way or tidied up, we can also reexamine if we want to rework some of the board layout. The current scheme does not lend itself terribly well to sharing, and I'd also like to get some of the header mess in asm-sh/ tidied up. These will be 2.6.24 issues, though. |
|
From: Paul M. <le...@li...> - 2007-07-25 02:48:09
|
On Wed, Jul 25, 2007 at 11:38:20AM +0900, Magnus Damm wrote: > On 7/25/07, Paul Mundt <le...@li...> wrote: > >On Tue, Jul 24, 2007 at 11:45:08PM +0900, Magnus Damm wrote: > >> sh: remove support for sh7300 and solution engine 7300 > >> > >> This patch removes old dead code: > >> - kill off sh7300 cpu support > >> - get rid of broken solution engine 7300 board support > >> > >> arch/sh/kernel/cpu/sh3/clock-sh7710.c | 78 +++ > > > >This seems to have snuck in. I'll apply the rest of it with this part > >removed, but you may want to respin your SH7710 patches. You may also > >want to double check to make sure no other bits accidentally made it in. > > The file clock-sh7300.c is renamed to clock-7710.c as part of the > sh7300 removal. Both sh7710 and sh7300 are using the same clock file. > I can always keep the name unchanged of the clock-sh7300.c file if you > prefer that.. > It's generally considered bad form to have a rename and code changes in the same changeset. As there are no real functional changes here, I've applied it. I suppose both of the CPUs are currently broken, so we don't really have to worry about keeping bisect happy. |
25 messages has been excluded from this view by a project administrator.
