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: Robert L. <rm...@te...> - 2001-12-11 08:28:17
|
On Tue, 2001-12-11 at 01:03, M. R. Brown wrote: > Sounds good. Marcelo's tree isn't very useful for the Dreamcast without > the patches against drivers/net/8139too.c anyhow, so we may as well hold > on to these files for now, especially until they get cleaned/rewritten (all > of the files you list above are scheduled for rewrites). Maybe whoever did the 8139too work could send their code upstream to the 8139too maintainer? It just had a driver updated in 2.4.17-pre so a resync is probably needed ... but we should look into merging at least those oddball diffs so we don't have to worry about them. Robert Love |
|
From: Robert L. <rm...@te...> - 2001-12-11 08:23:54
|
On Tue, 2001-12-11 at 01:32, NIIBE Yutaka wrote: > We have change for drivers/pci/pci.ids. Three lines are added, which > should not be an issue. I don't know the chage of name > > SGS Thomson Microelectronics ===> STMicroelectronics > > is right or not. > > It would be good if we don't maintain this file in LinuxSH, if we > dont' have enough reason to do that. > > Relevant person, could you please send your request to PCI.IDS > maintainer directly, so that we don't need to maintain it? I don't think there is a PCI ID maintainer, at least not anyone who does anything important. People just toss their changes to the kernel maintainer. I can't comment on the SGS Thomson -> STM change, but maybe it was down because the full name is too long? Unknown. The rest look sane. We should pass this on. Robert Love |
|
From: Robert L. <rm...@te...> - 2001-12-11 08:20:45
|
On Tue, 2001-12-11 at 01:27, NIIBE Yutaka wrote: > For the addition of include/asm-sh/segment.h, IIRC, our conclusion > was: have it in our tree for convenience, but not send it to mainline > because the it has been obsolete for seven years or so. No, it is needed to compile because some files include "asm/segment.h" and we need it. We _don't_ need what in it but its needed to compile ... see arch-ia64, for example. Non-arch stuff includes it. Please send it. Robert Love |
|
From: Robert L. <rm...@te...> - 2001-12-11 08:19:10
|
On Tue, 2001-12-11 at 01:20, NIIBE Yutaka wrote: > > kernel/ptrace.c | 1 > > I think that this is needed. Robert, could you please check this > and talk to Marcelo or DaveM. At least with the changes in my tree, the kernel/ptrace.c works is correct. We should send it off. Robert Love |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 08:13:51
|
NIIBE Yutaka wrote: > include/asm-sh/hitachi_se.h | 2 [...] > --- linux-2.4.16/include/asm-sh/hitachi_se.h Tue Jul 3 05:56:40 2001 > +++ linux/include/asm-sh/hitachi_se.h Wed Oct 17 04:39:50 2001 > @@ -36,7 +36,7 @@ > #define PA_DIPSW0 0xb0800000 /* Dip switch 5,6 */ > #define PA_DIPSW1 0xb0800002 /* Dip switch 7,8 */ > #define PA_LED 0xb0c00000 /* LED */ > -#define PA_BCR 0xb1400000 /* FPGA */ > +#define PA_BCR 0xb1400000 /* FPGA on the MS7750SE01 */ > > #define PA_MRSHPC 0xb83fffe0 /* MR-SHPC-01 PCMCIA controller */ > #define PA_MRSHPC_MW1 0xb8400000 /* MR-SHPC-01 memory window base */ I won't send this to mainline, because it is wrong. It used to be shared among 7751se and se, but now we have the separate file hitach_7751se.h. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 07:44:47
|
NIIBE Yutaka wrote: > Well, here is a patch to 2.4 which I'm going to submit. > > Please check this. I think that all is safe to submit and included. > > To be sure, I'll re-diff against 2.4.17-pre8, if it will be applied > cleanly. I checked our tree of HEAD. I believe it's applied cleanly. I think I'll re-diff against 2.5.1-pre8 and send it to 2.5 upstream. After that, let's think about kbuild. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 07:01:20
|
Robert Love wrote: > I'll be happy to help if needed; just let me know. Could you please write-up some sort of a page of "divergence status"? You see, some part is pending, some part is just a work around, some part is ready to submit. Each developers knows the things for himself, but it would be good if the information is available for other person. -- |
|
From: Paul M. <pm...@mv...> - 2001-12-11 06:58:34
|
On Tue, Dec 11, 2001 at 03:52:04PM +0900, NIIBE Yutaka wrote: > Someone did that:=20 > drivers/char/shwdt.c This was just a typo fix on my part .. it prevented the driver in mainline from functioning properly and probably should've gone in sooner, so there shouldn't be any problems there. Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:52:11
|
Well, here is a patch to 2.4 which I'm going to submit.
Please check this. I think that all is safe to submit and included.
To be sure, I'll re-diff against 2.4.17-pre8, if it will be applied
cleanly.
--------------------------
arch/sh/config.in | 2
arch/sh/kernel/io_7751se.c | 8 +--
arch/sh/kernel/pci-7751se.c | 1
arch/sh/kernel/traps.c | 5 ++
drivers/char/shwdt.c | 7 +--
include/asm-sh/hitachi_se.h | 2
include/asm-sh/pci.h | 5 ++
include/asm-sh/stat.h | 25 +++++++++-
include/asm-sh/uaccess.h | 1
Documentation/sh/new-machine.txt | 77 +++++++++++++++++++++++++++++++++
10 files changed, 119 insertions(+), 14 deletions(-)
--------------------------
Stuart Menefy
Documentation/sh/new-machine.txt
Jeremy Siegel
arch/sh/config.in
arch/sh/kernel/io_7751se.c
arch/sh/kernel/pci-7751se.c
include/asm-sh/pci.h
Jeremy Siegel
Big endian support
include/asm-sh/stat.h
Tomoyoshi ASANO
Big endian fix
include/asm-sh/uaccess.h
Someone did that:
drivers/char/shwdt.c
arch/sh/kernel/traps.c
include/asm-sh/hitachi_se.h
--- /dev/null Tue Dec 4 19:42:15 2001
+++ linux/Documentation/sh/new-machine.txt Tue Oct 16 05:44:46 2001
@@ -0,0 +1,77 @@
+The multiple machine support relies on redirecting all functions which will
+need to be machine specific through a table of function pointers, the
+machvec. These functions fall into a number of categories:
+
+ - I/O functions to IO memory (inb etc) and PCI/main memory (readb etc).
+ - I/O remapping functions (ioremap etc)
+ - some initialisation functions
+ - a 'heartbeat' function
+ - some miscellaneous flags
+
+The tree can be built in two ways:
+ - as a fully generic build. All drivers are linked in, and all functions
+ go through the machvec
+ - as a machine specific build. In this case only the required drivers
+ will be linked in, and some macros may be redefined to not go through
+ the machvec where performance is important (in particular IO functions).
+
+There are three ways in which IO can be performed:
+ - none at all. This is really only useful for the 'unknown' machine type,
+ which us designed to run on a machine about which we know nothing, and
+ so all all IO instructions do nothing.
+ - fully custom. In this case all IO functions go to a machine specific
+ set of functions which can do what they like
+ - a generic set of functions. These will cope with most situations,
+ and rely on a single function, mv_port2addr, which is called through the
+ machine vector, and converts an IO address into a memory address, which
+ can be read from/written to directly.
+
+Thus adding a new machine involves the following steps (I will assume I am
+adding a machine called fred):
+
+ - add a new file include/asm-sh/io_fred.h which contains prototypes for
+ any machine specific IO functions prefixed with the machine name, for
+ example fred_inb. These will be needed when filling out the machine
+ vector. In addition, a section is required which defines what to do when
+ building a machine specific version. For example:
+
+ #ifdef __WANT_IO_DEF
+ #define inb fred_inb
+ ...
+ #endif
+
+ This is the minimum that is required, however there are ample
+ opportunities to optimise this. In particular, by making the prototypes
+ inline function definitions, it is possible to inline the function when
+ building machine specific versions. Note that the machine vector
+ functions will still be needed, so that a module built for a generic
+ setup can be loaded.
+
+ - add a new file arch/sh/kernel/mach_fred.c. This contains the definition
+ of the machine vector. When building the machine specific version, this
+ will be the real machine vector (via an alias), while in the generic
+ version is used to initialise the machine vector, and then freed, by
+ making it initdata. This should be defined as:
+
+ struct sh_machine_vector mv_fred __initmv = {
+ mv_name: "Fred"
+ }
+ ALIAS_MV(se)
+
+ - finally add a file arch/sh/kernel/io_fred.c, which contains
+ definitions of the machine specific io functions.
+
+A note about initialisation functions. Three initialisation functions are
+provided in the machine vector:
+ - mv_arch_init - called very early on from setup_arch
+ - mv_init_irq - called from init_IRQ, after the generic SH interrupt
+ initialisation
+ - mv_init_pci - currently not used
+
+Any other remaining functions which need to be called at start up can be
+added to the list using the __initcalls macro (or module_init if the code
+can be built as a module). Many generic drivers probe to see if the device
+they are targeting is present, however this may not always be appropriate,
+so a flag can be added to the machine vector which will be set on those
+machines which have the hardware in question, reducing the probe to a
+single conditional.
--- linux-2.4.16/arch/sh/config.in Tue Oct 16 05:36:48 2001
+++ linux/arch/sh/config.in Sat Nov 3 09:52:47 2001
@@ -189,7 +189,7 @@ if [ "$CONFIG_PCI" = "y" ]; then
if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
define_bool CONFIG_PCI_DIRECT y
fi
- define_bool CONFIG_SH_PCIDMA_NONCOHERENT n
+ bool 'Cache and PCI noncoherent' CONFIG_SH_PCIDMA_NONCOHERENT n
fi
source drivers/pci/Config.in
--- linux-2.4.16/arch/sh/kernel/io_7751se.c Sun Sep 9 04:29:09 2001
+++ linux/arch/sh/kernel/io_7751se.c Sat Nov 3 09:52:47 2001
@@ -17,7 +17,7 @@
#include <asm/hitachi_7751se.h>
#include <asm/addrspace.h>
-#include <asm/pci.h>
+#include <linux/pci.h>
#include <asm/pci-sh7751.h>
#if 0
@@ -70,7 +70,7 @@ port2adr(unsigned int port)
else
return (volatile __u16 *) (PA_SUPERIO + (port << 1));
#endif
- maybebadio(name,port);
+ maybebadio(name,(unsigned long)port);
return (volatile __u16*)port;
}
@@ -276,6 +276,7 @@ void sh7751se_writel(unsigned int b, uns
/* ISA page descriptor. */
static __u32 sh_isa_memmap[256];
+#if 0
static int
sh_isa_mmap(__u32 start, __u32 length, __u32 offset)
{
@@ -286,12 +287,11 @@ sh_isa_mmap(__u32 start, __u32 length, _
idx = start >> 12;
sh_isa_memmap[idx] = 0xb8000000 + (offset &~ 0xfff);
-#if 0
printk("sh_isa_mmap: start %x len %x offset %x (idx %x paddr %x)\n",
start, length, offset, idx, sh_isa_memmap[idx]);
-#endif
return 0;
}
+#endif
unsigned long
sh7751se_isa_port2addr(unsigned long offset)
--- linux-2.4.16/arch/sh/kernel/pci-7751se.c Sun Sep 9 04:29:09 2001
+++ linux/arch/sh/kernel/pci-7751se.c Sat Nov 3 09:52:47 2001
@@ -37,7 +37,6 @@
*/
int __init pcibios_init_platform(void)
{
- unsigned long data;
unsigned long bcr1, wcr1, wcr2, wcr3, mcr;
unsigned short bcr2;
--- linux-2.4.16/arch/sh/kernel/traps.c Sun Sep 9 04:29:09 2001
+++ linux/arch/sh/kernel/traps.c Sat Dec 1 08:03:38 2001
@@ -559,4 +559,9 @@ void dump_stack(void)
printk("%08lx\n", v);
}
}
+}
+
+void show_trace_task(struct task_struct *tsk)
+{
+ printk("Backtrace not yet implemented for SH.\n");
}
--- linux-2.4.16/drivers/char/shwdt.c Tue Oct 16 05:36:48 2001
+++ linux/drivers/char/shwdt.c Fri Nov 30 09:27:08 2001
@@ -10,7 +10,6 @@
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
-
#include <linux/config.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -177,7 +176,7 @@ static int sh_wdt_close(struct inode *in
* sh_wdt_read - Read from Device
*
* @file: file handle of device
- * @char: buffer to write to
+ * @buf: buffer to write to
* @count: length of buffer
* @ppos: offset
*
@@ -193,7 +192,7 @@ static ssize_t sh_wdt_read(struct file *
* sh_wdt_write - Write to Device
*
* @file: file handle of device
- * @char: buffer to write
+ * @buf: buffer to write
* @count: length of buffer
* @ppos: offset
*
@@ -269,7 +268,7 @@ static int sh_wdt_ioctl(struct inode *in
static int sh_wdt_notify_sys(struct notifier_block *this,
unsigned long code, void *unused)
{
- if (code == SYS_DOWN || SYS_HALT) {
+ if (code == SYS_DOWN || code == SYS_HALT) {
sh_wdt_stop();
}
--- linux-2.4.16/include/asm-sh/hitachi_se.h Tue Jul 3 05:56:40 2001
+++ linux/include/asm-sh/hitachi_se.h Wed Oct 17 04:39:50 2001
@@ -36,7 +36,7 @@
#define PA_DIPSW0 0xb0800000 /* Dip switch 5,6 */
#define PA_DIPSW1 0xb0800002 /* Dip switch 7,8 */
#define PA_LED 0xb0c00000 /* LED */
-#define PA_BCR 0xb1400000 /* FPGA */
+#define PA_BCR 0xb1400000 /* FPGA on the MS7750SE01 */
#define PA_MRSHPC 0xb83fffe0 /* MR-SHPC-01 PCMCIA controller */
#define PA_MRSHPC_MW1 0xb8400000 /* MR-SHPC-01 memory window base */
--- linux-2.4.16/include/asm-sh/pci.h Sat Oct 13 07:35:54 2001
+++ linux/include/asm-sh/pci.h Wed Oct 31 08:22:18 2001
@@ -196,6 +196,11 @@ static inline int pci_dma_supported(stru
return 1;
}
+/* Not supporting more than 32-bit PCI bus addresses now, but
+ * must satisfy references to this function. Change if needed.
+ */
+#define pci_dac_dma_supported(pci_dev, mask) (0)
+
/* Return the index of the PCI controller for device PDEV. */
#define pci_controller_num(PDEV) (0)
--- linux-2.4.16/include/asm-sh/stat.h Tue Aug 1 09:38:07 2000
+++ linux/include/asm-sh/stat.h Sat Nov 3 09:52:47 2001
@@ -42,8 +42,16 @@ struct stat {
* insane amounts of padding around dev_t's.
*/
struct stat64 {
+#if defined(__BIG_ENDIAN__)
+ unsigned char __pad0b[6];
unsigned short st_dev;
- unsigned char __pad0[10];
+#elif defined(__LITTLE_ENDIAN__)
+ unsigned short st_dev;
+ unsigned char __pad0b[6];
+#else
+#error Must know endian to build stat64 structure!
+#endif
+ unsigned char __pad0[4];
unsigned long st_ino;
unsigned int st_mode;
@@ -52,14 +60,25 @@ struct stat64 {
unsigned long st_uid;
unsigned long st_gid;
+#if defined(__BIG_ENDIAN__)
+ unsigned char __pad3b[6];
+ unsigned short st_rdev;
+#else /* Must be little */
unsigned short st_rdev;
- unsigned char __pad3[10];
+ unsigned char __pad3b[6];
+#endif
+ unsigned char __pad3[4];
long long st_size;
unsigned long st_blksize;
+#if defined(__BIG_ENDIAN__)
+ unsigned long __pad4; /* Future possible st_blocks hi bits */
+ unsigned long st_blocks; /* Number 512-byte blocks allocated. */
+#else /* Must be little */
unsigned long st_blocks; /* Number 512-byte blocks allocated. */
- unsigned long __pad4; /* future possible st_blocks high bits */
+ unsigned long __pad4; /* Future possible st_blocks hi bits */
+#endif
unsigned long st_atime;
unsigned long __pad5;
--- linux-2.4.16/include/asm-sh/uaccess.h Tue Oct 16 05:36:48 2001
+++ linux/include/asm-sh/uaccess.h Sat Nov 3 09:52:47 2001
@@ -216,6 +216,7 @@ __asm__ __volatile__( \
: "r" (val), "m" (__m(addr)), "i" (-EFAULT) \
: "memory"); })
#else
+#define __put_user_u64(val,addr,retval) \
({ \
__asm__ __volatile__( \
"1:\n\t" \
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:39:05
|
Changes for drivers/net/Config.in There're two changes. One is Dreamcast change, another is CS89x0 support change. Relevant persion, please send the change by yourself to maintainer. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:36:08
|
arch/sh/kernel/pci-sh7751.c It seems Martin Mares' e-mail address has been changed, and it was applied to mainline. We should have change our file. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:32:55
|
We have change for drivers/pci/pci.ids. Three lines are added, which
should not be an issue. I don't know the chage of name
SGS Thomson Microelectronics ===> STMicroelectronics
is right or not.
It would be good if we don't maintain this file in LinuxSH, if we
dont' have enough reason to do that.
Relevant person, could you please send your request to PCI.IDS
maintainer directly, so that we don't need to maintain it?
@@ -963,11 +963,12 @@
1000 QuickStep 1000
3000 QuickStep 3000
1049 Fountain Technologies, Inc.
-104a SGS Thomson Microelectronics
+104a STMicroelectronics
0008 STG 2000X
0009 STG 1764X
1746 STG 1764X
3520 MPEG-II decoder card
+ 2774 STE10/100A
104b BusLogic
0140 BT-946C (old) [multimaster 01]
1040 BT-946C (BA80C30) [MultiMaster 10]
@@ -2640,6 +2641,7 @@
11aa Actel
11ab Galileo Technology Ltd.
0146 GT-64010
+ 4146 GT-64111
4801 GT-48001
f003 GT-64010 Primary Image Piranha Image Generator
11ac Canon Information Systems Research Aust.
@@ -2794,6 +2796,7 @@
11d9 TEC Corporation
11da Novell
11db Sega Enterprises Ltd
+ 1234 Broadband Adapter
11dc Questra Corporation
11dd Crosfield Electronics Limited
11de Zoran Corporation
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:27:38
|
NIIBE Yutaka wrote:
> Besides, following files are meaningless without those files.
^^^^^ changes
> Makefile
> driver/cdrom/Config.in
> driver/cdrom/Makefile
> driver/char/Makefile
> driver/char/joystic/Config.in
> driver/char/joystic/Makefile
> include/linux/input.h
and
init/main.c
For the addition of include/asm-sh/segment.h, IIRC, our conclusion
was: have it in our tree for convenience, but not send it to mainline
because the it has been obsolete for seven years or so.
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:20:24
|
* MTD driver > drivers/mtd/maps/solutionengine.c | 47 +- > drivers/mtd/mtdpart.c | 11 > drivers/mtd/maps/Config.in | 11 > include/linux/mtd/partitions.h | 7 Since these files are maintained by David Woodhouse, I don't send them to mainline. * 8139too driver > Documentation/Configure.help | 6 > drivers/net/8139too.c | 25 + This is changes for 8139too, I and Takeshi sent them to 8139too maintainer two or three times, but it has not yet included. I don't know the status of this change. Takeshi? * MEMORY management, cache management > Documentation/cachetlb.txt | 2 > mm/memory.c | 2 I've changed the document slightly to follow current implementation. I'm thinking new API for the chage of mm/memory.c. Let's leave them. > drivers/block/rd.c | 1 > include/linux/highmem.h | 1 These are paranoia thing which I put once. I think that we should remove them when we will find it's safe to remove. Don't send them to mainline. > kernel/ptrace.c | 1 I think that this is needed. Robert, could you please check this and talk to Marcelo or DaveM. > include/asm-sh/mmzone.h This version is known not to work. I think that Takeshi has newer version. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:04:20
|
NIIBE Yutaka wrote:
> Following files:
> drivers/cdrom/gdrom.c
> drivers/char/dc_keyb.c
> drivers/char/joystick/maplecontrol.c
> drivers/char/maple_keyb.c
> drivers/char/maplemouse.c
> drivers/maple/Config.in
> drivers/maple/Makefile
> drivers/maple/maple.c
> include/linux/maple.h
Besides, following files are meaningless without those files.
Makefile
driver/cdrom/Config.in
driver/cdrom/Makefile
driver/char/Makefile
driver/char/joystic/Config.in
driver/char/joystic/Makefile
include/linux/input.h
--
|
|
From: M. R. B. <mr...@0x...> - 2001-12-11 06:03:49
|
* NIIBE Yutaka <gn...@m1...> on Tue, Dec 11, 2001: >=20 > Following files: > drivers/cdrom/gdrom.c > drivers/char/dc_keyb.c > drivers/char/joystick/maplecontrol.c > drivers/char/maple_keyb.c > drivers/char/maplemouse.c > drivers/maple/Config.in > drivers/maple/Makefile > drivers/maple/maple.c > include/linux/maple.h >=20 > Without maple implementation, maplecontrol.c, maple_keyb.c and > maplemouse.c have nonsence. So, we leave the files above in our tree,=20 > not sending to mainline, OK? > =20 Sounds good. Marcelo's tree isn't very useful for the Dreamcast without the patches against drivers/net/8139too.c anyhow, so we may as well hold on to these files for now, especially until they get cleaned/rewritten (all of the files you list above are scheduled for rewrites). > Here is diffstats output for the divergence between 2.4.16 and our > 2.4 based tree (with no files above). >=20 > -------------------------- > arch/sh/kernel/sys_sh.c-1.7 | 236 ++++++++++ I wanted to ask about this file earlier. What is it here for? It looks like it's begging to be removed :). > arch/sh/kernel/entry.S | 2=20 > arch/sh/kernel/cf-enabler.c | 2=20 > arch/sh/config.in | 2=20 > arch/sh/Makefile | 2=20 > Documentation/cachetlb.txt | 2=20 > kernel/ptrace.c | 1=20 > include/linux/highmem.h | 1=20 > drivers/cdrom/Makefile | 1=20 > drivers/cdrom/Config.in | 1=20 > drivers/block/rd.c | 1=20 > arch/sh/kernel/pci-7751se.c | 1=20 I assume all the 2's and 1's are CVS Id tags? M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:02:14
|
NIIBE Yutaka wrote: > arch/sh/kernel/sys_sh.c-1.7 | 236 ++++++++++ This is a garbage, I put the other day. I remove this file. These 59 files are noly $Id$ difference, so leave them. > arch/sh/Makefile | 2 > arch/sh/kernel/cf-enabler.c | 2 > arch/sh/kernel/entry.S | 2 > arch/sh/kernel/fpu.c | 2 > arch/sh/kernel/hd64465_gpio.c | 2 > arch/sh/kernel/head.S | 2 > arch/sh/kernel/io_dc.c | 2 > arch/sh/kernel/io_generic.c | 2 > arch/sh/kernel/io_hd64461.c | 2 > arch/sh/kernel/io_hd64465.c | 2 > arch/sh/kernel/io_se.c | 2 > arch/sh/kernel/irq.c | 2 > arch/sh/kernel/irq_imask.c | 2 > arch/sh/kernel/irq_ipr.c | 2 > arch/sh/kernel/mach_dc.c | 2 > arch/sh/kernel/pci-dc.c | 2 > arch/sh/kernel/pcibios.c | 2 > arch/sh/kernel/process.c | 2 > arch/sh/kernel/ptrace.c | 2 > arch/sh/kernel/setup.c | 2 > arch/sh/kernel/setup_cqreek.c | 2 > arch/sh/kernel/setup_hd64461.c | 2 > arch/sh/kernel/setup_hd64465.c | 2 > arch/sh/kernel/setup_se.c | 2 > arch/sh/kernel/sh_bios.c | 2 > arch/sh/kernel/signal.c | 2 > arch/sh/kernel/time.c | 2 > arch/sh/lib/checksum.S | 2 > arch/sh/lib/memchr.S | 2 > arch/sh/lib/memcpy.S | 2 > arch/sh/lib/memmove.S | 2 > arch/sh/lib/memset.S | 2 > arch/sh/lib/strlen.S | 2 > arch/sh/mm/__clear_user_page-sh4.S | 2 > arch/sh/mm/__copy_user_page-sh4.S | 2 > arch/sh/mm/cache-sh3.c | 2 > arch/sh/mm/cache-sh4.c | 2 > arch/sh/mm/clear_page.S | 2 > arch/sh/mm/copy_page.S | 2 > arch/sh/mm/extable.c | 2 > arch/sh/mm/fault.c | 2 > arch/sh/mm/init.c | 2 > arch/sh/mm/ioremap.c | 2 > arch/sh/vmlinux.lds.S | 2 > drivers/char/hp600_keyb.c | 2 > drivers/char/sh-sci.c | 2 > drivers/char/sh-sci.h | 2 > drivers/pcmcia/hd64465_ss.c | 2 > drivers/video/hitfb.c | 2 > include/asm-sh/cache.h | 2 > include/asm-sh/hd64461.h | 2 > include/asm-sh/hd64465.h | 2 > include/asm-sh/hd64465_gpio.h | 2 > include/asm-sh/hitachi_se.h | 2 > include/asm-sh/io_dc.h | 2 > include/asm-sh/ioctl.h | 2 > include/asm-sh/keyboard.h | 2 > include/asm-sh/linux_logo.h | 2 > include/asm-sh/namei.h | 2 -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 05:42:56
|
Paul Mundt wrote: > Things like pvr2fb and the AICA RTC code are already in mainline. Maple is > currently undergoing a rewrite, and hopefully we'll be able to replace the > current implementation with that shortly. The current maple implementation > should never leave this tree. > > As far as GD-ROM support goes.. that's pending a proper implementation as > well, since the current driver isn't anything other then a hack of a port o= > f a > hack of a driver from NetBSD.. > > Are there any other drivers you were referring to that I missed? Following files: drivers/cdrom/gdrom.c drivers/char/dc_keyb.c drivers/char/joystick/maplecontrol.c drivers/char/maple_keyb.c drivers/char/maplemouse.c drivers/maple/Config.in drivers/maple/Makefile drivers/maple/maple.c include/linux/maple.h Without maple implementation, maplecontrol.c, maple_keyb.c and maplemouse.c have nonsence. So, we leave the files above in our tree, not sending to mainline, OK? Here is diffstats output for the divergence between 2.4.16 and our 2.4 based tree (with no files above). -------------------------- arch/sh/kernel/sys_sh.c-1.7 | 236 ++++++++++ Documentation/sh/new-machine.txt | 77 +++ include/asm-sh/mmzone.h | 61 ++ drivers/mtd/maps/solutionengine.c | 47 +- include/asm-sh/stat.h | 25 - drivers/net/8139too.c | 25 + drivers/mtd/mtdpart.c | 11 drivers/mtd/maps/Config.in | 11 arch/sh/kernel/io_7751se.c | 8 include/linux/mtd/partitions.h | 7 drivers/pci/pci.ids | 7 drivers/char/shwdt.c | 7 arch/sh/kernel/traps.c | 7 include/asm-sh/segment.h | 6 Documentation/Configure.help | 6 include/asm-sh/pci.h | 5 drivers/char/joystick/Config.in | 5 drivers/char/Makefile | 5 init/main.c | 3 include/linux/input.h | 3 include/asm-sh/uaccess.h | 3 drivers/net/Config.in | 3 drivers/Makefile | 3 mm/memory.c | 2 include/asm-sh/namei.h | 2 include/asm-sh/linux_logo.h | 2 include/asm-sh/keyboard.h | 2 include/asm-sh/ioctl.h | 2 include/asm-sh/io_dc.h | 2 include/asm-sh/hitachi_se.h | 2 include/asm-sh/hd64465_gpio.h | 2 include/asm-sh/hd64465.h | 2 include/asm-sh/hd64461.h | 2 include/asm-sh/cache.h | 2 drivers/video/hitfb.c | 2 drivers/pcmcia/hd64465_ss.c | 2 drivers/char/sh-sci.h | 2 drivers/char/sh-sci.c | 2 drivers/char/scan_keyb.c | 2 drivers/char/joystick/Makefile | 2 drivers/char/hp600_keyb.c | 2 arch/sh/vmlinux.lds.S | 2 arch/sh/mm/ioremap.c | 2 arch/sh/mm/init.c | 2 arch/sh/mm/fault.c | 2 arch/sh/mm/extable.c | 2 arch/sh/mm/copy_page.S | 2 arch/sh/mm/clear_page.S | 2 arch/sh/mm/cache-sh4.c | 2 arch/sh/mm/cache-sh3.c | 2 arch/sh/mm/__copy_user_page-sh4.S | 2 arch/sh/mm/__clear_user_page-sh4.S | 2 arch/sh/lib/strlen.S | 2 arch/sh/lib/memset.S | 2 arch/sh/lib/memmove.S | 2 arch/sh/lib/memcpy.S | 2 arch/sh/lib/memchr.S | 2 arch/sh/lib/checksum.S | 2 arch/sh/kernel/time.c | 2 arch/sh/kernel/signal.c | 2 arch/sh/kernel/sh_bios.c | 2 arch/sh/kernel/setup_se.c | 2 arch/sh/kernel/setup_hd64465.c | 2 arch/sh/kernel/setup_hd64461.c | 2 arch/sh/kernel/setup_cqreek.c | 2 arch/sh/kernel/setup.c | 2 arch/sh/kernel/ptrace.c | 2 arch/sh/kernel/process.c | 2 arch/sh/kernel/pcibios.c | 2 arch/sh/kernel/pci-sh7751.c | 2 arch/sh/kernel/pci-dc.c | 2 arch/sh/kernel/mach_dc.c | 2 arch/sh/kernel/irq_ipr.c | 2 arch/sh/kernel/irq_imask.c | 2 arch/sh/kernel/irq.c | 2 arch/sh/kernel/io_se.c | 2 arch/sh/kernel/io_hd64465.c | 2 arch/sh/kernel/io_hd64461.c | 2 arch/sh/kernel/io_generic.c | 2 arch/sh/kernel/io_dc.c | 2 arch/sh/kernel/head.S | 2 arch/sh/kernel/hd64465_gpio.c | 2 arch/sh/kernel/fpu.c | 2 arch/sh/kernel/entry.S | 2 arch/sh/kernel/cf-enabler.c | 2 arch/sh/config.in | 2 arch/sh/Makefile | 2 Documentation/cachetlb.txt | 2 kernel/ptrace.c | 1 include/linux/highmem.h | 1 drivers/cdrom/Makefile | 1 drivers/cdrom/Config.in | 1 drivers/block/rd.c | 1 arch/sh/kernel/pci-7751se.c | 1 Makefile | 1 -- |
|
From: Robby S. <pin...@ms...> - 2001-12-10 07:00:06
|
I looked at the linuxsh website and couldn't find any information on linuxsh for the jornada 525. Does anyone have any information that would be helpful? |
|
From: Paul M. <pm...@mv...> - 2001-12-10 05:36:35
|
On Mon, Dec 10, 2001 at 09:35:16AM +0900, NIIBE Yutaka wrote: > I have a question to M.R. How do you think about the drivers for DC? > Is it ready for inclusion of mainline? I don't know 2.4 opens for new > drivers or not, but at least it's worth sending those to 2.5.=20 Things like pvr2fb and the AICA RTC code are already in mainline. Maple is currently undergoing a rewrite, and hopefully we'll be able to replace the current implementation with that shortly. The current maple implementation should never leave this tree. As far as GD-ROM support goes.. that's pending a proper implementation as well, since the current driver isn't anything other then a hack of a port o= f a hack of a driver from NetBSD.. Are there any other drivers you were referring to that I missed? Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-10 04:29:06
|
Well, I flush things I've done those months. The issue is bootstrapping GNU Toolchain for SuperH. Once I've done it at September under ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010919/ and this is the update. It only includes GCC, Binutils and Glibc. It will be available at: ftp://ftp.m17n.org/pub/linux-sh/testing/debian-011210/ (now I'm rsync-ing to this...) Please note that this includes working directories along with sources and results. I hope that we can share this procedure and will formalize somewhat to have toolchain of better quality. -- |
|
From: Robert L. <rm...@te...> - 2001-12-10 04:07:19
|
On Sun, 2001-12-09 at 19:35, NIIBE Yutaka wrote: > For mm/memory.c, I think this is good. Official tree works anyway, though > runs with bad performance. True. > No, I don't. While I disagreed the handling of mm/memory.c, but I agree > that we should think and act for the synch to mainline. Good. > > Please consider the suggestions above. Let's synchronize things as much > > as possible. > > Yes. > > My plan for this week is like following: > (1) Check the patches I hold, and check in to the repository: > big-endian bug for users.h > discontigous memory handling > configuration issues (i.e., config.in and config.help) > (2) Check the difference between 2.4 and repository > and send it to upstream. > (3) Check the difference between 2.5 and repository > and send it to upstream. > (4) Gather opinion and features for 2.5 > > For (2) or (3) I think that I will submit the difference to this list > before sending to upstream, so that people can see what's going on > more clearly. Please note that I don't send all the difference, and > sometimes some parts may not be included by the upstream maintainer. Excellent! I'll be happy to help if needed; just let me know. > For (4), keeping up to kbuild is major one. > > I have a question to M.R. How do you think about the drivers for DC? > Is it ready for inclusion of mainline? I don't know 2.4 opens for new > drivers or not, but at least it's worth sending those to 2.5. He is not me, but the DC drivers seem very solid. 2.4 _is) taking new drivers so you can send those off. We actually have a better chance of getting the 2.4 merge synced ... 2.5 may take longer. Robert Love |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-10 00:35:20
|
Robert Love wrote: > However, a couple ideas: we need to realize that the above is a > 2.5-thing, and could take a _very_ long time to design, implement, test, > and finally have merged. In the mean time, SH will grow further and > further out of sync. Agreed. > (a) Don't send anything for mm/memory.c -- in our tree, keep it if'ed > out. In the official tree, keep it as-is. This means we keep the > reminder, we don't have the needless code, and the official tree doesn't > see anything yet. For mm/memory.c, I think this is good. Official tree works anyway, though runs with bad performance. > (b) Implement the API for just that one file. Something like: Please look at Documentation/cachetlb.txt, we should add new routine here. > I understand. What we disagree about is that we can't work around the > issue for the time-being. No, I don't. While I disagreed the handling of mm/memory.c, but I agree that we should think and act for the synch to mainline. > Please consider the suggestions above. Let's synchronize things as much > as possible. Yes. My plan for this week is like following: (1) Check the patches I hold, and check in to the repository: big-endian bug for users.h discontigous memory handling configuration issues (i.e., config.in and config.help) (2) Check the difference between 2.4 and repository and send it to upstream. (3) Check the difference between 2.5 and repository and send it to upstream. (4) Gather opinion and features for 2.5 For (2) or (3) I think that I will submit the difference to this list before sending to upstream, so that people can see what's going on more clearly. Please note that I don't send all the difference, and sometimes some parts may not be included by the upstream maintainer. For (4), keeping up to kbuild is major one. I have a question to M.R. How do you think about the drivers for DC? Is it ready for inclusion of mainline? I don't know 2.4 opens for new drivers or not, but at least it's worth sending those to 2.5. -- |
|
From: Adrian M. <ad...@mc...> - 2001-12-09 23:00:33
|
Some good news... My OSS sound driver for Dreamcast linux has at last got to first base - it will now respond to a cat somefile > /dev/dsp by outputting static. http://www.mcmen.demon.co.uk/linuxdc/aica The code will shortly go on the web site - but it's still a mess and shouldn't be considered anything other than a curiousity at the moment. For those who are interested, I have to say that most credit must go to Dan Potter and his KOS code (and, I suppose, to Marcus Comstedt to whom Dan P. gives credit). At the moment the "OSS driver" loads in the KOS soundstream code as a static array and then uses Dan's IPC mechanism to communicate. There will need to be some hacking of Dan's code to make it comply to the OSS PI eventually - but that bit is all his code at the moment. None of the ioctls are written and the architecture is all wrong now (it turns the SPU on and off between writes) - but at leasr I know it can work. Feel a little proud for me - 7 months ago I had never written a line of C in my life (though i admit I had written many thousands of lines of C++, java and perl but they were all for the enemy's operating system). Adrian |
|
From: kaz K. <kk...@rr...> - 2001-12-07 23:49:22
|
Vladimir Doukhanine <vdo...@wa...> wrote: >> Vladimir Doukhanine <vdo...@wa...> wrote: >>> If I copy data from one place to another after each megabyte (delta >>> between src and dst) >>> there is some kind of "black hole" 32 bytes long in which processor >>> works 15 times >>> slower. >> >> Which version of kernel are you testing? > > 2.4.5 2.4.5 kernel has SH-4 cache and other problems. Can you please get and test newer kernel? kaz |
25 messages has been excluded from this view by a project administrator.
