linuxsh-dev

[linuxsh-dev] PCMCIA driver for SH3 PCC module (partial)

[Jesper S. <js...@re...>]

Greetings people,

I've written a (partial) driver for the PCC PCMCIA module in some of
the SH3 CPUs (I have a SH7707 board).

Unfortunately, I cannot submit a patch that can be easily
integrated. This is mostly because it is not completed and is rather
hackish in some parts - and I will not be completing the driver (it
works well enough for me at this time).

Below are three sets of patches:

 o pcmcia.diff - this one contains the driver and its header file. At
   the top comment is a list of stuff that needs to be done to
   complete the driver.

 o asm.diff - interrupt hack definitions.

 o kernel.diff - this one contains a hack, remapping interrupts from
   the card to vector 11 (comes in at vector 62). If you have a board
   which uses another irq demux function, you'll have to integrate
   them. This interrupt stuff is the single biggest hack of the code;
   the PCMCIA driver layer expects interrupts to be in the range 0-15,
   and that just doesn't jive well with the PCC modules interrupts at
   vectors 62 and 63.

Please note that the driver is written for use with cs-pcmcia-3.19. I
simply copied the files from there into my kernel directory and it
works just fine.


You'll also need to remap the PCI driver's access to the PCMCIA IO
region using something like this:

--------------------------------------------------------------------

#define _P2SEGADDR(a)	((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | 0xb8000000))

void * _ioremap(unsigned long offset, unsigned long size)
{
#if 0
	return (void *) P2SEGADDR(offset);
#else
	/* FIXME:jskov Bad hack, redeirecting PCI access to the right region */
	if (offset < 0x10000)
		return (void *) _P2SEGADDR(offset);
	else
		return (void *) P2SEGADDR(offset);
#endif
}

void * _ioremap_nocache (unsigned long offset, unsigned long size)
{
#if 0
	return (void *) P2SEGADDR(offset);
#else
	/* FIXME:jskov Bad hack, redeirecting PCI access to the right region */
	if (offset < 0x10000)
		return (void *) _P2SEGADDR(offset);
	else
		return (void *) P2SEGADDR(offset);
#endif
}
--------------------------------------------------------------------

Finally, you need to add the necessary configury.


Even though the driver is not 100% complete, it still works well
enough for me to use an ethernet card in slot 0. I hope someone else
will find it useful.

Obviously, I'd be interested if anyone finds (or fixes) problems with
the driver.

Thanks,
Jesper

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Looks good to me.
Go for it.

Stuart

