Re: Git

Re: Git

[sjhill]

> As a heads up, I've started playing with GIT as the replacement of CVS.
> For information on the status of that conversion please see
> 
I assume the reason for choosing GIT was because the main line kernel
uses the same source management tool. No chance of using Subversion I
guess.

-Steve

Git

[Ralf Baechle]

As a heads up, I've started playing with GIT as the replacement of CVS.
For information on the status of that conversion please see

  http://www.linux-mips.org/wiki/Git

The converted repositories are accessible at via rsync at

  rsync://ftp.linux-mips.org/git

And there gitweb, a web frontend to replace cvsweb available at:

  http://www.linux-mips.org/wiki/git

Browse around, let me know if you find anything that doesn't work as you
want it to.

For those with write permission into CVS, for now continue using CVS
as always.  For now the conversion is still only for testing and
figuring out all the kinks.

  Ralf

Re: Git

[Ralf Baechle]

On Tue, Sep 13, 2005 at 07:15:03AM -0500, sjhill@realitydiluted.com wrote:

> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> > 
> I assume the reason for choosing GIT was because the main line kernel
> uses the same source management tool. No chance of using Subversion I
> guess.

Subversion maybe better but not good enough to justify the pain of
switching, I think.

Btw, can subversion do a checkout in 10s?

  Ralf

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Tue, 2005-09-13 13:45:44 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> As a heads up, I've started playing with GIT as the replacement of CVS.
> For information on the status of that conversion please see
> 
>   http://www.linux-mips.org/wiki/Git

Which docs did you use to get yourself started? I'm also on the way
getting familiar with GIT, doing my very first steps. It would be nice
if we'd present what we know in Oldenburg (I already offered to do so,
Joey planed it for Saturday).

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Tue, 2005-09-13 07:15:03 -0500, sjhill@realitydiluted.com <sjhill@realitydiluted.com> wrote:
> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> > 
> I assume the reason for choosing GIT was because the main line kernel
> uses the same source management tool. No chance of using Subversion I
> guess.

Is SVN already distributed? In the past, the non-distributed reality
of CVS is what bought me a lot of trouble. And SVN isn't really
designed for distribution, is it?

I for one see SVN as a CVS rewrite with some design flaws fixed, but
it's for sure not what I actually want to use.

So I'm currently learning to use GIT. It's a bit strange when you
start using it (because usually I interact with git itself as well as
with eg. cogito), but I slowly get used to it :-)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Thiemo Seufer]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Jan-Benedict Glaw wrote:
> On Tue, 2005-09-13 07:15:03 -0500, sjhill@realitydiluted.com <sjhill@realitydiluted.com> wrote:
> > > As a heads up, I've started playing with GIT as the replacement of CVS.
> > > For information on the status of that conversion please see
> > > 
> > I assume the reason for choosing GIT was because the main line kernel
> > uses the same source management tool. No chance of using Subversion I
> > guess.
> 
> Is SVN already distributed? In the past, the non-distributed reality
> of CVS is what bought me a lot of trouble. And SVN isn't really
> designed for distribution, is it?

SVN isn't, but SVK (which uses regular SVN) is.

> I for one see SVN as a CVS rewrite with some design flaws fixed, but
> it's for sure not what I actually want to use.
> 
> So I'm currently learning to use GIT. It's a bit strange when you
> start using it (because usually I interact with git itself as well as
> with eg. cogito), but I slowly get used to it :-)

I think for kernel development git is the way to go.


Thiemo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Ralf Baechle]

On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:

> On Tue, 2005-09-13 13:45:44 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > As a heads up, I've started playing with GIT as the replacement of CVS.
> > For information on the status of that conversion please see
> > 
> >   http://www.linux-mips.org/wiki/Git
> 
> Which docs did you use to get yourself started?

The tutorial.txt that comes with git is ok I guess; cvs-migration.txt is
helpful for CVS [1] experienced users.  And of course, my favorite search
engine.

> I'm also on the way
> getting familiar with GIT, doing my very first steps. It would be nice
> if we'd present what we know in Oldenburg (I already offered to do so,
> Joey planed it for Saturday).

Sounds like a plan.  And maybe present some of the other alternatives
to CVS as well?

  Ralf

[1] http://en.wikipedia.org/wiki/Cyclic_Vomiting_Syndrome

Re: Git

[Wolfgang Denk]

In message <20050913133126.GO23161@lug-owl.de> you wrote:
> 
> Which docs did you use to get yourself started? I'm also on the way
> getting familiar with GIT, doing my very first steps. It would be nice
> if we'd present what we know in Oldenburg (I already offered to do so,
> Joey planed it for Saturday).

