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: NIIBE Y. <gn...@m1...> - 2001-05-09 06:30:42
|
Ian da Silva wrote: > I posted a patch today that adds support for the SH7751's built-in PCI > controller on the 7751 Solution Engine. This patch needs to be applied > on top of Dustin's Big Sur/PCI patch. His patch provides all the > underlying support for the SH7751's PCI controller. My patch simply > extends support to the 7751 Solution Engine. > > I've been using these patches in my kernel so that I can the ethernet > controller, which lies off the PCI bus on the 7751 Solution Engine. > > Please send me your comments, feedback, etc. Great! Besides, it is very good because it reminds me Dustin's great work. I'll look incorporate your works. My response is so late for Dustin's work. I'm sorry. Last month, I'm bit busy to sync-up standard kernel. I assume that both works is OK for distributed under GPL. I mean, it's OK for you to include the patches to standard kernel, and let people to hack with that. -- |
|
From: Ian da S. <ida...@mv...> - 2001-05-08 16:38:15
|
I posted a patch today that adds support for the SH7751's built-in PCI controller on the 7751 Solution Engine. This patch needs to be applied on top of Dustin's Big Sur/PCI patch. His patch provides all the underlying support for the SH7751's PCI controller. My patch simply extends support to the 7751 Solution Engine. I've been using these patches in my kernel so that I can the ethernet controller, which lies off the PCI bus on the 7751 Solution Engine. Please send me your comments, feedback, etc. Ian. |
|
From: Jaswinder S. <jas...@3d...> - 2001-05-07 03:17:27
|
Dear Niibe-san, I was comparing sti and cli in Linux for different architectures . I found that for SH it is little bit longer , can we reduce some steps in it and make it more efficient. same story with __save_flags and __save_and_cli . Thanks , Happy Hacking !! Jaswinder. -- These are my opinions not 3Di. |
|
From: Masahiro A. <m-...@aa...> - 2001-05-07 00:28:05
|
On Mon, 7 May 2001 09:06:57 +0900 (JST) NIIBE Yutaka <gn...@m1...> wrote: > Masahiro Abe wrote: > > -segment.h is added(copied from alpha), as it is needed by some drivers. > > We have been having it in CVS, but I don't like it, IMNSHO. Why not > fix drivers? Simply, I thought that adding segment.h will make number of changes lower. But I can understand that adding this file will have kind of "side effects". I'll revisit this later. +-------------------------------------+ | Masahiro Abe, Software Engineer | | A&D Co., Ltd. of Tokyo, Japan | | mailto:m-...@aa... | +-------------------------------------+ |This is my opinion, not my employer's| +-------------------------------------+ |
|
From: NIIBE Y. <gn...@m1...> - 2001-05-07 00:07:07
|
Masahiro Abe wrote: > -processor.h and user.h changes are for making them consistent with > sigcontext.h. Definition of fpu bank1 register is changed from "long > long" to "long" in sigcontext.h, so that those two files are changed > similarly. Actually, it seems those fields are not accessed at all. But > I thought those should match sigcontext.h so as not to make confusion. Well done. Installed. > -segment.h is added(copied from alpha), as it is needed by some drivers. We have been having it in CVS, but I don't like it, IMNSHO. Why not fix drivers? -- |
|
From: Masahiro A. <m-...@aa...> - 2001-05-03 07:52:56
|
Hi, I have 3 small change requests to linux-sh kernel. I don't know if those are already in CVS, but if not, can someone take care of those (only if those are OK)? -processor.h and user.h changes are for making them consistent with sigcontext.h. Definition of fpu bank1 register is changed from "long long" to "long" in sigcontext.h, so that those two files are changed similarly. Actually, it seems those fields are not accessed at all. But I thought those should match sigcontext.h so as not to make confusion. -segment.h is added(copied from alpha), as it is needed by some drivers. I made those changes to stock 2.4.4 kernel, along with Sugioka-san's semaphore-patch and rtc-patch (posted to this list). Compiled and booted on SolutionEngine 7750S. I put patch files (including changes in this mail) to our server below. <ftp://ftp.aandd.co.jp/pub/linuxsh/20010503/> Most of those changes are by Sugioka-san. Many many thanks to him. (I may update my instruction/patches next week.) -----[request for changes BEGIN]----- diff -ruN linux-2.4.4.orig/include/asm-sh/processor.h linux-2.4.4-sh.orig/include/asm-sh/processor.h --- linux-2.4.4.orig/include/asm-sh/processor.h Thu May 3 13:53:37 2001 +++ linux-2.4.4-sh.orig/include/asm-sh/processor.h Thu May 3 16:11:08 2001 @@ -76,7 +76,7 @@ struct sh_fpu_hard_struct { unsigned long fp_regs[16]; - unsigned long long xd_regs[8]; + unsigned long xfp_regs[16]; unsigned long fpscr; unsigned long fpul; @@ -86,7 +86,7 @@ /* Dummy fpu emulator */ struct sh_fpu_soft_struct { unsigned long fp_regs[16]; - unsigned long long xd_regs[8]; + unsigned long xfp_regs[16]; unsigned long fpscr; unsigned long fpul; diff -ruN linux-2.4.4.orig/include/asm-sh/segment.h linux-2.4.4-sh.orig/include/asm-sh/segment.h --- linux-2.4.4.orig/include/asm-sh/segment.h Thu Jan 1 09:00:00 1970 +++ linux-2.4.4-sh.orig/include/asm-sh/segment.h Fri Apr 27 10:15:18 2001 @@ -0,0 +1,6 @@ +#ifndef __SH_SEGMENT_H +#define __SH_SEGMENT_H + +/* Only here because we have some old header files that expect it.. */ + +#endif diff -ruN linux-2.4.4.orig/include/asm-sh/user.h linux-2.4.4-sh.orig/include/asm-sh/user.h --- linux-2.4.4.orig/include/asm-sh/user.h Tue Mar 28 03:26:15 2000 +++ linux-2.4.4-sh.orig/include/asm-sh/user.h Thu May 3 15:12:10 2001 @@ -31,7 +31,7 @@ struct user_fpu_struct { unsigned long fp_regs[16]; - unsigned long long xd_regs[8]; + unsigned long xfp_regs[16]; unsigned long fpscr; unsigned long fpul; }; -----[request for changes END]----- +-------------------------------------+ | Masahiro Abe, Software Engineer | | A&D Co., Ltd. of Tokyo, Japan | | mailto:m-...@aa... | +-------------------------------------+ |This is my opinion, not my employer's| +-------------------------------------+ |
|
From: NIIBE Y. <gn...@m1...> - 2001-04-23 23:50:55
|
SUGIOKA Toshinobu wrote:
> OK, I removed the change of drivers/char/rtc.c ,
> and added RTC_UIP (RTC updating) bit emulation
> as your suggestion.
Thanks, please commit it in.
M. R. Brown wrote:
> There is a problem from my standpoint - this has no hope of working on the
> Dreamcast, which is a SH7750 (mostly) *without* a working RTC. This was the
> reason Philip Rumpf and NIIBE added the mv_rtc_{get,set}timeofday functions
> to the machvec. Actually from the LinuxDC side, I have implemented the DC
> RTC routines (there on the sound chip) and there in the merge that I can
> hopefully finish and commit this afternoon.
Yes, this is important issue. Please go ahead.
Note that /dev/rtc is optional device, while {get,set}timeofday is
required feature. I think that the patch made by Sugioka-san and your
work are basically orthogonal.
Only hwclock uses /dev/rtc. If we could support IRQ with /dev/rtc,
other (special) software could use it, though.
Hence, I think that the patch by Sugioka-san is quite useful at this
time.
> What I'm saying is it'd be infinitely cooler to implement this using the
> machvec routines, where you would never have a problem with compatibility.
> I had actually starting thinking a bit about this, if you give me a day or so
> I can try to get a patch for review.
Yes, you could generalize the /dev/rtc more.
--
|
|
From: M. R. B. <mrb...@0x...> - 2001-04-23 14:04:23
|
* SUGIOKA Toshinobu <su...@it...> on Mon, Apr 23, 2001:
> At 15:28 01/04/23 +0900, NIIBE Yutaka wrote:
> >I know that this is the way of handling SH's RTC in the manual, but we
> >could implement rtc_is_updating, such as checking R64CNT is near 0 or
> >not (with some safety). Errr... well, the implementation depends on
> >architecture, SH-3 or SH-4.
>
> OK, I removed the change of drivers/char/rtc.c ,
> and added RTC_UIP (RTC updating) bit emulation
> as your suggestion.
>
> I tested RTC_RD_TIME ioctl function several hundred million times,
> and found no errors. It seems that RTC_UIP bit works fine on SH7709A.
>
There is a problem from my standpoint - this has no hope of working on the
Dreamcast, which is a SH7750 (mostly) *without* a working RTC. This was the
reason Philip Rumpf and NIIBE added the mv_rtc_{get,set}timeofday functions
to the machvec. Actually from the LinuxDC side, I have implemented the DC
RTC routines (there on the sound chip) and there in the merge that I can
hopefully finish and commit this afternoon.
What I'm saying is it'd be infinitely cooler to implement this using the
machvec routines, where you would never have a problem with compatibility.
I had actually starting thinking a bit about this, if you give me a day or so
I can try to get a patch for review.
M. R.
|
|
From: SUGIOKA T. <su...@it...> - 2001-04-23 13:54:39
|
At 15:28 01/04/23 +0900, NIIBE Yutaka wrote:
>I know that this is the way of handling SH's RTC in the manual, but we
>could implement rtc_is_updating, such as checking R64CNT is near 0 or
>not (with some safety). Errr... well, the implementation depends on
>architecture, SH-3 or SH-4.
OK, I removed the change of drivers/char/rtc.c ,
and added RTC_UIP (RTC updating) bit emulation
as your suggestion.
I tested RTC_RD_TIME ioctl function several hundred million times,
and found no errors. It seems that RTC_UIP bit works fine on SH7709A.
+ do { \
+ ctrl_outb(rcr1, RCR1); /* clear CF */ \
+ r64cnt = ctrl_inb(R64CNT); \
+ } while((ctrl_inb(RCR1) & RCR1_CF) && retry++ < 1000);\
This loops about 120 times (maximum) with SH7709A(59MHz).
-------------------------------------------------------------------
Changes
* config.in: Added CONFIG_RTC.
* arch/sh/rtc.c: Moved some definitions to include/asm-sh/rtc.h.
* include/asm-sh/rtc.h: Likewise
* include/asm-sh/mc146818rtc.h (RTC_PORT, RTC_IRQ, CMOS_READ,
CMOS_WRITE, __CMOS_READ, __CMOS_WRITE): Defined.
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.36
diff -u -r1.36 config.in
--- arch/sh/config.in 2001/04/20 01:24:03 1.36
+++ arch/sh/config.in 2001/04/23 13:23:19
@@ -255,6 +255,7 @@
dep_tristate 'Support for user-space parallel port device drivers'
CONFIG_PPDEV $CONFIG_PARPORT
fi
bool 'PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
+tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
endmenu
if [ "$CONFIG_HOTPLUG" = "y" -a "$CONFIG_PCMCIA" != "n" ]; then
Index: arch/sh/kernel/rtc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/rtc.c,v
retrieving revision 1.7
diff -u -r1.7 rtc.c
--- arch/sh/kernel/rtc.c 2001/02/24 07:34:52 1.7
+++ arch/sh/kernel/rtc.c 2001/04/23 13:23:20
@@ -13,62 +13,6 @@
#include <asm/io.h>
#include <asm/rtc.h>
-/* RCR1 Bits */
-#define RCR1_CF 0x80 /* Carry Flag */
-#define RCR1_CIE 0x10 /* Carry Interrupt Enable */
-#define RCR1_AIE 0x08 /* Alarm Interrupt Enable */
-#define RCR1_AF 0x01 /* Alarm Flag */
-
-/* RCR2 Bits */
-#define RCR2_PEF 0x80 /* PEriodic interrupt Flag */
-#define RCR2_PESMASK 0x70 /* Periodic interrupt Set */
-#define RCR2_RTCEN 0x08 /* ENable RTC */
-#define RCR2_ADJ 0x04 /* ADJustment (30-second) */
-#define RCR2_RESET 0x02 /* Reset bit */
-#define RCR2_START 0x01 /* Start bit */
-
-#if defined(__sh3__)
-/* SH-3 RTC */
-#define R64CNT 0xfffffec0
-#define RSECCNT 0xfffffec2
-#define RMINCNT 0xfffffec4
-#define RHRCNT 0xfffffec6
-#define RWKCNT 0xfffffec8
-#define RDAYCNT 0xfffffeca
-#define RMONCNT 0xfffffecc
-#define RYRCNT 0xfffffece
-#define RSECAR 0xfffffed0
-#define RMINAR 0xfffffed2
-#define RHRAR 0xfffffed4
-#define RWKAR 0xfffffed6
-#define RDAYAR 0xfffffed8
-#define RMONAR 0xfffffeda
-#define RCR1 0xfffffedc
-#define RCR2 0xfffffede
-
-#define RTC_BIT_INVERTED 0 /* No bug on SH7708, SH7709A */
-#elif defined(__SH4__)
-/* SH-4 RTC */
-#define R64CNT 0xffc80000
-#define RSECCNT 0xffc80004
-#define RMINCNT 0xffc80008
-#define RHRCNT 0xffc8000c
-#define RWKCNT 0xffc80010
-#define RDAYCNT 0xffc80014
-#define RMONCNT 0xffc80018
-#define RYRCNT 0xffc8001c /* 16bit */
-#define RSECAR 0xffc80020
-#define RMINAR 0xffc80024
-#define RHRAR 0xffc80028
-#define RWKAR 0xffc8002c
-#define RDAYAR 0xffc80030
-#define RMONAR 0xffc80034
-#define RCR1 0xffc80038
-#define RCR2 0xffc8003c
-
-#define RTC_BIT_INVERTED 0x40 /* bug on SH7750, SH7750S */
-#endif
-
#ifndef BCD_TO_BIN
#define BCD_TO_BIN(val) ((val)=((val)&15) + ((val)>>4)*10)
#endif
Index: include/asm-sh/mc146818rtc.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/mc146818rtc.h,v
retrieving revision 1.1
diff -u -r1.1 mc146818rtc.h
--- include/asm-sh/mc146818rtc.h 2001/04/18 18:28:35 1.1
+++ include/asm-sh/mc146818rtc.h 2001/04/23 13:23:37
@@ -4,6 +4,156 @@
#ifndef _ASM_MC146818RTC_H
#define _ASM_MC146818RTC_H
-/* empty include file to satisfy the include in genrtc.c */
+#include <asm/rtc.h>
+#define RTC_ALWAYS_BCD 1
+
+/* FIXME:RTC Interrupt feature is not implemented yet. */
+#undef RTC_IRQ
+#define RTC_IRQ 0
+
+#if defined(__sh3__)
+#define RTC_PORT(n) (R64CNT+(n)*2)
+#define CMOS_READ(addr) __CMOS_READ(addr,b)
+#define CMOS_WRITE(val,addr) __CMOS_WRITE(val,addr,b)
+
+#elif defined(__SH4__)
+#define RTC_PORT(n) (R64CNT+(n)*4)
+#define CMOS_READ(addr) __CMOS_READ(addr,w)
+#define CMOS_WRITE(val,addr) __CMOS_WRITE(val,addr,w)
+#endif
+
+#define __CMOS_READ(addr, s) ({ \
+ unsigned char val=0, rcr1, rcr2, r64cnt, retry; \
+ switch(addr) { \
+ case RTC_SECONDS: \
+ val = ctrl_inb(RSECCNT); \
+ break; \
+ case RTC_SECONDS_ALARM: \
+ val = ctrl_inb(RSECAR); \
+ break; \
+ case RTC_MINUTES: \
+ val = ctrl_inb(RMINCNT); \
+ break; \
+ case RTC_MINUTES_ALARM: \
+ val = ctrl_inb(RMINAR); \
+ break; \
+ case RTC_HOURS: \
+ val = ctrl_inb(RHRCNT); \
+ break; \
+ case RTC_HOURS_ALARM: \
+ val = ctrl_inb(RHRAR); \
+ break; \
+ case RTC_DAY_OF_WEEK: \
+ val = ctrl_inb(RWKCNT); \
+ break; \
+ case RTC_DAY_OF_MONTH: \
+ val = ctrl_inb(RDAYCNT); \
+ break; \
+ case RTC_MONTH: \
+ val = ctrl_inb(RMONCNT); \
+ break; \
+ case RTC_YEAR: \
+ val = ctrl_in##s(RYRCNT); \
+ break; \
+ case RTC_REG_A: /* RTC_FREQ_SELECT */ \
+ rcr2 = ctrl_inb(RCR2); \
+ val = (rcr2 & RCR2_PESMASK) >> 4; \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr1 = (rcr1 & (RCR1_CIE | RCR1_AIE)) | RCR1_AF;\
+ retry = 0; \
+ do { \
+ ctrl_outb(rcr1, RCR1); /* clear CF */ \
+ r64cnt = ctrl_inb(R64CNT); \
+ } while((ctrl_inb(RCR1) & RCR1_CF) && retry++ < 1000);\
+ r64cnt ^= RTC_BIT_INVERTED; \
+ if(r64cnt == 0x7f || r64cnt == 0) \
+ val |= RTC_UIP; \
+ break; \
+ case RTC_REG_B: /* RTC_CONTROL */ \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ if(rcr1 & RCR1_CIE) val |= RTC_UIE; \
+ if(rcr1 & RCR1_AIE) val |= RTC_AIE; \
+ if(rcr2 & RCR2_PESMASK) val |= RTC_PIE; \
+ if(!(rcr2 & RCR2_START))val |= RTC_SET; \
+ val |= RTC_24H; \
+ break; \
+ case RTC_REG_C: /* RTC_INTR_FLAGS */ \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr1 &= ~(RCR1_CF | RCR1_AF); \
+ ctrl_outb(rcr1, RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ rcr2 &= ~RCR2_PEF; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_D: /* RTC_VALID */ \
+ /* Always valid ... */ \
+ val = RTC_VRT; \
+ break; \
+ default: \
+ break; \
+ } \
+ val; \
+})
+
+#define __CMOS_WRITE(val, addr, s) ({ \
+ unsigned char rcr1,rcr2; \
+ switch(addr) { \
+ case RTC_SECONDS: \
+ ctrl_outb(val, RSECCNT); \
+ break; \
+ case RTC_SECONDS_ALARM: \
+ ctrl_outb(val, RSECAR); \
+ break; \
+ case RTC_MINUTES: \
+ ctrl_outb(val, RMINCNT); \
+ break; \
+ case RTC_MINUTES_ALARM: \
+ ctrl_outb(val, RMINAR); \
+ break; \
+ case RTC_HOURS: \
+ ctrl_outb(val, RHRCNT); \
+ break; \
+ case RTC_HOURS_ALARM: \
+ ctrl_outb(val, RHRAR); \
+ break; \
+ case RTC_DAY_OF_WEEK: \
+ ctrl_outb(val, RWKCNT); \
+ break; \
+ case RTC_DAY_OF_MONTH: \
+ ctrl_outb(val, RDAYCNT); \
+ break; \
+ case RTC_MONTH: \
+ ctrl_outb(val, RMONCNT); \
+ break; \
+ case RTC_YEAR: \
+ ctrl_out##s((ctrl_in##s(RYRCNT) & 0xff00) | (val & 0xff), RYRCNT);\
+ break; \
+ case RTC_REG_A: /* RTC_FREQ_SELECT */ \
+ rcr2 = ctrl_inb(RCR2); \
+ if((val & RTC_DIV_CTL) == RTC_DIV_RESET2) \
+ rcr2 |= RCR2_RESET; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_B: /* RTC_CONTROL */ \
+ rcr1 = (ctrl_inb(RCR1) & 0x99) | RCR1_AF; \
+ if(val & RTC_AIE) rcr1 |= RCR1_AIE; \
+ else rcr1 &= ~RCR1_AIE; \
+ if(val & RTC_UIE) rcr1 |= RCR1_CIE; \
+ else rcr1 &= ~RCR1_CIE; \
+ ctrl_outb(rcr1, RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ if(val & RTC_SET) rcr2 &= ~RCR2_START; \
+ else rcr2 |= RCR2_START; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_C: /* RTC_INTR_FLAGS */ \
+ break; \
+ case RTC_REG_D: /* RTC_VALID */ \
+ break; \
+ default: \
+ break; \
+ } \
+})
#endif /* _ASM_MC146818RTC_H */
Index: include/asm-sh/rtc.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/rtc.h,v
retrieving revision 1.1
diff -u -r1.1 rtc.h
--- include/asm-sh/rtc.h 2000/12/26 00:07:14 1.1
+++ include/asm-sh/rtc.h 2001/04/23 13:23:37
@@ -9,4 +9,60 @@
extern void sh_rtc_gettimeofday(struct timeval *tv);
extern int sh_rtc_settimeofday(const struct timeval *tv);
+/* RCR1 Bits */
+#define RCR1_CF 0x80 /* Carry Flag */
+#define RCR1_CIE 0x10 /* Carry Interrupt Enable */
+#define RCR1_AIE 0x08 /* Alarm Interrupt Enable */
+#define RCR1_AF 0x01 /* Alarm Flag */
+
+/* RCR2 Bits */
+#define RCR2_PEF 0x80 /* PEriodic interrupt Flag */
+#define RCR2_PESMASK 0x70 /* Periodic interrupt Set */
+#define RCR2_RTCEN 0x08 /* ENable RTC */
+#define RCR2_ADJ 0x04 /* ADJustment (30-second) */
+#define RCR2_RESET 0x02 /* Reset bit */
+#define RCR2_START 0x01 /* Start bit */
+
+#if defined(__sh3__)
+/* SH-3 RTC */
+#define R64CNT 0xfffffec0
+#define RSECCNT 0xfffffec2
+#define RMINCNT 0xfffffec4
+#define RHRCNT 0xfffffec6
+#define RWKCNT 0xfffffec8
+#define RDAYCNT 0xfffffeca
+#define RMONCNT 0xfffffecc
+#define RYRCNT 0xfffffece
+#define RSECAR 0xfffffed0
+#define RMINAR 0xfffffed2
+#define RHRAR 0xfffffed4
+#define RWKAR 0xfffffed6
+#define RDAYAR 0xfffffed8
+#define RMONAR 0xfffffeda
+#define RCR1 0xfffffedc
+#define RCR2 0xfffffede
+
+#define RTC_BIT_INVERTED 0 /* No bug on SH7708, SH7709A */
+#elif defined(__SH4__)
+/* SH-4 RTC */
+#define R64CNT 0xffc80000
+#define RSECCNT 0xffc80004
+#define RMINCNT 0xffc80008
+#define RHRCNT 0xffc8000c
+#define RWKCNT 0xffc80010
+#define RDAYCNT 0xffc80014
+#define RMONCNT 0xffc80018
+#define RYRCNT 0xffc8001c /* 16bit */
+#define RSECAR 0xffc80020
+#define RMINAR 0xffc80024
+#define RHRAR 0xffc80028
+#define RWKAR 0xffc8002c
+#define RDAYAR 0xffc80030
+#define RMONAR 0xffc80034
+#define RCR1 0xffc80038
+#define RCR2 0xffc8003c
+
+#define RTC_BIT_INVERTED 0x40 /* bug on SH7750, SH7750S */
+#endif
+
#endif /* _ASM_RTC_H */
--------------------------------------------------------------------
----
SUGIOKA Toshinobu
|
|
From: NIIBE Y. <gn...@m1...> - 2001-04-23 06:29:04
|
SUGIOKA Toshinobu wrote:
> This patch implements 'Enhanced RTC Support' by emulating
> MC146868 with CMOS_READ/CMOS_WRITE macros.
> However, drivers/char/rtc.c should be modified slightly,
> since emulation is incomplete.
>
> 'hwclock' command now works on my board(SH7709A) with this patch.
Great. Looks good.
I just am afraid of there's need to support real MC146868 in some
cases. Say, Hitachi Solution Engine has another RTC.
Besides, I think that we only could change the function
rtc_is_updating.
> Index: drivers/char/rtc.c
> ===================================================================
[...]
> +#ifdef __sh__
> + do {
> + ctrl_outb((ctrl_inb(RCR1) & (RCR1_CIE | RCR1_AIE)) | RCR1_AF, RCR1); /*
> Clear CF */
> +#else
> if (rtc_is_updating() != 0)
> while (jiffies - uip_watchdog < 2*HZ/100)
> barrier();
> +#endif
>
> /*
> * Only the values that we read from the RTC are set. We leave
I know that this is the way of handling SH's RTC in the manual, but we
could implement rtc_is_updating, such as checking R64CNT is near 0 or
not (with some safety). Errr... well, the implementation depends on
architecture, SH-3 or SH-4.
--
|
|
From: SUGIOKA T. <su...@it...> - 2001-04-23 06:06:16
|
Hi All.
This patch implements 'Enhanced RTC Support' by emulating
MC146868 with CMOS_READ/CMOS_WRITE macros.
However, drivers/char/rtc.c should be modified slightly,
since emulation is incomplete.
'hwclock' command now works on my board(SH7709A) with this patch.
How do you think about this approach ?
-------------------------------------------------------------------
Changes
* config.in: Added CONFIG_RTC.
* arch/sh/rtc.c: Moved some definitions to include/asm-sh/rtc.h.
* include/asm-sh/rtc.h: Likewise
* include/asm-sh/mc146818rtc.h (RTC_PORT, RTC_IRQ, CMOS_READ,
CMOS_WRITE, __CMOS_READ, __CMOS_WRITE): Defined.
* drivers/char/rtc.c: Added SH specific 'read RTC' operation.
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.36
diff -u -r1.36 config.in
--- arch/sh/config.in 2001/04/20 01:24:03 1.36
+++ arch/sh/config.in 2001/04/23 04:59:10
@@ -255,6 +255,7 @@
dep_tristate 'Support for user-space parallel port device drivers'
CONFIG_PPDEV $CONFIG_PARPORT
fi
bool 'PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
+tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
endmenu
if [ "$CONFIG_HOTPLUG" = "y" -a "$CONFIG_PCMCIA" != "n" ]; then
Index: arch/sh/kernel/rtc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/rtc.c,v
retrieving revision 1.7
diff -u -r1.7 rtc.c
--- arch/sh/kernel/rtc.c 2001/02/24 07:34:52 1.7
+++ arch/sh/kernel/rtc.c 2001/04/23 04:59:10
@@ -13,62 +13,6 @@
#include <asm/io.h>
#include <asm/rtc.h>
-/* RCR1 Bits */
-#define RCR1_CF 0x80 /* Carry Flag */
-#define RCR1_CIE 0x10 /* Carry Interrupt Enable */
-#define RCR1_AIE 0x08 /* Alarm Interrupt Enable */
-#define RCR1_AF 0x01 /* Alarm Flag */
-
-/* RCR2 Bits */
-#define RCR2_PEF 0x80 /* PEriodic interrupt Flag */
-#define RCR2_PESMASK 0x70 /* Periodic interrupt Set */
-#define RCR2_RTCEN 0x08 /* ENable RTC */
-#define RCR2_ADJ 0x04 /* ADJustment (30-second) */
-#define RCR2_RESET 0x02 /* Reset bit */
-#define RCR2_START 0x01 /* Start bit */
-
-#if defined(__sh3__)
-/* SH-3 RTC */
-#define R64CNT 0xfffffec0
-#define RSECCNT 0xfffffec2
-#define RMINCNT 0xfffffec4
-#define RHRCNT 0xfffffec6
-#define RWKCNT 0xfffffec8
-#define RDAYCNT 0xfffffeca
-#define RMONCNT 0xfffffecc
-#define RYRCNT 0xfffffece
-#define RSECAR 0xfffffed0
-#define RMINAR 0xfffffed2
-#define RHRAR 0xfffffed4
-#define RWKAR 0xfffffed6
-#define RDAYAR 0xfffffed8
-#define RMONAR 0xfffffeda
-#define RCR1 0xfffffedc
-#define RCR2 0xfffffede
-
-#define RTC_BIT_INVERTED 0 /* No bug on SH7708, SH7709A */
-#elif defined(__SH4__)
-/* SH-4 RTC */
-#define R64CNT 0xffc80000
-#define RSECCNT 0xffc80004
-#define RMINCNT 0xffc80008
-#define RHRCNT 0xffc8000c
-#define RWKCNT 0xffc80010
-#define RDAYCNT 0xffc80014
-#define RMONCNT 0xffc80018
-#define RYRCNT 0xffc8001c /* 16bit */
-#define RSECAR 0xffc80020
-#define RMINAR 0xffc80024
-#define RHRAR 0xffc80028
-#define RWKAR 0xffc8002c
-#define RDAYAR 0xffc80030
-#define RMONAR 0xffc80034
-#define RCR1 0xffc80038
-#define RCR2 0xffc8003c
-
-#define RTC_BIT_INVERTED 0x40 /* bug on SH7750, SH7750S */
-#endif
-
#ifndef BCD_TO_BIN
#define BCD_TO_BIN(val) ((val)=((val)&15) + ((val)>>4)*10)
#endif
Index: drivers/char/rtc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/rtc.c,v
retrieving revision 1.8
diff -u -r1.8 rtc.c
--- drivers/char/rtc.c 2001/01/06 02:52:41 1.8
+++ drivers/char/rtc.c 2001/04/23 04:59:14
@@ -40,9 +40,10 @@
* 1.10b Andrew Morton: SMP lock fix
* 1.10c Cesar Barros: SMP locking fixes and cleanup
* 1.10d Paul Gortmaker: delete paranoia check in rtc_exit
+ * 1.10e Sugioka Toshinobu: SuperH version.
*/
-#define RTC_VERSION "1.10d"
+#define RTC_VERSION "1.10e"
#define RTC_IO_EXTENT 0x10 /* Only really two ports, but... */
@@ -902,9 +903,14 @@
* Once the read clears, read the RTC time (again via ioctl). Easy.
*/
+#ifdef __sh__
+ do {
+ ctrl_outb((ctrl_inb(RCR1) & (RCR1_CIE | RCR1_AIE)) | RCR1_AF, RCR1); /*
Clear CF */
+#else
if (rtc_is_updating() != 0)
while (jiffies - uip_watchdog < 2*HZ/100)
barrier();
+#endif
/*
* Only the values that we read from the RTC are set. We leave
@@ -921,6 +927,9 @@
rtc_tm->tm_year = CMOS_READ(RTC_YEAR);
ctrl = CMOS_READ(RTC_CONTROL);
spin_unlock_irq(&rtc_lock);
+#ifdef __sh__
+ } while((ctrl_inb(RCR1) & RCR1_CF) != 0 && jiffies - uip_watchdog <
2*HZ/100);
+#endif
if (!(ctrl & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
{
Index: include/asm-sh/mc146818rtc.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/mc146818rtc.h,v
retrieving revision 1.1
diff -u -r1.1 mc146818rtc.h
--- include/asm-sh/mc146818rtc.h 2001/04/18 18:28:35 1.1
+++ include/asm-sh/mc146818rtc.h 2001/04/23 04:59:37
@@ -4,6 +4,148 @@
#ifndef _ASM_MC146818RTC_H
#define _ASM_MC146818RTC_H
-/* empty include file to satisfy the include in genrtc.c */
+#include <asm/rtc.h>
+
+#define RTC_ALWAYS_BCD 1
+
+/* FIXME:RTC Interrupt feature is not implemented yet. */
+#undef RTC_IRQ
+#define RTC_IRQ 0
+
+#if defined(__sh3__)
+#define RTC_PORT(n) (R64CNT+n*2)
+#define CMOS_READ(addr) __CMOS_READ(addr,b)
+#define CMOS_WRITE(val,addr) __CMOS_WRITE(val,addr,b)
+
+#elif defined(__SH4__)
+#define RTC_PORT(n) (R64CNT+n*4)
+#define CMOS_READ(addr) __CMOS_READ(addr,w)
+#define CMOS_WRITE(val,addr) __CMOS_WRITE(val,addr,w)
+#endif
+
+#define __CMOS_READ(addr, s) ({ \
+ unsigned char val=0, rcr1,rcr2; \
+ switch(addr) { \
+ case RTC_SECONDS: \
+ val = ctrl_inb(RSECCNT); \
+ break; \
+ case RTC_SECONDS_ALARM: \
+ val = ctrl_inb(RSECAR); \
+ break; \
+ case RTC_MINUTES: \
+ val = ctrl_inb(RMINCNT); \
+ break; \
+ case RTC_MINUTES_ALARM: \
+ val = ctrl_inb(RMINAR); \
+ break; \
+ case RTC_HOURS: \
+ val = ctrl_inb(RHRCNT); \
+ break; \
+ case RTC_HOURS_ALARM: \
+ val = ctrl_inb(RHRAR); \
+ break; \
+ case RTC_DAY_OF_WEEK: \
+ val = ctrl_inb(RWKCNT); \
+ break; \
+ case RTC_DAY_OF_MONTH: \
+ val = ctrl_inb(RDAYCNT); \
+ break; \
+ case RTC_MONTH: \
+ val = ctrl_inb(RMONCNT); \
+ break; \
+ case RTC_YEAR: \
+ val = ctrl_in##s(RYRCNT); \
+ break; \
+ case RTC_REG_A: /* RTC_FREQ_SELECT */ \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ val = (rcr2 & RCR2_PESMASK) >> 4; \
+ break; \
+ case RTC_REG_B: /* RTC_CONTROL */ \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ if(rcr1 & RCR1_CIE) val |= RTC_UIE; \
+ if(rcr1 & RCR1_AIE) val |= RTC_AIE; \
+ if(rcr2 & RCR2_PESMASK) val |= RTC_PIE; \
+ if(!(rcr2 & RCR2_START))val |= RTC_SET; \
+ val |= RTC_24H; \
+ break; \
+ case RTC_REG_C: /* RTC_INTR_FLAGS */ \
+ rcr1 = ctrl_inb(RCR1); \
+ rcr1 &= ~(RCR1_CF | RCR1_AF); \
+ ctrl_outb(rcr1, RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ rcr2 &= ~RCR2_PEF; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_D: /* RTC_VALID */ \
+ /* Always valid ... */ \
+ val = RTC_VRT; \
+ break; \
+ default: \
+ break; \
+ } \
+ val; \
+})
+
+#define __CMOS_WRITE(val, addr, s) ({ \
+ unsigned char rcr1,rcr2; \
+ switch(addr) { \
+ case RTC_SECONDS: \
+ ctrl_outb(val, RSECCNT); \
+ break; \
+ case RTC_SECONDS_ALARM: \
+ ctrl_outb(val, RSECAR); \
+ break; \
+ case RTC_MINUTES: \
+ ctrl_outb(val, RMINCNT); \
+ break; \
+ case RTC_MINUTES_ALARM: \
+ ctrl_outb(val, RMINAR); \
+ break; \
+ case RTC_HOURS: \
+ ctrl_outb(val, RHRCNT); \
+ break; \
+ case RTC_HOURS_ALARM: \
+ ctrl_outb(val, RHRAR); \
+ break; \
+ case RTC_DAY_OF_WEEK: \
+ ctrl_outb(val, RWKCNT); \
+ break; \
+ case RTC_DAY_OF_MONTH: \
+ ctrl_outb(val, RDAYCNT); \
+ break; \
+ case RTC_MONTH: \
+ ctrl_outb(val, RMONCNT); \
+ break; \
+ case RTC_YEAR: \
+ ctrl_out##s((ctrl_in##s(RYRCNT) & 0xff00) | (val & 0xff), RYRCNT);\
+ break; \
+ case RTC_REG_A: /* RTC_FREQ_SELECT */ \
+ rcr2 = ctrl_inb(RCR2); \
+ if((val & RTC_DIV_CTL) == RTC_DIV_RESET2) \
+ rcr2 |= RCR2_RESET; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_B: /* RTC_CONTROL */ \
+ rcr1 = (ctrl_inb(RCR1) & 0x99) | RCR1_AF; \
+ if(val & RTC_AIE) rcr1 |= RCR1_AIE; \
+ else rcr1 &= ~RCR1_AIE; \
+ if(val & RTC_UIE) rcr1 |= RCR1_CIE; \
+ else rcr1 &= ~RCR1_CIE; \
+ ctrl_outb(rcr1, RCR1); \
+ rcr2 = ctrl_inb(RCR2); \
+ if(val & RTC_SET) rcr2 &= ~RCR2_START; \
+ else rcr2 |= RCR2_START; \
+ ctrl_outb(rcr2, RCR2); \
+ break; \
+ case RTC_REG_C: /* RTC_INTR_FLAGS */ \
+ break; \
+ case RTC_REG_D: /* RTC_VALID */ \
+ break; \
+ default: \
+ break; \
+ } \
+})
#endif /* _ASM_MC146818RTC_H */
Index: include/asm-sh/rtc.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/rtc.h,v
retrieving revision 1.1
diff -u -r1.1 rtc.h
--- include/asm-sh/rtc.h 2000/12/26 00:07:14 1.1
+++ include/asm-sh/rtc.h 2001/04/23 04:59:37
@@ -9,4 +9,60 @@
extern void sh_rtc_gettimeofday(struct timeval *tv);
extern int sh_rtc_settimeofday(const struct timeval *tv);
+/* RCR1 Bits */
+#define RCR1_CF 0x80 /* Carry Flag */
+#define RCR1_CIE 0x10 /* Carry Interrupt Enable */
+#define RCR1_AIE 0x08 /* Alarm Interrupt Enable */
+#define RCR1_AF 0x01 /* Alarm Flag */
+
+/* RCR2 Bits */
+#define RCR2_PEF 0x80 /* PEriodic interrupt Flag */
+#define RCR2_PESMASK 0x70 /* Periodic interrupt Set */
+#define RCR2_RTCEN 0x08 /* ENable RTC */
+#define RCR2_ADJ 0x04 /* ADJustment (30-second) */
+#define RCR2_RESET 0x02 /* Reset bit */
+#define RCR2_START 0x01 /* Start bit */
+
+#if defined(__sh3__)
+/* SH-3 RTC */
+#define R64CNT 0xfffffec0
+#define RSECCNT 0xfffffec2
+#define RMINCNT 0xfffffec4
+#define RHRCNT 0xfffffec6
+#define RWKCNT 0xfffffec8
+#define RDAYCNT 0xfffffeca
+#define RMONCNT 0xfffffecc
+#define RYRCNT 0xfffffece
+#define RSECAR 0xfffffed0
+#define RMINAR 0xfffffed2
+#define RHRAR 0xfffffed4
+#define RWKAR 0xfffffed6
+#define RDAYAR 0xfffffed8
+#define RMONAR 0xfffffeda
+#define RCR1 0xfffffedc
+#define RCR2 0xfffffede
+
+#define RTC_BIT_INVERTED 0 /* No bug on SH7708, SH7709A */
+#elif defined(__SH4__)
+/* SH-4 RTC */
+#define R64CNT 0xffc80000
+#define RSECCNT 0xffc80004
+#define RMINCNT 0xffc80008
+#define RHRCNT 0xffc8000c
+#define RWKCNT 0xffc80010
+#define RDAYCNT 0xffc80014
+#define RMONCNT 0xffc80018
+#define RYRCNT 0xffc8001c /* 16bit */
+#define RSECAR 0xffc80020
+#define RMINAR 0xffc80024
+#define RHRAR 0xffc80028
+#define RWKAR 0xffc8002c
+#define RDAYAR 0xffc80030
+#define RMONAR 0xffc80034
+#define RCR1 0xffc80038
+#define RCR2 0xffc8003c
+
+#define RTC_BIT_INVERTED 0x40 /* bug on SH7750, SH7750S */
+#endif
+
#endif /* _ASM_RTC_H */
-----------------------------------------------------------------------
----
SUGIOKA Toshinobu
|
|
From: NIIBE Y. <gn...@m1...> - 2001-04-23 02:30:56
|
Well, CVS can't handle to remove directory. How about following:
(1) Just change arch/sh/config.in and Makefile not supporting
Overdrive any more.
(2) Leave the directory Overdrive as is. It is just for reference.
(3) I won't send the files under arch/sh/overdrive for inclusion of
Linux.
Some README file under arch/sh/overdrive would be good to avoid
confusion.
--
|
|
From: Greg B. <gb...@po...> - 2001-04-21 14:27:44
|
Stuart Menefy wrote: > > The only down side is we'd end up with an 'empty' directory in CVS, > which may confuse people who forget to use the 'prune' option on > CVS checkouts and updates. Do you know if SourceForge provide a way > to really delete directories? I don't believe they offer anything other than what you get with "cvs admin". You might be able to repeatedly "cvs admin -o" but it wouldn't be worth the effort. I don't think the empty directory is such a big problem. Greg. -- These are my opinions not PPIs. |
|
From: Stuart M. <Stu...@st...> - 2001-04-20 17:44:18
|
Niibe-san I was hoping that the SH7750 Overdrive hardware, and the corrisponding directory in the source tree, would have been made obsolete by now. This was only a prototype board, and the ST40STB1 boards should have replaced it by now. I should know by now that killing off old hardware is hard to do, especially in the Linux world! So while I don't expect there to be any more new 7750 Overdrive users, there are some existing ones I have to continue to support for a while longer. However, virtually all the people using the board are taking kernel releases from ST, and I understand it's a pain having just one thing we don't sync with the main kernel sources. So I'd be quite happy to delete the directory from SourceForge, and I'll just keep the SH7750 Overdrive support as a patch. There is no active development on this part of the kernel any more, so this wouldn't be a real problem. I'd really rather it didn't go into the main kernel, The only down side is we'd end up with an 'empty' directory in CVS, which may confuse people who forget to use the 'prune' option on CVS checkouts and updates. Do you know if SourceForge provide a way to really delete directories? Stuart On Apr 20, 1:28pm, gn...@m1... wrote: > Subject: [linuxsh-dev] Synchronization to Linux 2.4.x series > > I've sent Dreamcast drivers. > > Next, I'll send the part of stboards and overdrive. > > In overdrive, we have one big file, overdrive.ttf (>200KB). It seems > that it is FPGA data. Is there any way let it small? > -- > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev >-- End of excerpt from gn...@m1... |
|
From: NIIBE Y. <gn...@m1...> - 2001-04-20 04:29:07
|
I've sent Dreamcast drivers. Next, I'll send the part of stboards and overdrive. In overdrive, we have one big file, overdrive.ttf (>200KB). It seems that it is FPGA data. Is there any way let it small? -- |
|
From: Masahiro A. <m-...@aa...> - 2001-04-20 00:31:13
|
Hi all, [This is a duplicate of email I've sent to lin...@m1... yesterday.] I wrote three documents, each describes execution sequence of sh-ipl+g, sh-lilo, and LinuxSH kernel. Those are put here and open to public. [English] <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/sh-ipl+g_sequence_E.txt> <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/sh-lilo_sequence_E.txt> <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/linux-sh-kernel-bootup_E.txt> [Japanese] <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/sh-ipl+g_sequence_J.txt> <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/sh-lilo_sequence_J.txt> <ftp://ftp.aandd.co.jp/pub/linuxsh/doc/linux-sh-kernel-bootup_J.txt> Please note that those are not "DEFINITIVE". I believe those must contain many mistakes because of my lack of knowledge and experience. Also my poor English skill may contribute to them. If you are interested, please read them with suspicion in your mind. If you notify me any errors found, I'd really appreciate and will correct them. Thank you for your time. +-------------------------------------+ | Masahiro Abe, Software Engineer | | A&D Co., Ltd. of Tokyo, Japan | | mailto:m-...@aa... | +-------------------------------------+ |This is my opinion, not my employer's| +-------------------------------------+ |
|
From: NIIBE Y. <gn...@m1...> - 2001-04-20 00:07:47
|
SUGIOKA Toshinobu wrote: > current cvs source tree seems broken around rw_semaphore since few days ago. > I just fixed so that it could be build. Thanks a lot. I've been sync-ing to/from current pre-patches. Most of the work has merged into standard kernel. Next is dreamcast drivers. If there's no objection, I'd like to send Overdrive and STboard part too. > -extern __inline__ void down(struct semaphore * sem) > +static inline void down(struct semaphore * sem) Yes, static inline is good. The use of extern inline in Linux is old one (at that time, Linux developpers misunderstood "inline" means specification but actually it's just a hint to compiler). Compiler is free not to expand into inline. Besides, I think __inline__ (enclosed with __) is better for header file, if there is possibility for that file to be included by user program. User program may be written in K&R, in which the keyword inline is not supported, and user are free to use the word inline (say, #define inline). To avoid conflict, using __ is good idea. The meaning is same for GCC. I know that current header files of Linux SH is not consistent... -- |
|
From: SUGIOKA T. <su...@it...> - 2001-04-19 16:14:23
|
Hi all.
current cvs source tree seems broken around rw_semaphore since few days ago.
I just fixed so that it could be build.
I will commit this soon.
2001-04-20 SUGIOKA Toshinobu <su...@it...>
* arch/sh/config.in: define CONFIG_RWSEM_GENERIC.
* include/asm-sh/bitops.h (__set_bit, __clear_bit): defined.
* include/asm-sh/semaphore.h: Follow i386 implementation.
* include/linux/rwsem.h: small fix.
* lib/rwsem.c: Added include linux/bitops.h.
Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.34
diff -u -r1.34 config.in
--- arch/sh/config.in 2001/04/18 04:25:15 1.34
+++ arch/sh/config.in 2001/04/19 15:50:20
@@ -7,6 +7,7 @@
define_bool CONFIG_SUPERH y
define_bool CONFIG_UID16 y
+define_bool CONFIG_RWSEM_GENERIC y
define_bool CONFIG_RWSEM_GENERIC_SPINLOCK y
define_bool CONFIG_RWSEM_XCHGADD_ALGORITHM n
Index: include/asm-sh/bitops.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/bitops.h,v
retrieving revision 1.6
diff -u -r1.6 bitops.h
--- include/asm-sh/bitops.h 2000/09/30 03:43:32 1.6
+++ include/asm-sh/bitops.h 2001/04/19 15:50:39
@@ -19,6 +19,16 @@
restore_flags(flags);
}
+static __inline__ void __set_bit(int nr, volatile void * addr)
+{
+ int mask;
+ volatile unsigned int *a = addr;
+
+ a += nr >> 5;
+ mask = 1 << (nr & 0x1f);
+ *a |= mask;
+}
+
/*
* clear_bit() doesn't provide any barrier for the compiler.
*/
@@ -35,6 +45,16 @@
save_and_cli(flags);
*a &= ~mask;
restore_flags(flags);
+}
+
+static __inline__ void __clear_bit(int nr, volatile void * addr)
+{
+ int mask;
+ volatile unsigned int *a = addr;
+
+ a += nr >> 5;
+ mask = 1 << (nr & 0x1f);
+ *a &= ~mask;
}
static __inline__ void change_bit(int nr, volatile void * addr)
Index: include/asm-sh/semaphore.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/semaphore.h,v
retrieving revision 1.2
diff -u -r1.2 semaphore.h
--- include/asm-sh/semaphore.h 2001/04/18 04:25:17 1.2
+++ include/asm-sh/semaphore.h 2001/04/19 15:50:45
@@ -84,13 +84,10 @@
asmlinkage int __down_interruptible(struct semaphore * sem);
asmlinkage int __down_trylock(struct semaphore * sem);
asmlinkage void __up(struct semaphore * sem);
-extern struct rw_semaphore *__down_read(struct rw_semaphore *sem, int carry);
-extern struct rw_semaphore *__down_write(struct rw_semaphore *sem, int carry);
-asmlinkage struct rw_semaphore *__rwsem_wake(struct rw_semaphore *sem);
extern spinlock_t semaphore_wake_lock;
-extern __inline__ void down(struct semaphore * sem)
+static inline void down(struct semaphore * sem)
{
#if WAITQUEUE_DEBUG
CHECK_MAGIC(sem->__magic);
@@ -100,7 +97,7 @@
__down(sem);
}
-extern __inline__ int down_interruptible(struct semaphore * sem)
+static inline int down_interruptible(struct semaphore * sem)
{
int ret = 0;
#if WAITQUEUE_DEBUG
@@ -112,7 +109,7 @@
return ret;
}
-extern __inline__ int down_trylock(struct semaphore * sem)
+static inline int down_trylock(struct semaphore * sem)
{
int ret = 0;
#if WAITQUEUE_DEBUG
@@ -128,7 +125,7 @@
* Note! This is subtle. We jump to wake people up only if
* the semaphore was negative (== somebody was waiting on it).
*/
-extern __inline__ void up(struct semaphore * sem)
+static inline void up(struct semaphore * sem)
{
#if WAITQUEUE_DEBUG
CHECK_MAGIC(sem->__magic);
Index: include/linux/rwsem.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/linux/rwsem.h,v
retrieving revision 1.2
diff -u -r1.2 rwsem.h
--- include/linux/rwsem.h 2001/04/18 04:25:17 1.2
+++ include/linux/rwsem.h 2001/04/19 15:51:30
@@ -42,12 +42,6 @@
#include <asm/atomic.h>
#include <linux/wait.h>
-#ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
-#include <linux/rwsem-spinlock.h> /* use a generic implementation */
-#else
-#include <asm/rwsem.h> /* use an arch-specific implementation */
-#endif
-
/* defined contention handler functions for the generic case
* - these are also used for the exchange-and-add based algorithm
*/
@@ -56,6 +50,12 @@
extern struct rw_semaphore *FASTCALL(rwsem_down_read_failed(struct rw_semaphore *sem));
extern struct rw_semaphore *FASTCALL(rwsem_down_write_failed(struct rw_semaphore *sem));
extern struct rw_semaphore *FASTCALL(rwsem_wake(struct rw_semaphore *sem));
+#endif
+
+#ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
+#include <linux/rwsem-spinlock.h> /* use a generic implementation */
+#else
+#include <asm/rwsem.h> /* use an arch-specific implementation */
#endif
#ifndef rwsemtrace
Index: lib/rwsem.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/lib/rwsem.c,v
retrieving revision 1.2
diff -u -r1.2 rwsem.c
--- lib/rwsem.c 2001/04/18 04:25:18 1.2
+++ lib/rwsem.c 2001/04/19 15:52:12
@@ -6,6 +6,7 @@
#include <linux/rwsem.h>
#include <linux/sched.h>
#include <linux/module.h>
+#include <linux/bitops.h>
/*
* wait for the read lock to be granted
-----
SUGIOKA Toshinobu
|
|
From: Greg B. <gb...@po...> - 2001-04-17 03:03:04
|
kaz Kojima wrote: > > -- > BTW, I've got hello world from the java program which is natively > compiled with gcj. Cool! Greg. -- These are my opinions not PPIs. |
|
From: kaz K. <kk...@rr...> - 2001-04-15 01:23:51
|
Hi, I'm trying to make gcj working. For this, I've ported gcc/libffi stuff to SH which is tested on little endian sh4 only. The libffi library gives a generalized calling convention of the function. If you have a chance to run ffitest with this stuff on big endian sh4 or both endian sh3, please tell me its result. The ffitest program is a test program for libffi and created when gcc is built with --enable-languages=c,c++,java configuration option. Perhaps to make a statically linked ffitest manually will be enough and easy in cross environment. If it's difficult to make ffitest, stop and forget to do this test. Please don't ask me how to do it. :-) Current libffi stuff for SH are http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-libffi-sh.diff and http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-libffi-sh-2add.tar.gz where the former is a patch to the current mainline cvs of gcc and the latter is the new files which should be put into the new libffi/src/sh directory. Thanks in advance. kaz -- BTW, I've got hello world from the java program which is natively compiled with gcj. |
|
From: Lew G. <le...@se...> - 2001-04-09 22:34:54
|
Hi Kaz,
It works! Thanks a lot for your help!
-Lew
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of kaz Kojima
> Sent: Sunday, April 08, 2001 7:58 PM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Problem with pthread mutex
>
>
> Hi,
>
> Lewis Girod <mim...@ya...> wrote:
> > Mitch Davis <md...@po...> wrote:
> >> Could you post the source for a tiny program which
> >> demonstrates the mutex problem?
> >
> > Yes.. the following program demonstrates the problem,
> > although it works fine on an x86 system. It would be
> > helpful to know if other people see this problem; it
> > might very well be something wrong with our
> > development environment..
>
> I've just found a few reverse tests in our spinlock implementation
> in GNU libc/linuxthreads. Your test program behaves same as in x86
> with applying the attached patch to glibc. Can you please test
> this patch?
> The last part of the diff to pt-machine.h is irrelevant to this
> problem and very experimental. So you can delete it.
> Thank you for your test program and sorry for my bad response.
>
> kaz
> --
> Index: pspinlock.c
> ===================================================================
> RCS file: /cvs/glibc/libc/linuxthreads/sysdeps/sh/pspinlock.c,v
> retrieving revision 1.2
> diff -u -r1.2 pspinlock.c
> --- pspinlock.c 2000/12/27 17:17:16 1.2
> +++ pspinlock.c 2001/04/09 02:24:11
> @@ -31,7 +31,7 @@
> : "=r" (val)
> : "r" (lock)
> : "memory");
> - while (val != 0);
> + while (val == 0);
>
> return 0;
> }
> @@ -47,7 +47,7 @@
> : "=r" (val)
> : "r" (lock)
> : "memory");
> - return val ? EBUSY : 0;
> + return val ? 0 : EBUSY;
> }
> weak_alias (__pthread_spin_trylock, pthread_spin_trylock)
>
> Index: pt-machine.h
> ===================================================================
> RCS file: /cvs/glibc/libc/linuxthreads/sysdeps/sh/pt-machine.h,v
> retrieving revision 1.3
> diff -u -r1.3 pt-machine.h
> --- pt-machine.h 2000/12/18 05:55:14 1.3
> +++ pt-machine.h 2001/04/09 02:24:12
> @@ -32,11 +32,11 @@
> __asm__ __volatile__(
> "tas.b @%1\n\t"
> "movt %0"
> - : "=z" (ret)
> + : "=r" (ret)
> : "r" (spinlock)
> : "memory", "cc");
>
> - return ret;
> + return (ret == 0);
> }
>
>
> @@ -44,3 +44,13 @@
> of the stack, just something somewhere in the current frame. */
> #define CURRENT_STACK_FRAME stack_pointer
> register char * stack_pointer __asm__ ("r15");
> +
> +/* Return the thread descriptor for the current thread. */
> +struct _pthread_descr_struct;
> +#define THREAD_SELF \
> + ({ struct _pthread_descr_struct *self; \
> + __asm__("stc gbr,%0" : "=r" (self)); self;})
> +
> +/* Initialize the thread-unique value. */
> +#define INIT_THREAD_SELF(descr, nr) \
> + ({ __asm__("ldc %0,gbr" : : "r" (descr));})
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-04-09 02:54:15
|
Hi,
Lewis Girod <mim...@ya...> wrote:
> Mitch Davis <md...@po...> wrote:
>> Could you post the source for a tiny program which
>> demonstrates the mutex problem?
>
> Yes.. the following program demonstrates the problem,
> although it works fine on an x86 system. It would be
> helpful to know if other people see this problem; it
> might very well be something wrong with our
> development environment..
I've just found a few reverse tests in our spinlock implementation
in GNU libc/linuxthreads. Your test program behaves same as in x86
with applying the attached patch to glibc. Can you please test
this patch?
The last part of the diff to pt-machine.h is irrelevant to this
problem and very experimental. So you can delete it.
Thank you for your test program and sorry for my bad response.
kaz
--
Index: pspinlock.c
===================================================================
RCS file: /cvs/glibc/libc/linuxthreads/sysdeps/sh/pspinlock.c,v
retrieving revision 1.2
diff -u -r1.2 pspinlock.c
--- pspinlock.c 2000/12/27 17:17:16 1.2
+++ pspinlock.c 2001/04/09 02:24:11
@@ -31,7 +31,7 @@
: "=r" (val)
: "r" (lock)
: "memory");
- while (val != 0);
+ while (val == 0);
return 0;
}
@@ -47,7 +47,7 @@
: "=r" (val)
: "r" (lock)
: "memory");
- return val ? EBUSY : 0;
+ return val ? 0 : EBUSY;
}
weak_alias (__pthread_spin_trylock, pthread_spin_trylock)
Index: pt-machine.h
===================================================================
RCS file: /cvs/glibc/libc/linuxthreads/sysdeps/sh/pt-machine.h,v
retrieving revision 1.3
diff -u -r1.3 pt-machine.h
--- pt-machine.h 2000/12/18 05:55:14 1.3
+++ pt-machine.h 2001/04/09 02:24:12
@@ -32,11 +32,11 @@
__asm__ __volatile__(
"tas.b @%1\n\t"
"movt %0"
- : "=z" (ret)
+ : "=r" (ret)
: "r" (spinlock)
: "memory", "cc");
- return ret;
+ return (ret == 0);
}
@@ -44,3 +44,13 @@
of the stack, just something somewhere in the current frame. */
#define CURRENT_STACK_FRAME stack_pointer
register char * stack_pointer __asm__ ("r15");
+
+/* Return the thread descriptor for the current thread. */
+struct _pthread_descr_struct;
+#define THREAD_SELF \
+ ({ struct _pthread_descr_struct *self; \
+ __asm__("stc gbr,%0" : "=r" (self)); self;})
+
+/* Initialize the thread-unique value. */
+#define INIT_THREAD_SELF(descr, nr) \
+ ({ __asm__("ldc %0,gbr" : : "r" (descr));})
|
|
From: Mitch D. <md...@po...> - 2001-03-30 00:26:37
|
ale wrote: > > I'm new to this community. Hi Dong-In, > I want to know what kind of board or PDA or anthing else is good for running > LinuxSH. > I read Mr. Kojima is using MS7750SE01 evaluation board. > It seems that he is runnig stable GNU/Linux on the board. > I could find only SH7750 HARP CPU board from Hitachi home page. > Are MS7750SE01 board and SH7750 HARP CPU board same? I have had experience with three SuperH boards. The first was a board with an SH3 that was designed in-house when I worked for HP. The second was the MS7750SE01 board. The third is this unit, which we have ported full Linux to: http://www.pocketpenguins.com/IDA150specs.html (It's much bigger than the picture would suggest - about A4 size, and it's rated to be dropped 4 feet onto concrete. We've done so many times. People get very very frightened when they see this demonstration!!) > How much overhead do you think to port Linux on that? We have found it is quite quick to port the core kernel to a new board, if you can get the bootloader working, and you have technical information about the board. It took us several weeks of futzing with the MS7750SE01 to get the core working. A lot of this was trying to get the Hitachi HIMON to do anything sane. > How much overhead do you think to port/write bootloader? Is there any > 'reference' bootloader code to hack? If you have a bare-bones (ie, not WinCE) machine, you can't go past "sh-ipl+g", by Niibe Yutaka. (To decode the acronym, that's "SuperH Initial Program Loader, with Gdb stub"). To convert for your board, you have to put in the BSC settings and tweak some other things, then somehow get it into your board. Then you can use this and GDB to download kernel images. Very very useful. For source, have a look at the top of Niibe-san's page: http://www.m17n.org/linux-sh/index.html When we ported Linux to the IDA, my colleague and I knew a lot more about what we were doing. It took us three days to discover how awful the built-in monitor is, to hack a workaround, and to port sh-ipl+g. Then it only took three days to get the Linux core working to the point where it was looking for a ramdisk image. One day after that, we had a user-mode program working. I think it's really incredible that it's possible to get such quick results on a new platform. There are many others who have contributed, but in particular, our success owes a lot to Niibe-san for being the driving force behind the first port to SuperH, and to Kaz Kojima, for some most extraordinary hacking of the GNU toolchain so we can turn source into object code! Thank you guys. Regarding kernel hacking, most of the time since then (many man-months) has been writing device-specific drivers, for things like PCMCIA, touch screen, LCD, battery and power management, status leds, front-panel keys, etc, etc. That's the bit that takes the time!! :-) Anyway, hope this has helped. Regards, Mitch. -- mailto:mj...@al... mailto:md...@po... |
|
From: Lewis G. <mim...@ya...> - 2001-03-27 18:12:10
|
Hi Mitch, --- Mitch Davis <md...@po...> wrote: > Hi Lew, welcome to our project. > > > I have run into a problem using pthread_mutex. > When two threads try to lock > > the same mutex, one of them blocks, but never > wakes up when the other > > releases the lock. > > We don't use the pthread library where I work, so I > can't offer you anything > from experience. There was some mention of pthreads > on the mailing list > some time back. You might want to search the > archive: > > > http://www.geocrawler.com/search/?config=3076&words=pthread&SUBMIT=Search+linuxsh-dev I looked here, but didn't find anything relevant. We did find some old patches (June 2000) having to do with pthreads which have long since been merged into glibc. > > We are using glibc-2.2.2, having followed the > instructions for building the > > cross-development tools from this mailing list. > > Just a heads-up, Stuart Menefy's instructions are > now a little long in the > tooth. They should be read in conjunction with > Masahiro Abe's new instructions. > http://linuxsh.sourceforge.net/docs/abe/20010320-gcc2.97/README_E.php3 yes.. we were actually following the new ones from Masahiro Abe... > Could you post the source for a tiny program which > demonstrates the mutex problem? Yes.. the following program demonstrates the problem, although it works fine on an x86 system. It would be helpful to know if other people see this problem; it might very well be something wrong with our development environment.. //==================== // sh4-linux-gcc -Wall test.c -o test -lpthread -static #include <pthread.h> #include <stdio.h> #include <unistd.h> pthread_mutex_t m; void * func(void *arg) { printf("func locking\n"); pthread_mutex_lock(&m); printf("func got lock\n"); sleep(1); printf("func unlocking\n"); pthread_mutex_unlock(&m); printf("func unlocked\n"); return NULL; } void * func2(void *arg) { printf("func2 locking\n"); pthread_mutex_lock(&m); printf("func2 got lock\n"); sleep(1); printf("func2 unlocking\n"); pthread_mutex_unlock(&m); printf("func2 unlocked\n"); return NULL; } int main() { pthread_t t; pthread_mutex_init(&m, NULL); printf("starting\n"); pthread_create(&t, NULL, func, NULL); func2(NULL); sleep(2); return 0; } //================= THanks for your helpful response ! -Lew > > Regards, > > Mitch. > -- > mailto:mj...@al... > mailto:md...@po... > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev > > > __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text |
|
From: Mitch D. <md...@po...> - 2001-03-27 07:08:32
|
Lew Girod wrote: > > Hi, Hi Lew, welcome to our project. > I have run into a problem using pthread_mutex. When two threads try to lock > the same mutex, one of them blocks, but never wakes up when the other > releases the lock. We don't use the pthread library where I work, so I can't offer you anything from experience. There was some mention of pthreads on the mailing list some time back. You might want to search the archive: http://www.geocrawler.com/search/?config=3076&words=pthread&SUBMIT=Search+linuxsh-dev > We are using glibc-2.2.2, having followed the instructions for building the > cross-development tools from this mailing list. Just a heads-up, Stuart Menefy's instructions are now a little long in the tooth. They should be read in conjunction with Masahiro Abe's new instructions. http://linuxsh.sourceforge.net/docs/abe/20010320-gcc2.97/README_E.php3 Could you post the source for a tiny program which demonstrates the mutex problem? Regards, Mitch. -- mailto:mj...@al... mailto:md...@po... |
25 messages has been excluded from this view by a project administrator.