On Aug 3,  5:19pm, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Back from the dead
> 
> NIIBE Yutaka wrote:
>  > Besides, I think that it is better to use some linker magic for
>  > `all_vecs' handling.  Currently, when people want to add another
>  > system, he has to touch setup.c for the inclusion.  I think that we
>  > can add our own ELF section for the machine vector, then all that he
>  > need is adding the specific file and modify Makefile.  No need to
>  > touch other files.  Sounds good?
> 
> Like this one.  Any comments are appreciated.  If it's OK, I will add
> ChangeLog entries and commit this over the changes by Stuart.
> 
> Index: arch/sh/vmlinux.lds.S
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
> retrieving revision 1.5
> diff -u -r1.5 vmlinux.lds.S
> --- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
> +++ arch/sh/vmlinux.lds.S	2000/08/03 08:11:21
> @@ -61,6 +61,9 @@
>    __initcall_start = .;
>    .initcall.init : { *(.initcall.init) }
>    __initcall_end = .;
> +  __machvec_start = .;
> +  .machvec.init : { *(.machvec.init) }
> +  __machvec_end = .;
>    . = ALIGN(4096);
>    __init_end = .;
>  
> Index: include/asm-sh/machvec_init.h
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
> retrieving revision 1.1
> diff -u -r1.1 machvec_init.h
> --- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
> +++ include/asm-sh/machvec_init.h	2000/08/03 08:11:30
> @@ -26,11 +26,15 @@
>   * alias this one vector to alpha_mv, so no copy is needed.
>   *
>   * Upshot: set __initdata to nothing for non-GENERIC kernels.
> + *
> + * Note we do the same thing for the UNKNOWN kernel, as we need to write
> + * to the machine vector while setting it up.
>   */
>  
> -#ifdef CONFIG_SH_GENERIC
> +#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
>  #define __initmv __initdata
>  #define ALIAS_MV(x)
> +#define REGISTER_MV(x) long pointer_to_##x __attribute__((unused,__section__ (".machvec.init"))) = (long)&mv_##x;
>  #else
>  #define __initmv
>  
> @@ -44,6 +48,7 @@
>  #define ALIAS_MV(system) \
>    asm(".global sh_mv\nsh_mv = mv_"#system );
>  #endif
> +#define REGISTER_MV(x)
>  #endif /* GENERIC */
>  
>  #endif /* __SH_MACHVEC_INIT_H */
> Index: arch/sh/kernel/mach_hp600.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_hp600.c,v
> retrieving revision 1.3
> diff -u -r1.3 mach_hp600.c
> --- arch/sh/kernel/mach_hp600.c	2000/08/01 03:18:38	1.3
> +++ arch/sh/kernel/mach_hp600.c	2000/08/03 08:11:21
> @@ -61,3 +61,4 @@
>  	mv_hw_hd64461:		1,
>  };
>  ALIAS_MV(hp600)
> +REGISTER_MV(hp600)
> Index: arch/sh/kernel/mach_se.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_se.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach_se.c
> --- arch/sh/kernel/mach_se.c	2000/07/31 12:30:17	1.1
> +++ arch/sh/kernel/mach_se.c	2000/08/03 08:11:21
> @@ -78,3 +78,4 @@
>  	mv_hw_se:		1,
>  };
>  ALIAS_MV(se)
> +REGISTER_MV(se)
> Index: arch/sh/kernel/mach_unknown.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_unknown.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach_unknown.c
> --- arch/sh/kernel/mach_unknown.c	2000/07/31 12:30:36	1.1
> +++ arch/sh/kernel/mach_unknown.c	2000/08/03 08:11:21
> @@ -66,3 +66,4 @@
>  	mv_isa_port2addr:	unknown_isa_port2addr,
>  };
>  ALIAS_MV(unknown)
> +REGISTER_MV(unknown)
> Index: arch/sh/kernel/setup.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
> retrieving revision 1.10
> diff -u -r1.10 setup.c
> --- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
> +++ arch/sh/kernel/setup.c	2000/08/03 08:11:21
> @@ -63,16 +64,6 @@
>  extern int root_mountflags;
>  extern int _text, _etext, _edata, _end;
>  
> -/* __attribute__(weak) doesn't appear to do anything */
> -#define WEAK(X) \
> -	extern struct sh_machine_vector X; \
> -	asm(".weak "#X)
> -
> -WEAK(mv_unknown);
> -WEAK(mv_hp600);
> -WEAK(mv_od);
> -WEAK(mv_se);
> -
>  #define MV_NAME_SIZE 32
>  
>  static struct sh_machine_vector* __init get_mv_byname(const char* name);
> @@ -426,14 +471,11 @@
>  struct sh_machine_vector* __init get_mv_byname(const char* name)
>  {
>  	extern int strcasecmp(const char *, const char *);
> -	static struct sh_machine_vector *all_vecs[] __initlocaldata =
> -	{
> -		&mv_hp600,
> -		&mv_od,
> -		&mv_se,
> -	};
> +	extern long __machvec_start, __machvec_end;
> +	struct sh_machine_vector **all_vecs =
> +		(struct sh_machine_vector **)&__machvec_start;
>  
> -	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
> +	int i, n = (&__machvec_end - &__machvec_start);
>  
>  	for (i = 0; i < n; ++i) {
>  		struct sh_machine_vector *mv = all_vecs[i];
> Index: arch/sh/overdrive/mach.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/overdrive/mach.c,v
> retrieving revision 1.1
> diff -u -r1.1 mach.c
> --- arch/sh/overdrive/mach.c	2000/07/31 12:38:20	1.1
> +++ arch/sh/overdrive/mach.c	2000/08/03 08:11:21
> @@ -71,3 +71,4 @@
>  };
>  
>  ALIAS_MV(od)
> +REGISTER_MV(od)
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from gn...@ch...

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

YAEGASHI Takeshi wrote:
> 
> >  Anyway I have no idea why CONFIG_GDB_STUB_VBR exists at all. [...]
> 
> On my HP690 and Dreamcast, gdb stub code is loaded at 0xacff0000
> and VBR is also set there.  It jumps into 0xa0000000 on the
> reset regardless of VBR value.

  Hmm.  Perhaps a better solution than a config variable would be
to record the old value of the VBR register in trap_init() and
use that for stub trap delegation?  This should work on any system
and not need the user to figure out where his system's gdb VBR
table is loaded.  I can work up a patch for this tomorrow.


Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Jesper S. <js...@re...>]

>>>>> "YAEGASHI" == YAEGASHI Takeshi <yae...@ma...> writes:

YAEGASHI> Is there any plan to support SuperH at Red Hat? :->

Not that I know of. I suspect it's far too small a marked for a
distribution.

Jesper

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[YAEGASHI T. <yae...@ma...>]

Hi all,

>  The actual problem here is that the definition of CONFIG_GDB_STUB_VBR
>in
>config.in is wrongly dependant on CONFIG_DEBUG_KERNEL_WITH_GDB_STUB=y
>[instead of both the variables, or neither].

It's a change by me.  Sorry for my carelessness.


>  Anyway I have no idea why CONFIG_GDB_STUB_VBR exists at all.  I was
>under the impression that the value 0xa0000000 is essentially fixed by
>the CPU design, as a VBR needs to exist at physical 0x00000000 to handle
>resets and powerup.  But I'm sure there's a good reason.

On my HP690 and Dreamcast, gdb stub code is loaded at 0xacff0000
and VBR is also set there.  It jumps into 0xa0000000 on the
reset regardless of VBR value.


>  BTW, nice job Jesper ;-)

Yes, great contribution.

Is there any plan to support SuperH at Red Hat? :->

-
YAEGASHI Takeshi <yae...@ma...>

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> Jesper Skov writes:
>  > I don't know if this is right, but building without GDB
>  > support, but with CONFIG_SH_STANDARD_BIOS causes a failure
>  > since the STUB_VBR option is not defined.
> 
> This is bug of config.in.  I've fixed.  Thanks.
> --

  Arrrgh, you beat me to the punch ;-)

  For the edification of Jesper and anyone else who might care,
here's the explanation of what just happened (from the message
I'll now not need to send)...

  The code in entry.S which is activated by those #if's (specifically
the code at debug_kernel: which delegates certain traps to the BIOS'
or stub's trap handler) is needed in *both* these cases:

x  CONFIG_DEBUG_KERNEL_WITH_GDB_STUB=y
   so that traps which go to the stub (e.g. breakpoints) are delegated
   to the stub.

x  CONFIG_SH_EARLY_PRINTK=y
   so that traps which go the BIOS (i.e. BIOS calls) are delegated
   to the BIOS.

  The actual problem here is that the definition of CONFIG_GDB_STUB_VBR
in
config.in is wrongly dependant on CONFIG_DEBUG_KERNEL_WITH_GDB_STUB=y
[instead of both the variables, or neither].

  Anyway I have no idea why CONFIG_GDB_STUB_VBR exists at all.  I was
under the impression that the value 0xa0000000 is essentially fixed by
the CPU design, as a VBR needs to exist at physical 0x00000000 to handle
resets and powerup.  But I'm sure there's a good reason.

  BTW, nice job Jesper ;-)

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] sh-sci PPP fix

[NIIBE Y. <gn...@ch...>]

Jesper Skov wrote:
 > I tried using the SCI controller for a PPP connection, but it would
 > freeze after a few seconds. 
 > 
 > The reason is that the PPP driver is called from within the interrupt
 > handler, circumventing the bottom_handler locking which the PPP driver
 > relies on. 
 > 
 > The fix is to call the PPP driver from a softirq like it's done in
 > serial.c.

I see.  It seems tht all that we need is calling it from bottom half.
Then, we don't need to introduce our own task queue and bottom half
handler (I'm afraid of conflict of SERIAL_BH with standard serial
driver).  We can use IMMEDIATE_BH instead.  I've committed
IMMEDIATE_BH version.  Please check CVS repository.

Besides, I've installed your 7707 and semaphore fix.  Thanks a lot.
-- 

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[NIIBE Y. <gn...@ch...>]

Jesper Skov writes:
 > I don't know if this is right, but building without GDB
 > support, but with CONFIG_SH_STANDARD_BIOS causes a failure
 > since the STUB_VBR option is not defined.

This is bug of config.in.  I've fixed.  Thanks.
-- 

Re: [linuxsh-dev] Back from the dead

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> NIIBE Yutaka wrote:
>  > Besides, I think that it is better to use some linker magic for
>  > `all_vecs' handling.  [...]
> 
> Like this one.  Any comments are appreciated.  If it's OK, I will add
> ChangeLog entries and commit this over the changes by Stuart.
> 
> +  .machvec.init : { *(.machvec.init) }

  I like it.  Scales better than all_vecs and is consistent with