I collected a bit of information, like postings from the git  mailing
list I found especially informative, at
http://source.denx.net/en/Documents/GitDocs

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is clear that the individual who persecutes a  man,  his  brother,
because he is not of the same opinion, is a monster.       - Voltaire

Re: Git

[Dominic Sweetman]

Since I didn't understand it, I did some digging around.  I recorded
what I figured out so far (which may, of course, be deeply wrong) in a
wiki page

  http://www.linux-mips.org/wiki/WhatIsGit

Unless and until someone else comes up with a link to something better
like this - which I appreciate quite likely exists somewhere - perhaps
this will get amended by others and become useful.

--
Dominic Sweetman

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > I'm also on the way
> > getting familiar with GIT, doing my very first steps. It would be nice
> > if we'd present what we know in Oldenburg (I already offered to do so,
> > Joey planed it for Saturday).
> 
> Sounds like a plan.  And maybe present some of the other alternatives
> to CVS as well?

I'm not sure if it's worth it. Linus decided against all other SCMs. I
did use (for small test projects) monotone, darcs and arch. (I think
all other alternatives aren't.)

monotone
	Is quite nice'n'easy to use for CVS users, you'll have quite a
	fast start. The network sync protocol can be a bit lengthy at
	a time, but it works. It's acceptable in speed, but not
	exactly "fast". Written in C, code can easily be read and
	hacked.

darcs
	Is easy to use, too, and quite some helpful. Network
	operations are a bit slower than those of monotone, but the
	real point is that it's merging algorithms are awfully slow.
	Also, it's written in Haskell (and getting a working compiler
	isn't exactly trivial), so the code is hard to read (for a C
	person), mostly because Haskell's concept are so different
	(it's a function programming language, after all.)

arch
	Arch can do almost everything; it's network sync protocol is
	quite fast (can use several transports and will make use of
	caches). However, it's not exactly easy to use because of it's
	thousands of commands and it's project name conventions are,
	um, ugly. It has very good merging capabilities, but it's
	heavy use of local caches forces you to have loads of free HDD
	space.

CVS
	Um, we all know the problems, don't we?

SVN
	Not distributed, easy to use.  Though there's a different
	frontend with distribution capabilities. Personally, SVN feels
	like CVS with it's major conceptual problems fixed.

More SCM questions?

So my famous last words are:  I don't think it's worth really
presenting all the other alternatives (except probably reading down
the above text).

To get fixes/port updates/subsystem updates upstream to Linus, GIT is
the way[tm] to go, so we'd try to get familiar with it.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Geert Uytterhoeven]

On Wed, 14 Sep 2005, Jan-Benedict Glaw wrote:
> On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > > I'm also on the way
> > > getting familiar with GIT, doing my very first steps. It would be nice
> > > if we'd present what we know in Oldenburg (I already offered to do so,
> > > Joey planed it for Saturday).
> > 
> > Sounds like a plan.  And maybe present some of the other alternatives
> > to CVS as well?
> 
> I'm not sure if it's worth it. Linus decided against all other SCMs. I
> did use (for small test projects) monotone, darcs and arch. (I think
> all other alternatives aren't.)

Have you tried mercurial?

> To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> the way[tm] to go, so we'd try to get familiar with it.

Still using plain patches and email...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

On Wed, 2005-09-14 13:23:22 +0200, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, 14 Sep 2005, Jan-Benedict Glaw wrote:
> > On Tue, 2005-09-13 16:20:38 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> > > On Tue, Sep 13, 2005 at 03:31:26PM +0200, Jan-Benedict Glaw wrote:
> > > > I'm also on the way
> > > > getting familiar with GIT, doing my very first steps. It would be nice
> > > > if we'd present what we know in Oldenburg (I already offered to do so,
> > > > Joey planed it for Saturday).
> > > 
> > > Sounds like a plan.  And maybe present some of the other alternatives
> > > to CVS as well?
> > 
> > I'm not sure if it's worth it. Linus decided against all other SCMs. I
> > did use (for small test projects) monotone, darcs and arch. (I think
> > all other alternatives aren't.)
> 
> Have you tried mercurial?

Nope. I've only used it's web frontend on http://www.kernel.org/hg/ .

Mercurial's author claims that it scales even better than git, esp. on
its network transfer. However, I'm not aware how it scales there right
now, since git got its "packs" implemented.

> > To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> > the way[tm] to go, so we'd try to get familiar with it.
> 
> Still using plain patches and email...

...which is a nice and actually working scheme, too. At least, it
doesn't require to learn working with a new SCM :-P  Though I think
it's a good idea.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Ralf Baechle]

On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote:

> To:	linux-mips@linux-mips.org

If you actually expect finite time answer, don't delete the cc list ...

> monotone
> 	Is quite nice'n'easy to use for CVS users, you'll have quite a
> 	fast start. The network sync protocol can be a bit lengthy at
> 	a time, but it works. It's acceptable in speed, but not
> 	exactly "fast". Written in C, code can easily be read and
> 	hacked.

Git has taken some ideas from Monotone.

> darcs
> 	Is easy to use, too, and quite some helpful. Network
> 	operations are a bit slower than those of monotone, but the
> 	real point is that it's merging algorithms are awfully slow.
> 	Also, it's written in Haskell (and getting a working compiler
> 	isn't exactly trivial), so the code is hard to read (for a C
> 	person), mostly because Haskell's concept are so different
> 	(it's a function programming language, after all.)

In my tests at the beginning of the year darcs's performance was
undescribably low.  The speedup factor needed to make it useful for any
large project probably cannot be described in a floating point number.

> arch
> 	Arch can do almost everything; it's network sync protocol is
> 	quite fast (can use several transports and will make use of
> 	caches). However, it's not exactly easy to use because of it's
> 	thousands of commands and it's project name conventions are,
> 	um, ugly. It has very good merging capabilities, but it's
> 	heavy use of local caches forces you to have loads of free HDD
> 	space.

Git is a huge diskspace consumer also unless repositories are converted.
For example, the Linux kernel repository from CVS did inflate itself to
over 4GB and over 340,000 files.  After packing I got that down to like
170MB.  Not bad compared to the some 770MB of RCS files it's using
currently and < 11s checkout from git can't be wrong either ;-)

> SVN
> 	Not distributed, easy to use.  Though there's a different
> 	frontend with distribution capabilities. Personally, SVN feels
> 	like CVS with it's major conceptual problems fixed.

And plenty of reports about database corruption that are not terribly old
so I'd feel uneasy to keep the crown jewels there.

> To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> the way[tm] to go, so we'd try to get familiar with it.

The other accepted currency of the trade are still simple patches, see
http://www.linux-mips.org/wiki/The_perfect_patch.

  Ralf

[PATCH] Ethernet for TX4927(37) platform

[Vladimir A. Barinov]

[-- Attachment #1: Type: text/plain, Size: 128 bytes --]

Hello All!

This as a patch to add ethernet support for TX4927 platform.
Does it makes sence to push it in?

Regards,
Vladimir


[-- Attachment #2: pro_mips_tx4927_ethernet.patch --]
[-- Type: text/plain, Size: 1105 bytes --]

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
        Ethernet support for TX4927/37 platform in 2.6.
                                                                                                                                                             
Index: linux-2.6.10/drivers/net/ne.c
===================================================================
--- linux-2.6.10.orig/drivers/net/ne.c
+++ linux-2.6.10/drivers/net/ne.c
@@ -54,7 +54,9 @@ static const char version2[] =
 #include <asm/system.h>
 #include <asm/io.h>
 
-#if defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938)
+#if defined(CONFIG_TOSHIBA_RBTX4927)
+#include <asm/tx4927/toshiba_rbtx4927.h>
+#elif defined(CONFIG_TOSHIBA_RBTX4938)
 #include <asm/tx4938/rbtx4938.h>
 #endif
 
@@ -237,6 +239,10 @@ struct net_device * __init ne_probe(int 
 	dev->base_addr = 0x07f20280;
 	dev->irq = RBTX4938_RTL_8019_IRQ;
 #endif
+#ifdef CONFIG_TOSHIBA_RBTX4927
+	dev->base_addr = RBTX4927_RTL_8019_BASE;
+	dev->irq = RBTX4927_RTL_8019_IRQ;
+#endif
 	err = do_ne_probe(dev);
 	if (err)
 		goto out;

Re: Git

[Thiemo Seufer]

Ralf Baechle wrote:
[snip]
> > SVN
> > 	Not distributed, easy to use.  Though there's a different
> > 	frontend with distribution capabilities. Personally, SVN feels
> > 	like CVS with it's major conceptual problems fixed.
> 
> And plenty of reports about database corruption that are not terribly old
> so I'd feel uneasy to keep the crown jewels there.

This was related to the underlying berkeleydb, the switch to fsfs
fixed that. (SVN is used for several larger Debian projects like
its Xfree86/XOrg tree, it holds up quite well there.)

Btw, there's also SVK which implements a distributed system on top
of SVN. Some general comparision of the various SCMs:

http://linuxmafia.com/faq/Apps/scm.html
http://www.dwheeler.com/essays/scm.html


Thiemo

[PATCH] RTC for TX4927(37) platform

[Vladimir A. Barinov]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Hello All!

This as a patch to add RTC support for TX4927 platform.
The current RTC_DS1742=y can't be ever compiled.

Does it makes sence to push it in?

Regards,
Vladimir

[-- Attachment #2: pro_mips_tx4927_rtc.patch --]
[-- Type: text/plain, Size: 10495 bytes --]

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
 	RTC support for TX4927/37 platform in 2.6.
 	
Index: linux-2.6.10/arch/mips/tx4927/common/Makefile
===================================================================
--- linux-2.6.10/arch/mips/tx4927/common/Makefile
+++ linux-2.6.10/arch/mips/tx4927/common/Makefile
@@ -6,7 +6,7 @@
 # unless it's something special (ie not a .c file).
 #
 
-obj-y	+= tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o
+obj-y	+= tx4927_prom.o tx4927_setup.o tx4927_irq.o tx4927_irq_handler.o rtc_ds1742.o
 
 obj-$(CONFIG_TOSHIBA_FPCIB0)	   += smsc_fdc37m81x.o
 obj-$(CONFIG_KGDB)                 += tx4927_dbgio.o
Index: linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
===================================================================
--- linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
+++ linux-2.6.10/include/asm-mips/tx4927/toshiba_rbtx4927.h
@@ -49,6 +49,7 @@
 #define RBTX4927_SW_RESET_ENABLE     0xbc00f002
 #define RBTX4927_SW_RESET_ENABLE_SET            0x01
 
+#define RBTX4927_RTC_BASE	0xbc010000
 
 #define RBTX4927_RTL_8019_BASE (0x1c020280-TBTX4927_ISA_IO_OFFSET)
 #define RBTX4927_RTL_8019_IRQ  (29)
Index: linux-2.6.10/arch/mips/tx4927/common/rtc_ds1742.c
===================================================================
--- /dev/null
+++ linux-2.6.10/arch/mips/tx4927/common/rtc_ds1742.c
@@ -0,0 +1,141 @@
+/*
+ * arch/mips/tx4927/common/rtc_ds1742.c 
+ * 
+ * This is a copy of:  arch/mips/jmr3927/common/rtc_ds1742.c
+ *
+ * Copyright (c) 2001-2005 MontaVista Software Inc.
+ * Copyright (c) 2000-2001 Toshiba Corporation 
+ *
+ * 2001-2005 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is
+ * licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/types.h>
+#include <linux/ds1742rtc.h>
+
+#include <asm/time.h>
+#include <asm/delay.h>
+#include <asm/debug.h>
+
+#define	EPOCH		2000
+
+#undef BCD_TO_BIN
+#define BCD_TO_BIN(val) (((val)&15) + ((val)>>4)*10)
+
+#undef BIN_TO_BCD
+#define BIN_TO_BCD(val) ((((val)/10)<<4) + (val)%10)
+
+unsigned long rtc_base;
+
+/* RTC-dependent code for time.c */
+
+static unsigned long rtc_ds1742_get_time(void)
+{
+	unsigned int year, month, day, hour, minute, second;
+	unsigned int century;
+	static unsigned int save = 0;
+
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	second 	= BCD_TO_BIN(CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	minute 	= BCD_TO_BIN(CMOS_READ(RTC_MINUTES));
+	hour 	= BCD_TO_BIN(CMOS_READ(RTC_HOURS));
+	day 	= BCD_TO_BIN(CMOS_READ(RTC_DATE));
+	month 	= BCD_TO_BIN(CMOS_READ(RTC_MONTH));
+	year 	= BCD_TO_BIN(CMOS_READ(RTC_YEAR));
+	century = BCD_TO_BIN(CMOS_READ(RTC_CENTURY) & RTC_CENTURY_MASK);
+	CMOS_WRITE(0, RTC_CONTROL);
+
+	/* manual -- must wait 500us min between RTC_READ clr and next set */
+	if (save != second)
+		save = second;
+	else
+		udelay(500);
+
+	year += EPOCH;
+
+	return mktime(year, month, day, hour, minute, second);
+}
+
+static int rtc_ds1742_set_time(unsigned long t)
+{
+	struct rtc_time tm;
+	u8 year, month, day, hour, minute, second;
+	u8 cmos_year, cmos_month, cmos_day, cmos_hour, cmos_minute, cmos_second;
+	int cmos_century;
+
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	cmos_second  = (u8) (CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	cmos_minute  = (u8) CMOS_READ(RTC_MINUTES);
+	cmos_hour    = (u8) CMOS_READ(RTC_HOURS);
+	cmos_day     = (u8) CMOS_READ(RTC_DATE);
+	cmos_month   = (u8) CMOS_READ(RTC_MONTH);
+	cmos_year    = (u8) CMOS_READ(RTC_YEAR);
+	cmos_century = CMOS_READ(RTC_CENTURY) & RTC_CENTURY_MASK;
+	CMOS_WRITE(RTC_WRITE, RTC_CONTROL);
+
+	/* convert */
+	to_tm(t, &tm);
+
+	/* check each field one by one */
+	year = BIN_TO_BCD(tm.tm_year - EPOCH);
+	if (year != cmos_year)
+		CMOS_WRITE(year, RTC_YEAR);
+
+	month = BIN_TO_BCD(tm.tm_mon + 1);
+	if (month != (cmos_month & 0x1f))
+		CMOS_WRITE((month & 0x1f) | (cmos_month & ~0x1f), RTC_MONTH);
+
+	day = BIN_TO_BCD(tm.tm_mday);
+	if (day != cmos_day)
+		CMOS_WRITE(day, RTC_DATE);
+
+	if (cmos_hour & 0x40) {
+		/* 12 hour format */
+		hour = 0x40;
+		if (tm.tm_hour > 12) {
+			hour |= 0x20 | (BIN_TO_BCD(hour - 12) & 0x1f);
+		} else {
+			hour |= BIN_TO_BCD(tm.tm_hour);
+		}
+	} else {
+		/* 24 hour format */
+		hour = BIN_TO_BCD(tm.tm_hour) & 0x3f;
+	}
+
+	if (hour != cmos_hour)
+		CMOS_WRITE(hour, RTC_HOURS);
+
+	minute = BIN_TO_BCD(tm.tm_min);
+	if (minute != cmos_minute)
+		CMOS_WRITE(minute, RTC_MINUTES);
+
+	second = BIN_TO_BCD(tm.tm_sec);
+	if (second != cmos_second)
+		CMOS_WRITE(second & RTC_SECONDS_MASK, RTC_SECONDS);
+
+	/* RTC_CENTURY and RTC_CONTROL share same address... */
+	CMOS_WRITE(cmos_century, RTC_CONTROL);
+	return 0;
+}
+
+void rtc_ds1742_init(unsigned long base)
+{
+	u8 cmos_second;
+
+	/* remember the base */
+	rtc_base = base;
+	db_assert((rtc_base & 0xe0000000) == KSEG1);
+
+	/* clear oscillator stop bit */
+	CMOS_WRITE(RTC_READ, RTC_CONTROL);
+	cmos_second = (u8) (CMOS_READ(RTC_SECONDS) & RTC_SECONDS_MASK);
+	CMOS_WRITE(RTC_WRITE, RTC_CONTROL);
+	CMOS_WRITE(cmos_second, RTC_SECONDS);	/* clear msb */
+	CMOS_WRITE(0, RTC_CONTROL);
+
+	/* set the function pointers */
+	rtc_get_time = rtc_ds1742_get_time;
+	rtc_set_time = rtc_ds1742_set_time;
+}
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
@@ -133,9 +133,6 @@ JP7 is not bus master -- do NOT use -- o
 #include <asm/time.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
-#ifdef CONFIG_RTC_DS1742
-#include <linux/ds1742rtc.h>
-#endif
 #ifdef CONFIG_TOSHIBA_FPCIB0
 #include <asm/tx4927/smsc_fdc37m81x.h>
 #endif
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -63,9 +63,7 @@
 #include <asm/time.h>
 #include <linux/bootmem.h>
 #include <linux/blkdev.h>
-#ifdef CONFIG_RTC_DS1742
 #include <linux/ds1742rtc.h>
-#endif
 #ifdef CONFIG_TOSHIBA_FPCIB0
 #include <asm/tx4927/smsc_fdc37m81x.h>
 #endif
@@ -970,12 +968,6 @@ void __init toshiba_rbtx4927_setup(void)
 			       "+\n");
 }
 
-#ifdef CONFIG_RTC_DS1742
-extern unsigned long rtc_ds1742_get_time(void);
-extern int rtc_ds1742_set_time(unsigned long);
-extern void rtc_ds1742_wait(void);
-#endif
-
 void __init
 toshiba_rbtx4927_time_init(void)
 {
@@ -984,58 +976,14 @@ toshiba_rbtx4927_time_init(void)
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "-\n");
 
-#ifdef CONFIG_RTC_DS1742
-
-	rtc_get_time = rtc_ds1742_get_time;
-	rtc_set_time = rtc_ds1742_set_time;
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":rtc_ds1742_init()-\n");
-	rtc_ds1742_init(0xbc010000);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":rtc_ds1742_init()+\n");
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_hpt_frequency-\n");
-	rtc_ds1742_wait();
-
-	/* get the count */
-	c1 = read_c0_count();
-
-	/* wait for the seconds to change again */
-	rtc_ds1742_wait();
-
-	/* get the count again */
-	c2 = read_c0_count();
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":Calibrate mips_hpt_frequency+\n");
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":c1=%12u\n", c1);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":c2=%12u\n", c2);
-
-	/* this diff is as close as we are going to get to counter ticks per sec */
-	mips_hpt_frequency = abs(c2 - c1);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f1=%12u\n", mips_hpt_frequency);
-
-	/* round to 1/10th of a MHz */
-	mips_hpt_frequency /= (100 * 1000);
-	mips_hpt_frequency *= (100 * 1000);
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT,
-				       ":f2=%12u\n", mips_hpt_frequency);
-
-	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_INFO,
-				       ":mips_hpt_frequency=%uHz (%uMHz)\n",
-				       mips_hpt_frequency,
-				       mips_hpt_frequency / 1000000);
-#else
-	mips_hpt_frequency = 100000000;
+	rtc_ds1742_init(RBTX4927_RTC_BASE);
+	/*
+	 * Default TX4927 processor speed is 200 MHz. However, it
+	 * can be configured by the user
+	 */
+	mips_hpt_frequency = (CONFIG_TOSHIBA_TX4927_CPU_SPEED * 1000000) / 2;
-#endif
 
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "+\n");
-
 }
 
 void __init toshiba_rbtx4927_timer_setup(struct irqaction *irq)
Index: linux-2.6.10/include/asm-mips/ds1742.h
===================================================================
--- /dev/null
+++ linux-2.6.10/include/asm-mips/ds1742.h
@@ -0,0 +1,29 @@
+/*
+ * Machine dependent access functions for RTC registers.
+ *
+ * Do not include this file directly. It's included from linux/ds1742rtc.h
+ *
+ * Author: Vladimir Barinov <vbarinov@ru.mvista.com>
+ *
+ * (c) 2005 MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is
+ * licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#ifndef __LINUX_DS1742_H
+#define __LINUX_DS1742_H
+
+extern unsigned long rtc_base;
+
+static inline unsigned char CMOS_READ(unsigned long addr)
+{
+	return (*(volatile u8 *)(rtc_base + addr));
+}
+
+static inline void CMOS_WRITE(unsigned char data, unsigned long addr)
+{
+	*(volatile u8 *)(rtc_base + addr) = data;
+}
+
+#endif /* __LINUX_DS1742_H */
Index: linux-2.6.10/arch/mips/tx4927/Kconfig
===================================================================
--- linux-2.6.10/arch/mips/tx4927/Kconfig	2005-01-30 23:45:36.000000000 +0300
+++ linux-2.6.10/arch/mips/tx4927/Kconfig	2005-09-14 15:41:00.000000000 +0400
@@ -1,3 +1,11 @@
+config TOSHIBA_TX4927_CPU_SPEED
+        int "CPU speed of the TX4927 processor (MHz)"
+        depends on TOSHIBA_RBTX4927
+        default 200
+        help
+          This sets the speed for the TX4927 processor. The default speed
+          is 200 MHz.
+
 config TOSHIBA_FPCIB0
 	bool "FPCIB0 Backplane Support"
 	depends on TOSHIBA_RBTX4927