all the other linker magic tricks in the kernel.

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] SH-4 cache handling.

[NIIBE Y. <gn...@ch...>]

I've found SH-4 cache handling mistake.  When we don't have valid TLB
entries, flushing cache doesn't work well with current code.  I've
attached tentative patch below, which is better than nothing.

I'll commit the changes by Stuart (I/O base for "unkown"), and chenges
by me.  Then, I'll check Jesper's patches.

Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.12
diff -u -r1.12 cache.c
--- arch/sh/mm/cache.c	2000/07/19 11:22:47	1.12
+++ arch/sh/mm/cache.c	2000/08/05 04:28:18
@@ -209,10 +209,28 @@
 	 * 
 	 */
 	for (v = start; v < end; v+=L1_CACHE_BYTES) {
+#if 0
 		addr = CACHE_IC_ADDRESS_ARRAY |	(v&CACHE_IC_ENTRY_MASK)
 			| 0x8 /* A-bit */;
 		data = (v&0xfffffc00); /* Valid=0 */
 		ctrl_outl(data, addr);
+#else
+		/* No, we can't use A-bit.  If we don't have entry on ITLB,
+		 * the cache line is not handled correctly...
+		 */
+		/*
+		 * So... Flush possible two lines, anyway 
+		 */
+		addr = CACHE_IC_ADDRESS_ARRAY |	(v&CACHE_IC_ENTRY_MASK);
+		data = ctrl_inl(addr);
+		data = (data&0xfffffc00);
+		ctrl_outl(data, addr);
+
+		addr = addr ^ 0x1000;
+		data = ctrl_inl(addr);
+		data = (data&0xfffffc00);
+		ctrl_outl(data, addr);
+#endif
 	}
 	back_to_P1();
 }
@@ -225,8 +243,12 @@
  */
 void flush_icache_range(unsigned long start, unsigned long end)
 {
+	unsigned long flags;
+
+	save_and_cli(flags);
 	dcache_wback_range(start, end);
 	icache_purge_range(start, end);
+	restore_flags(flags);
 }
 
 /*
@@ -237,6 +259,7 @@
 void flush_icache_page(struct vm_area_struct *vma, struct page *pg)
 {
 	unsigned long phys, addr, data, i;
+	unsigned long flags;
 
 	/*
 	 * Alas, we don't know where the virtual address is,
@@ -246,6 +269,7 @@
 	/* Physical address of this page */
 	phys = (pg - mem_map)*PAGE_SIZE + __MEMORY_START;
 
+	save_and_cli(flags);
 	jump_to_P2();
 	/* Loop all the I-cache */
 	for (i=0; i<CACHE_IC_NUM_ENTRIES; i++) {
@@ -257,6 +281,7 @@
 		}
 	}
 	back_to_P1();
+	restore_flags(flags);
 }
 
 void flush_cache_all(void)
@@ -326,6 +351,7 @@
 	jump_to_P2();
 
 	for (v = start; v < end; v+=L1_CACHE_BYTES) {
+#if 0
 		addr = CACHE_OC_ADDRESS_ARRAY |
 			(v&CACHE_OC_ENTRY_PHYS_MASK) | 0x8 /* A-bit */;
 		data = (v&0xfffffc00); /* Update=0, Valid=0 */
@@ -335,6 +361,31 @@
 		ctrl_outl(data, addr | 0x1000);
 		ctrl_outl(data, addr | 0x2000);
 		ctrl_outl(data, addr | 0x3000);
+#else
+		/* No, we can't use A-bit.  If we don't have entry on UTLB,
+		 * the cache line is not handled correctly...
+		 */
+		/*
+		 * So... Flush possible two lines, anyway 
+		 */
+		/* Try all possible cases */
+
+		addr = CACHE_OC_ADDRESS_ARRAY | (v&CACHE_OC_ENTRY_PHYS_MASK);
+		data = ctrl_inl(addr) & 0xfffffc00;
+		ctrl_outl(data, addr);
+
+		addr ^= 0x1000;
+		data = ctrl_inl(addr) & 0xfffffc00;
+		ctrl_outl(data, addr);
+
+		addr ^= 0x2000;
+		data = ctrl_inl(addr) & 0xfffffc00;
+		ctrl_outl(data, addr);
+
+		addr ^= 0x1000;
+		data = ctrl_inl(addr) & 0xfffffc00;
+		ctrl_outl(data, addr);
+#endif
 	}
 	back_to_P1();
 }
@@ -355,10 +406,12 @@
 void flush_page_to_ram(struct page *pg)
 {
 	unsigned long phys, addr, data, i;
+	unsigned long flags;
 
 	/* Physical address of this page */
 	phys = (pg - mem_map)*PAGE_SIZE + __MEMORY_START;
 
+	save_and_cli(flags);
 	jump_to_P2();
 	/* Loop all the D-cache */
 	for (i=0; i<CACHE_OC_NUM_ENTRIES; i++) {
@@ -370,5 +423,6 @@
 		}
 	}
 	back_to_P1();
+	restore_flags(flags);
 }
 #endif
-- 

Re: [linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Jesper S. <js...@re...>]

>>>>> "Jesper" == Jesper Skov <js...@re...> writes:

Jesper> I don't know if this is right, but building without GDB
Jesper> support, but with CONFIG_SH_STANDARD_BIOS causes a failure
Jesper> since the STUB_VBR option is not defined.

Please note this patch is reversed. Sorry!

Jesper

[linuxsh-dev] sh-sci PPP fix

[Jesper S. <js...@re...>]

I tried using the SCI controller for a PPP connection, but it would
freeze after a few seconds. 

The reason is that the PPP driver is called from within the interrupt
handler, circumventing the bottom_handler locking which the PPP driver
relies on. 

The fix is to call the PPP driver from a softirq like it's done in
serial.c.

I've spoken with Rogier Wolff who wrote the SX driver which the SCI
driver is based on, and they do not have this problem, for the simple
reason that the SX controller will not interrupt until after a 10ms
delay - which gives the driver time enough to unwind to a safe state.

With the below I can mount NFS over the serial line via PPP.

Jesper



[note, patch is reversed! Sorry!]

diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P ../../devo/linux/linux-sh/drivers/char/sh-sci.c ./drivers/char/sh-sci.c
--- ../../devo/linux/linux-sh/drivers/char/sh-sci.c	Thu Aug  3 15:20:12 2000
+++ ./drivers/char/sh-sci.c	Thu Aug  3 14:36:27 2000
@@ -83,8 +83,6 @@
 static struct termios *sci_termios[SCI_NPORTS];
 static struct termios *sci_termios_locked[SCI_NPORTS];
 
-static DECLARE_TASK_QUEUE(tq_serial);
-
 int sci_refcount;
 int sci_debug = 0;
 
@@ -416,19 +414,6 @@
  *                   the interrupt related routines                       *
  * ********************************************************************** */
 
-/*
- * This routine is used by the interrupt handler to schedule
- * processing in the software interrupt portion of the driver.
- */
-static inline void rs_sched_event(struct sci_port *port,
-				  int event)
-{
-	port->event |= 1 << event;
-	queue_task(&port->tqueue, &tq_serial);
-	mark_bh(SERIAL_BH);
-}
-
-
 static void sci_transmit_chars(struct sci_port *port)
 {
 	int count, i;
@@ -486,8 +471,12 @@
 		port->gs.xmit_cnt -= count;
 	}
 
-	if (port->gs.xmit_cnt <= port->gs.wakeup_chars)
-		rs_sched_event(port, RS_EVENT_WRITE_WAKEUP);
+	if (port->gs.xmit_cnt <= port->gs.wakeup_chars) {
+		if ((port->gs.tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) &&
+		    port->gs.tty->ldisc.write_wakeup)
+			(port->gs.tty->ldisc.write_wakeup)(port->gs.tty);
+		wake_up_interruptible(&port->gs.tty->write_wait);
+	}
 
 	save_and_cli(flags);
 	ctrl = sci_in(port, SCSCR);
@@ -588,37 +577,6 @@
 	sci_tx_interrupt(irq, ptr, regs);
 }
 