[PATCH] Remove compile warnings for TX4927(37) platform

[Vladimir A. Barinov]

[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

Hello All!

This as a patch to aviod compile warnings for TX4927 platform.

Does it makes sence to push it in?

Regards,
Vladimir


[-- Attachment #2: pro_mips_tx4927_warnings.patch --]
[-- Type: text/plain, Size: 3293 bytes --]

 Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
 Description:
 	Patch to aviod compile warnings from TX4927/37 platform.
                                                                                                                                                             
Index: linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/common/tx4927_irq.c
@@ -567,6 +567,8 @@ int tx4927_irq_nested(void)
 
 #ifdef CONFIG_TOSHIBA_RBTX4927
 			{
+				extern int toshiba_rbtx4927_irq_nested(int
+								       sw_irq);
 				sw_irq = toshiba_rbtx4927_irq_nested(sw_irq);
 			}
 #endif
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_irq.c
@@ -293,8 +293,10 @@ u32 bit2num(u32 num)
 int toshiba_rbtx4927_irq_nested(int sw_irq)
 {
 	u32 level3;
+#ifdef CONFIG_TOSHIBA_FPCIB0
 	u32 level4;
 	u32 level5;
+#endif
 
 	level3 = reg_rd08(TOSHIBA_RBTX4927_IOC_INTR_STAT) & 0x1f;
 	if (level3) {
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c
@@ -74,7 +74,7 @@ void __init prom_init(void)
 	else
 		mips_machtype = MACH_TOSHIBA_RBTX4937;
 
-        toshiba_name = toshiba_name_list[mips_machtype];
+        toshiba_name = (char *)toshiba_name_list[mips_machtype];
 
 	msize = tx4927_get_mem_size();
 	add_memory_region(0, msize << 20, BOOT_MEM_RAM);
Index: linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
===================================================================
--- linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c
@@ -134,6 +134,9 @@ int tx4927_using_backplane = 0;
 extern void gt64120_time_init(void);
 extern void toshiba_rbtx4927_irq_setup(void);
 
+extern char *prom_getcmdline(void);
+extern void rtc_ds1742_init(unsigned long);
+
 #ifdef CONFIG_PCI
 #define CONFIG_TX4927BUG_WORKAROUND
 #undef TX4927_SUPPORT_COMMAND_IO
@@ -268,7 +271,9 @@ static int __init tx4927_pcibios_init(vo
 			u8 v08_64;
 			u32 v32_b0;
 			u8 v08_e1;
+#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG
 			char *s = " sb/isa --";
+#endif
 
 			TOSHIBA_RBTX4927_SETUP_DPRINTK
 			    (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -353,7 +358,9 @@ static int __init tx4927_pcibios_init(vo
 			u8 v08_41;
 			u8 v08_43;
 			u8 v08_5c;
+#ifdef TOSHIBA_RBTX4927_SETUP_DEBUG
 			char *s = " sb/ide --";
+#endif
 
 			TOSHIBA_RBTX4927_SETUP_DPRINTK
 			    (TOSHIBA_RBTX4927_SETUP_PCIBIOS, ":%s beg\n",
@@ -971,9 +978,6 @@ void __init toshiba_rbtx4927_setup(void)
 void __init
 toshiba_rbtx4927_time_init(void)
 {
-	u32 c1;
-	u32 c2;
-
 	TOSHIBA_RBTX4927_SETUP_DPRINTK(TOSHIBA_RBTX4927_SETUP_TIME_INIT, "-\n");
 
 	rtc_ds1742_init(RBTX4927_RTC_BASE);

[PATCH] Fix module insertion fail for TX4927/TX4938 platforms

[Vladimir A. Barinov]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

Hello All!

This patch fixes module insertion fail for TX4927/TX4938 platforms for 
several drivers:
*** Warning: "__wbflush" [fs/reiserfs/reiserfs.ko] undefined!
*** Warning: "__wbflush" [fs/jbd/jbd.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/net2280.ko] undefined!
*** Warning: "__wbflush" [drivers/usb/gadget/g_serial.ko] undefined!
*** Warning: "__wbflush" [drivers/net/ppp_generic.ko] undefined!

Does it makes sence to push it in?

Regards,
Vladimir


[-- Attachment #2: pro_mips_tx4927_modules_fix.patch --]
[-- Type: text/plain, Size: 841 bytes --]

Signed-off-by: Vladimir Barinov <vbarinov@ru.mvista.com>
Description:
	Fix module insertion fail on TX4927/TX4938 platforms

Index: linux-2.6.10/arch/mips/tx4927/common/tx4927_setup.c
===================================================================
--- linux-2.6.10.orig/arch/mips/tx4927/common/tx4927_setup.c
+++ linux-2.6.10/arch/mips/tx4927/common/tx4927_setup.c
@@ -231,3 +231,5 @@ void pk0(void)
 	printk("k0=[0x%08x]\n", val);
 }
 #endif
+
+EXPORT_SYMBOL(__wbflush);
Index: linux-2.6.10/arch/mips/tx4938/common/setup.c
===================================================================
--- linux-2.6.10.orig/arch/mips/tx4938/common/setup.c
+++ linux-2.6.10/arch/mips/tx4938/common/setup.c
@@ -89,3 +89,5 @@ void __init tx4938_timer_setup(struct ir
 	write_c0_compare(count);
 	c2 = read_c0_count();
 }
+
+EXPORT_SYMBOL(__wbflush);

Re: [PATCH] Ethernet for TX4927(37) platform

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On Wed, 2005-09-14 16:55:31 +0400, Vladimir A. Barinov <vbarinov@ru.mvista.com> wrote:
> Hello All!
> 
> This as a patch to add ethernet support for TX4927 platform.
> Does it makes sence to push it in?

Whenever you want to start a new thread of discussion, please do so
and don't simply press 'Reply' on some unrelated email and change the
subject line. Your patches don't correspond to the GIT discossen, so
please keep out out of it.

Thanks, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On Wed, 2005-09-14 13:37:50 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote:
> > monotone
> > 	Is quite nice'n'easy to use for CVS users, you'll have quite a
> > 	fast start. The network sync protocol can be a bit lengthy at
> > 	a time, but it works. It's acceptable in speed, but not
> > 	exactly "fast". Written in C, code can easily be read and
> > 	hacked.
> 
> Git has taken some ideas from Monotone.

Though monotone uses a (berkeley?) DB to store all objects...

> > arch
> > 	Arch can do almost everything; it's network sync protocol is
> > 	quite fast (can use several transports and will make use of
> > 	caches). However, it's not exactly easy to use because of it's
> > 	thousands of commands and it's project name conventions are,
> > 	um, ugly. It has very good merging capabilities, but it's
> > 	heavy use of local caches forces you to have loads of free HDD
> > 	space.
> 
> Git is a huge diskspace consumer also unless repositories are converted.
> For example, the Linux kernel repository from CVS did inflate itself to
> over 4GB and over 340,000 files.  After packing I got that down to like
> 170MB.  Not bad compared to the some 770MB of RCS files it's using
> currently and < 11s checkout from git can't be wrong either ;-)

Well, Arch *may* cache any tree version you check out. So take a
source tree and check-out some 15 tree versions, you may end up with a
really *hugh* cache. You're free to delete it, though...

> > To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> > the way[tm] to go, so we'd try to get familiar with it.
> 
> The other accepted currency of the trade are still simple patches, see
> http://www.linux-mips.org/wiki/The_perfect_patch.

ACK. But unless you've got the perfect Patch Queue Manager that'll
re-diff and re-send your patches automatically to Linus, you keep on
doing some manual work or at least starting your scripts ever and ever
again :)

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Git

[Nigel Stephens]

Jan-Benedict Glaw wrote:

>>>To get fixes/port updates/subsystem updates upstream to Linus, GIT is
>>>the way[tm] to go, so we'd try to get familiar with it.
>>>      
>>>
>>The other accepted currency of the trade are still simple patches, see
>>http://www.linux-mips.org/wiki/The_perfect_patch.
>>    
>>
>
>ACK. But unless you've got the perfect Patch Queue Manager that'll
>re-diff and re-send your patches automatically to Linus, you keep on
>doing some manual work or at least starting your scripts ever and ever
>again :)
>
>  
>

Speaking of patch management, has anyone tried out Stacked GIT (aka 
StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like 
it could be useful, and can be used in conjunction with other porcelain 
like Cogito.

Nigel

Re: Git

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Ni Nigel!

On Wed, 2005-09-14 16:27:15 +0100, Nigel Stephens <nigel@mips.com> wrote:
> Jan-Benedict Glaw wrote:
> >>>To get fixes/port updates/subsystem updates upstream to Linus, GIT is
> >>>the way[tm] to go, so we'd try to get familiar with it.
> >>The other accepted currency of the trade are still simple patches, see
> >>http://www.linux-mips.org/wiki/The_perfect_patch.
> >
> >ACK. But unless you've got the perfect Patch Queue Manager that'll
> >re-diff and re-send your patches automatically to Linus, you keep on
> >doing some manual work or at least starting your scripts ever and ever
> >again :)
> 
> Speaking of patch management, has anyone tried out Stacked GIT (aka 
> StGIT, aka quilt on GIT) at http://www.procode.org/stgit/? It looks like 
> it could be useful, and can be used in conjunction with other porcelain 
> like Cogito.

No, not yet, mostly due to time reasons. But I second it sounds
useful. 

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]