-/*
- * This routine is used to handle the "bottom half" processing for the
- * serial driver, known also the "software interrupt" processing.
- * This processing is done at the kernel interrupt level, after the
- * rs_interrupt() has returned, BUT WITH INTERRUPTS TURNED ON.  This
- * is where time-consuming activities which can not be done in the
- * interrupt driver proper are done; the interrupt driver schedules
- * them using rs_sched_event(), and they get done here.
- */
-static void do_serial_bh(void)
-{
-	run_task_queue(&tq_serial);
-}
-
-static void do_softint(void *private_)
-{
-	struct sci_port *port = (struct sci_port *) private_;
-	struct tty_struct	*tty;
-	
-	tty = port->gs.tty;
-	if (!tty)
-		return;
-
-	if (test_and_clear_bit(RS_EVENT_WRITE_WAKEUP, &port->event)) {
-		if ((tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) &&
-		    tty->ldisc.write_wakeup)
-			(tty->ldisc.write_wakeup)(tty);
-		wake_up_interruptible(&tty->write_wait);
-	}
-}
-
 /* ********************************************************************** *
  *                Here are the routines that actually                     *
  *              interface with the generic_serial driver                  *
@@ -722,10 +680,6 @@
 	port->gs.tty = tty;
 	port->gs.count++;
 
-	port->event = 0;
-	port->tqueue.routine = do_softint;
-	port->tqueue.data = port;
-
 	/*
 	 * Start up serial port
 	 */
@@ -1007,7 +961,6 @@
 
 	printk("SuperH SCI(F) driver initialized\n");
 
-	init_bh(SERIAL_BH, do_serial_bh);
 	for (j=0; j<SCI_NPORTS; j++) {
 		port = &sci_ports[j];
 		printk("ttySC%d at 0x%08x is a %s\n", j, port->base,
@@ -1043,7 +996,6 @@
 	for (i=SCI_ERI_IRQ; i<SCI_TEI_IRQ; i++) /* XXX: irq_end?? */
 		free_irq(i, port);
 
-	remove_bh(SERIAL_BH);
 	tty_unregister_driver(&sci_driver);
 	tty_unregister_driver(&sci_callout_driver);
 }
diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P ../../devo/linux/linux-sh/drivers/char/sh-sci.h ./drivers/char/sh-sci.h
--- ../../devo/linux/linux-sh/drivers/char/sh-sci.h	Thu Aug  3 15:21:49 2000
+++ ./drivers/char/sh-sci.h	Thu Aug  3 14:36:27 2000
@@ -159,12 +159,6 @@
 
 #define SCI_MAGIC 0xbabeface
 
-/*
- * Events are used to schedule things to happen at timer-interrupt
- * time, instead of at rs interrupt time.
- */
-#define RS_EVENT_WRITE_WAKEUP	0
-
 struct sci_port {
 	struct gs_port gs;
 	int type;
@@ -173,8 +167,6 @@
 	void (*init_pins)(struct sci_port* port, unsigned int cflag);
 	unsigned int old_cflag;
 	struct async_icount icount;
-	struct tq_struct tqueue;
-	unsigned long event;
 };
 
 #define SCI_IN(size, offset)					\

[linuxsh-dev] Interrupt fix for 7707

[Jesper S. <js...@re...>]

Without this, serial interrupts are not initialized on the 7707.

Jesper

diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P ../../devo/linux/linux-sh/include/asm-sh/irq.h ./include/asm-sh/irq.h
--- ../../devo/linux/linux-sh/include/asm-sh/irq.h	Thu Aug  3 18:25:39 2000
+++ ./include/asm-sh/irq.h	Thu Aug  3 14:36:27 2000
@@ -39,7 +39,7 @@
 #define SCI_IPR_POS	1
 #define SCI_PRIORITY	3
 
-#if defined(CONFIG_CPU_SUBTYPE_SH7709)
+#if defined(CONFIG_CPU_SUBTYPE_SH7707) || defined(CONFIG_CPU_SUBTYPE_SH7709)
 #define SCIF_ERI_IRQ	56
 #define SCIF_RXI_IRQ	57
 #define SCIF_TXI_IRQ	59

[linuxsh-dev] semaphore.c fix

[Jesper S. <js...@re...>]

When enabling debugging in include/linux/spinlocks.h this definition
is missing.

Jesper


diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P ../../devo/linux/linux-sh/arch/sh/kernel/semaphore.c ./arch/sh/kernel/semaphore.c
--- ../../devo/linux/linux-sh/arch/sh/kernel/semaphore.c	Thu Aug  3 13:29:19 2000
+++ ./arch/sh/kernel/semaphore.c	Thu Aug  3 14:36:26 2000
@@ -12,6 +12,8 @@
 #include <asm/semaphore.h>
 #include <asm/semaphore-helper.h>
 
+spinlock_t semaphore_wake_lock;
+
 /*
  * Semaphores are implemented using a two-way counter:
  * The "count" variable is decremented for each process

[linuxsh-dev] Compile fix - CONFIG_GDB_STUB_VBR

[Jesper S. <js...@re...>]

I don't know if this is right, but building without GDB support, but
with CONFIG_SH_STANDARD_BIOS causes a failure since the STUB_VBR
option is not defined.

Jesper



diff -urN --exclude-from=/home/jskov/lib/diff-excludes -P ../../devo/linux/linux-sh/arch/sh/kernel/entry.S ./arch/sh/kernel/entry.S
--- ../../devo/linux/linux-sh/arch/sh/kernel/entry.S	Thu Aug  3 17:27:53 2000
+++ ./arch/sh/kernel/entry.S	Thu Aug  3 14:36:25 2000
@@ -182,7 +182,7 @@
 1:	.long	SYMBOL_NAME(do_page_fault)
 2:	.long	MMU_TEA
 
-#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB)
+#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
 	.align	2
 	/* Unwind the stack and jmp to the debug entry */
 debug_kernel:
@@ -224,7 +224,7 @@
 
 	.align	2
 debug_trap:	
-#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB)
+#if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
 	mov	#SR, $r0
 	mov.l	@($r0,$r15), $r0	! get status register
 	shll	$r0

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Updated.

2000-08-04  NIIBE Yutaka  <gn...@m1...>

	Machvec support.
	* arch/sh/kernel/setup.c: Remove WEAK references.
	(get_mv_byname): Use .macvec.init. section.
	* include/asm-sh/machvec_init.h (__initmv): Use
	.macvec.init. section.
	* arch/sh/vmlinux.lds.S (.machvec.init): Added new section for
	Machine Vector.

Index: arch/sh/vmlinux.lds.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
retrieving revision 1.5
diff -u -r1.5 vmlinux.lds.S
--- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
+++ arch/sh/vmlinux.lds.S	2000/08/04 03:14:22
@@ -61,6 +61,9 @@
   __initcall_start = .;
   .initcall.init : { *(.initcall.init) }
   __initcall_end = .;
+  __machvec_start = .;
+  .machvec.init : { *(.machvec.init) }
+  __machvec_end = .;
   . = ALIGN(4096);
   __init_end = .;
 
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.10
diff -u -r1.10 setup.c
--- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
+++ arch/sh/kernel/setup.c	2000/08/04 03:14:23
@@ -63,16 +64,6 @@
 extern int root_mountflags;
 extern int _text, _etext, _edata, _end;
 
-/* __attribute__(weak) doesn't appear to do anything */
-#define WEAK(X) \
-	extern struct sh_machine_vector X; \
-	asm(".weak "#X)
-
-WEAK(mv_unknown);
-WEAK(mv_hp600);
-WEAK(mv_od);
-WEAK(mv_se);
-
 #define MV_NAME_SIZE 32
 
 static struct sh_machine_vector* __init get_mv_byname(const char* name);
@@ -426,17 +471,16 @@
 struct sh_machine_vector* __init get_mv_byname(const char* name)
 {
 	extern int strcasecmp(const char *, const char *);
-	static struct sh_machine_vector *all_vecs[] __initlocaldata =
-	{
-		&mv_hp600,
-		&mv_od,
-		&mv_se,
-	};
-
-	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
+	extern long __machvec_start, __machvec_end;
+	struct sh_machine_vector *all_vecs =
+		(struct sh_machine_vector *)&__machvec_start;
+
+	int i, n = ((unsigned long)&__machvec_end
+		    - (unsigned long)&__machvec_start)/
+		sizeof(struct sh_machine_vector);
 
 	for (i = 0; i < n; ++i) {
-		struct sh_machine_vector *mv = all_vecs[i];
+		struct sh_machine_vector *mv = &all_vecs[i];
 		if (mv == NULL)
 			continue;
 		if (strcasecmp(name, mv->mv_name) == 0) {
Index: include/asm-sh/machvec_init.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
retrieving revision 1.1
diff -u -r1.1 machvec_init.h
--- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
+++ include/asm-sh/machvec_init.h	2000/08/04 03:14:34
@@ -26,10 +26,13 @@
  * alias this one vector to alpha_mv, so no copy is needed.
  *
  * Upshot: set __initdata to nothing for non-GENERIC kernels.
+ *
+ * Note we do the same thing for the UNKNOWN kernel, as we need to write
+ * to the machine vector while setting it up.
  */
 
-#ifdef CONFIG_SH_GENERIC
-#define __initmv __initdata
+#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
+#define __initmv __attribute__((unused,__section__ (".machvec.init")))
 #define ALIAS_MV(x)
 #else
 #define __initmv

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

NIIBE Yutaka wrote:
 > Besides, I think that it is better to use some linker magic for
 > `all_vecs' handling.  Currently, when people want to add another
 > system, he has to touch setup.c for the inclusion.  I think that we
 > can add our own ELF section for the machine vector, then all that he
 > need is adding the specific file and modify Makefile.  No need to
 > touch other files.  Sounds good?

Like this one.  Any comments are appreciated.  If it's OK, I will add
ChangeLog entries and commit this over the changes by Stuart.

Index: arch/sh/vmlinux.lds.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/vmlinux.lds.S,v
retrieving revision 1.5
diff -u -r1.5 vmlinux.lds.S
--- arch/sh/vmlinux.lds.S	2000/07/20 06:50:06	1.5
+++ arch/sh/vmlinux.lds.S	2000/08/03 08:11:21
@@ -61,6 +61,9 @@
   __initcall_start = .;
   .initcall.init : { *(.initcall.init) }
   __initcall_end = .;
+  __machvec_start = .;
+  .machvec.init : { *(.machvec.init) }
+  __machvec_end = .;
   . = ALIGN(4096);
   __init_end = .;
 
Index: include/asm-sh/machvec_init.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec_init.h,v
retrieving revision 1.1
diff -u -r1.1 machvec_init.h
--- include/asm-sh/machvec_init.h	2000/07/31 12:31:12	1.1
+++ include/asm-sh/machvec_init.h	2000/08/03 08:11:30
@@ -26,11 +26,15 @@
  * alias this one vector to alpha_mv, so no copy is needed.
  *
  * Upshot: set __initdata to nothing for non-GENERIC kernels.
+ *
+ * Note we do the same thing for the UNKNOWN kernel, as we need to write
+ * to the machine vector while setting it up.
  */
 
-#ifdef CONFIG_SH_GENERIC
+#if defined(CONFIG_SH_GENERIC) || defined(CONFIG_SH_UNKNOWN)
 #define __initmv __initdata
 #define ALIAS_MV(x)
+#define REGISTER_MV(x) long pointer_to_##x __attribute__((unused,__section__ (".machvec.init"))) = (long)&mv_##x;
 #else
 #define __initmv
 
@@ -44,6 +48,7 @@
 #define ALIAS_MV(system) \
   asm(".global sh_mv\nsh_mv = mv_"#system );
 #endif
+#define REGISTER_MV(x)
 #endif /* GENERIC */
 
 #endif /* __SH_MACHVEC_INIT_H */
Index: arch/sh/kernel/mach_hp600.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_hp600.c,v
retrieving revision 1.3
diff -u -r1.3 mach_hp600.c
--- arch/sh/kernel/mach_hp600.c	2000/08/01 03:18:38	1.3
+++ arch/sh/kernel/mach_hp600.c	2000/08/03 08:11:21
@@ -61,3 +61,4 @@
 	mv_hw_hd64461:		1,
 };
 ALIAS_MV(hp600)
+REGISTER_MV(hp600)
Index: arch/sh/kernel/mach_se.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_se.c,v
retrieving revision 1.1
diff -u -r1.1 mach_se.c
--- arch/sh/kernel/mach_se.c	2000/07/31 12:30:17	1.1
+++ arch/sh/kernel/mach_se.c	2000/08/03 08:11:21
@@ -78,3 +78,4 @@
 	mv_hw_se:		1,
 };
 ALIAS_MV(se)
+REGISTER_MV(se)
Index: arch/sh/kernel/mach_unknown.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_unknown.c,v
retrieving revision 1.1
diff -u -r1.1 mach_unknown.c
--- arch/sh/kernel/mach_unknown.c	2000/07/31 12:30:36	1.1
+++ arch/sh/kernel/mach_unknown.c	2000/08/03 08:11:21
@@ -66,3 +66,4 @@
 	mv_isa_port2addr:	unknown_isa_port2addr,
 };
 ALIAS_MV(unknown)
+REGISTER_MV(unknown)
Index: arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.10
diff -u -r1.10 setup.c
--- arch/sh/kernel/setup.c	2000/08/01 03:18:38	1.10
+++ arch/sh/kernel/setup.c	2000/08/03 08:11:21
@@ -63,16 +64,6 @@
 extern int root_mountflags;
 extern int _text, _etext, _edata, _end;
 
-/* __attribute__(weak) doesn't appear to do anything */
-#define WEAK(X) \
-	extern struct sh_machine_vector X; \
-	asm(".weak "#X)
-
-WEAK(mv_unknown);
-WEAK(mv_hp600);
-WEAK(mv_od);
-WEAK(mv_se);
-
 #define MV_NAME_SIZE 32
 
 static struct sh_machine_vector* __init get_mv_byname(const char* name);
@@ -426,14 +471,11 @@
 struct sh_machine_vector* __init get_mv_byname(const char* name)
 {
 	extern int strcasecmp(const char *, const char *);
-	static struct sh_machine_vector *all_vecs[] __initlocaldata =
-	{
-		&mv_hp600,
-		&mv_od,
-		&mv_se,
-	};
+	extern long __machvec_start, __machvec_end;
+	struct sh_machine_vector **all_vecs =
+		(struct sh_machine_vector **)&__machvec_start;
 
-	int i, n = sizeof(all_vecs)/sizeof(*all_vecs);
+	int i, n = (&__machvec_end - &__machvec_start);
 
 	for (i = 0; i < n; ++i) {
 		struct sh_machine_vector *mv = all_vecs[i];
Index: arch/sh/overdrive/mach.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/overdrive/mach.c,v
retrieving revision 1.1
diff -u -r1.1 mach.c
--- arch/sh/overdrive/mach.c	2000/07/31 12:38:20	1.1
+++ arch/sh/overdrive/mach.c	2000/08/03 08:11:21
@@ -71,3 +71,4 @@
 };
 
 ALIAS_MV(od)
+REGISTER_MV(od)

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > If there is no good reason for this, great, I'll re-combine them.

AFAIK, there's no good reason here.  Please go ahead.

Besides, I think that it is better to use some linker magic for
`all_vecs' handling.  Currently, when people want to add another
system, he has to touch setup.c for the inclusion.  I think that we
can add our own ELF section for the machine vector, then all that he
need is adding the specific file and modify Makefile.  No need to
touch other files.  Sounds good?
-- 

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Niibe-san

Thanks for this. I wasn't able to test it before I posted as my
SolutionEngine has just been fried (the power supply was accidently
changed from 5V to 9V) and the Overdrive only has PCI I/O.

When I first did this work I only had one port2addr function. However I
got a bit confused by the code in the SolutionEngine io_se.c. There
appears to be different handling for PCMCIA I/O addresses (which doesn't
look finished...) and I/O to the SMSC SuperIO controller. I've never
played with PCMCIA, so don't really understand the issues, and kept
to two separate for this reason. If there is no good reason for this, 
great, I'll re-combine them.

Stuart

On Aug 2,  6:17pm, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Back from the dead
> 
> Stuart, I needed following one-liner patch to use the command line:
> 
> 	sh_mv=unknown,a4000000,1
> 
> for my board (CqREEK SH-4 with ISA/ATA Bridge).
> 
> I'm not sure why we have both of mv_port2addr and mv_isa_port2addr.
> One is enough, isn't it?  I think that in/out is for ISA(-like)
> interface.
> 
> --- arch/sh/kernel/io_generic.c	Wed Aug  2 18:06:36 2000
> +++ arch/sh/kernel/io_generic.c.new	Wed Aug  2 17:26:23 2000
> @@ -23,7 +23,7 @@
>  #define DUMMY_READ_AREA6	  0xba000000
>  #endif
>  
> -#define PORT2ADDR(x) (sh_mv.mv_port2addr(x))
> +#define PORT2ADDR(x) (sh_mv.mv_isa_port2addr(x))
>  
>  unsigned long generic_io_base;
>  
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from gn...@ch...

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart, I needed following one-liner patch to use the command line:

	sh_mv=unknown,a4000000,1

for my board (CqREEK SH-4 with ISA/ATA Bridge).

I'm not sure why we have both of mv_port2addr and mv_isa_port2addr.
One is enough, isn't it?  I think that in/out is for ISA(-like)
interface.

--- arch/sh/kernel/io_generic.c	Wed Aug  2 18:06:36 2000
+++ arch/sh/kernel/io_generic.c.new	Wed Aug  2 17:26:23 2000
@@ -23,7 +23,7 @@
 #define DUMMY_READ_AREA6	  0xba000000
 #endif
 
-#define PORT2ADDR(x) (sh_mv.mv_port2addr(x))
+#define PORT2ADDR(x) (sh_mv.mv_isa_port2addr(x))
 
 unsigned long generic_io_base;
 

[linuxsh-dev] Re: Back from the dead

[Tomoyoshi A. <as...@us...>]

Hello Stuart-san and all.

On Tue, 1 Aug 2000 18:26:55 +0100
Stuart Menefy <Stu...@st...> wrote:

> 
> I'll probably need to add support for the HD64465 at some point in the
> next few months, and hope to be able to use the HD64461 code as a
> starting point, so we'll see what happens then.
> 
> Stuart
> 

I'm Tomoyoshi ASANO.
I'm working at Lineo.

We ported linuxsh cvs code for HSA ASPEN/TAHOE board
last month.

The ASPEN board has a SH7750 and the TAHOE board which 
is the dauther board of ASEPN has a HD64465.
So we have some codes for HD64465.

Do you plan to wrok for the same board?

I want to provide these codes for HSA ASPEN/TAHOE board.
But I don't know how to marge the code to cvs well.
Please give me suggestion to do it.

But the current linuxsh cvs code is changed around I/O and
interrupt recently, so I have not fixed it yet.

And I'm busy this week and the next week.
I hope do it at the last of this month.

Tom
--

Re: [linuxsh-dev] Back from the dead

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > Its easier to do it than try and explain it. See what you think about
 > the attached patches.
 > 
 > The sh_mv command line option now takes two parameters, the I/O base
 > address, and whether to enable memory mapped I/O. For example:
 >   sh_mv=unknown,0xa8000000,1

Great.  That's the one I wanted.

When people try to port the kernel to their own board __at the first
time__, they have nothing.  With the patch like you made, people just
could try it out.  That's great value, I think.
-- 

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Folks

> I think that we should support I/O for "unknown" (bare) machine.
> Currently, there's no I/O support for "unknown" board.  This is kind
> of backward.

I'm not sure. My thinking was that for a really unknown machine (i.e.
one which is not yet specifically supported) because you don't know
where any off-chip peripherials are it was better to not attempt any
I/O at all....

> I'm thinking adding BIOS call to get I/O offset and interface type
> and such.

...however if we can pass extra information into the kernel (BIOS
and/or command line), then it makes sense to support it.

[Time passes, several attempts to put what I'm thinking into words fail.]

Its easier to do it than try and explain it. See what you think about
the attached patches.

The sh_mv command line option now takes two parameters, the I/O base
address, and whether to enable memory mapped I/O. For example:
  sh_mv=unknown,0xa8000000,1

Stuart

Re: [linuxsh-dev] Back from the dead

[Stuart M. <Stu...@st...>]

Yaegashi-san

> Hmm, there were so big changes.  I've hunted some bugs for HP600.

Thanks for doing this. I did my best not to break it, but was
probably inevitable that I would!

> I think that io_hd64461.[ch] are a kind of generic I/O routines
> for the system using HD64461 and should be used under
> CONFIG_SH_HP600 for now.  I'll create new files as io_hp600.[ch]
> if needed in future.

I think with support chips like this, it is hard to distinguish what is
machine specific and what is chip specific, especially when there is
only one example of such a machine! But I agree, it is useful to have
as a reference point for a machine with no other I/O requirements.

I'll probably need to add support for the HD64465 at some point in the
next few months, and hope to be able to use the HD64461 code as a
starting point, so we'll see what happens then.

Stuart

Re: [linuxsh-dev] Back from the dead

[Mitch D. <mj...@al...>]

NIIBE Yutaka wrote:
> 
> I think that we should support I/O for "unknown" (bare) machine.
> Currently, there's no I/O support for "unknown" board.  This is kind
> of backward.
> 
> I'm thinking adding BIOS call to get I/O offset and interface type
> and such.

Excellent.  Then the job of getting the kernel to work on a new
board would be reduced to writing the correct BIOS self-description
routines.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!