Re: CVS Update@-mips.org: linux

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

You forgot to patch mips64 / 2.6 also.  *grrr*

  Ralf

On Wed, Jul 16, 2003 at 02:08:24AM +0100, sjhill@linux-mips.org wrote:
> From:	sjhill@linux-mips.org
> To:	linux-cvs@linux-mips.org
> Subject: CVS Update@-mips.org: linux 
> Date:	Wed, 16 Jul 2003 02:08:24 +0100
> 
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	sjhill@ftp.linux-mips.org	03/07/16 02:08:24
> 
> Modified files:
> 	arch/mips/kernel: Tag: linux_2_4 setup.c time.c 
> 	arch/mips/mm   : Tag: linux_2_4 tlb-r4k.c 
> 	arch/mips/tx4927/common: Tag: linux_2_4 tx4927_irq.c 
> 	arch/mips/tx4927/toshiba_rbtx4927: Tag: linux_2_4 
> 	                                   toshiba_rbtx4927_irq.c 
> 	                                   toshiba_rbtx4927_prom.c 
> 	                                   toshiba_rbtx4927_setup.c 
> 	include/asm-mips: Tag: linux_2_4 au1000.h pci.h 
> 
> Log message:
> 	A bunch of small clean ups to remove compile warning messages.
> 

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sat, 18 Dec 2004, Steven J. Hill wrote:

> > Log message:
> > 	Fixup the SiByte PCI-HT bridge lying about being a host bridge.
> > 
> The file 'arch/mips/pci/fixup-sb1250.c' is missing. Please place into
> CVS. Thank you.

 Gosh, thanks for the notice.  I've just fixed it up.

  Maciej

Re: CVS Update@-mips.org: linux

[Steven J. Hill]

macro@linux-mips.org wrote:
> 
> Modified files:
> 	arch/mips/pci  : Makefile 
> 	include/linux  : pci_ids.h 
> 
> Log message:
> 	Fixup the SiByte PCI-HT bridge lying about being a host bridge.
> 
The file 'arch/mips/pci/fixup-sb1250.c' is missing. Please place into
CVS. Thank you.

-Steve

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 17 Dec 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: setup.c smp.c 
> 
> Log message:
> 	Clean-up compiler warnings.

 Please follow "CodingStyle" when doing changes.

  Maciej

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 16 Dec 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	drivers/i2c    : Kconfig 
> 	drivers/i2c/chips: adm1021.c 
> Removed files:
> 	drivers/i2c    : i2c-max1617.c 
> 
> Log message:
> 	Remove obsolete MAX1617 driver code. The 'adm1021' driver handles both
> 	the 1617 and 1617a with a minor modification. This chip now works properly
> 	on SiByte Swarm boards.

 The removal is welcome, but the change to adm1021.c is broken.  You
should set I2C_CLASS_HWMON for the SiByte I2C adapter instead.  Please fix
your commit.  Thanks.

  Maciej

Re: CVS Update@-mips.org: linux

[Steven J. Hill]

sjhill@linux-mips.org wrote:
> 
> Log message:
> 	Remove obsolete MAX1617 driver code. The 'adm1021' driver handles both
> 	the 1617 and 1617a with a minor modification. This chip now works properly
> 	on SiByte Swarm boards.

Ralf,

A lot of the I2C code, specifically the headers files in 'include/linux' need
to be pushed back to the I2C maintainers. Would you like me to make the patches
and do that, or do you have time?

-Steve

Re: CVS Update@-mips.org: linux

[Manish Lachwani]

ralf@linux-mips.org wrote:
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/12/09 22:09:24
> 
> Modified files:
> 	arch/mips/sibyte/sb1250: irq_handler.S 
> 
> Log message:
> 	And yet another build fix.
> 
> 

Hi Ralf

There is one more build fix needed in drivers/net/sb1250-mac.c



if (sbmac_init(dev, idx)) {
			port = A_MAC_CHANNEL_BASE(idx);
			SBMAC_WRITECSR(KSEG1ADDR(port+R_MAC_ETHERNET_ADDR),
					sbmac_orig_hwaddr[idx] );
			free_netdev(dev);
			continue;
		}

If you wish, I can send a patch

Thanks
Manish Lachwani

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Sun, 2004-11-28 12:53:36 +0100, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20041128115336.GB14004@linux-mips.org>:
> On Sun, Nov 28, 2004 at 02:01:44AM +0000, Maciej W. Rozycki wrote:

> As a deterring example why I try to cut down on system messages checkout:
> 
>   http://www.linux-mips.org/wiki/index.php/IP27_boot_messages
> 
> 70kB of little information crawling over a 19k2 console making kernel
> startup an entertaining experience for the whole family ;-)

Ralf, don't get me wrong, but you're a lamer :)   If you don't like your
box, just hand it over to me. 24GB of memory, 128 CPUs, 16x ethernet,
16x serial, 32x SCSI, 33x HDD, yay, that looks quite promising. I
appreciate this as a christmas present :)

By the way, could you post some physical values of this box (like
dimenstion, approx. weight, power consumption during stand-by and work)?

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
 fuer 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: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sun, Nov 28, 2004 at 05:44:16PM +0000, Maciej W. Rozycki wrote:
> Date: Sun, 28 Nov 2004 17:44:16 +0000 (GMT)
> From: "Maciej W. Rozycki" <macro@linux-mips.org>
> To: Ralf Baechle <ralf@linux-mips.org>
> Cc: sjhill@linux-mips.org, linux-mips@linux-mips.org
> Subject: Re: CVS Update@-mips.org: linux
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Sun, 28 Nov 2004, Ralf Baechle wrote:
> 
> > >  Anyone is free to bump their console/syslog loglevel to get rid of less
> > > important messages to suit there preferences.  And INFO, which is what the
> > > message uses, is the lowest level for stuff for non-developers.
> > 
> > As a deterring example why I try to cut down on system messages checkout:
> > 
> >   http://www.linux-mips.org/wiki/index.php/IP27_boot_messages
> > 
> > 70kB of little information crawling over a 19k2 console making kernel
> > startup an entertaining experience for the whole family ;-)
> 
>  Why don't you boot at 115200bps then?  I do that with my DECstations
> (well, since I've fixed their serial console to support it).  Otherwise
> there's that "quiet" argument to bump the console loglevel.
> 
>  Besides the SWARM and friends boot at 115200bps by default anyway and
> their average bootstrap log size is around 7kB... ;-)

Because that a) the default rate of the machine and b) the limit of the
terminal server.  ALOT of console servers.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sun, 28 Nov 2004, Ralf Baechle wrote:

> >  Anyone is free to bump their console/syslog loglevel to get rid of less
> > important messages to suit there preferences.  And INFO, which is what the
> > message uses, is the lowest level for stuff for non-developers.
> 
> As a deterring example why I try to cut down on system messages checkout:
> 
>   http://www.linux-mips.org/wiki/index.php/IP27_boot_messages
> 
> 70kB of little information crawling over a 19k2 console making kernel
> startup an entertaining experience for the whole family ;-)

 Why don't you boot at 115200bps then?  I do that with my DECstations
(well, since I've fixed their serial console to support it).  Otherwise
there's that "quiet" argument to bump the console loglevel.

 Besides the SWARM and friends boot at 115200bps by default anyway and
their average bootstrap log size is around 7kB... ;-)

  Maciej

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sun, Nov 28, 2004 at 02:01:44AM +0000, Maciej W. Rozycki wrote:

> > We're already printing way too much stuff and this is a not very useful
> > message so why not removing the whole thing for good ...
> 
>  This is useful for reliability verification.  See the thread starting at:  
> "http://oss.sgi.com/projects/netdev/archive/2004-11/msg00475.html".  The
> setting should also be user controllable, but for now people should at
> least know whether it's in effect or not.
> 
>  Anyone is free to bump their console/syslog loglevel to get rid of less
> important messages to suit there preferences.  And INFO, which is what the
> message uses, is the lowest level for stuff for non-developers.

As a deterring example why I try to cut down on system messages checkout:

  http://www.linux-mips.org/wiki/index.php/IP27_boot_messages

70kB of little information crawling over a 19k2 console making kernel
startup an entertaining experience for the whole family ;-)

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sun, 28 Nov 2004, Ralf Baechle wrote:

> We're already printing way too much stuff and this is a not very useful
> message so why not removing the whole thing for good ...

 This is useful for reliability verification.  See the thread starting at:  
"http://oss.sgi.com/projects/netdev/archive/2004-11/msg00475.html".  The
setting should also be user controllable, but for now people should at
least know whether it's in effect or not.

 Anyone is free to bump their console/syslog loglevel to get rid of less
important messages to suit there preferences.  And INFO, which is what the
message uses, is the lowest level for stuff for non-developers.

  Maciej

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sat, Nov 27, 2004 at 10:05:07PM +0000, Maciej W. Rozycki wrote:

> > Log message:
> > 	Clean up comments, add in new module parameter handling to get rid of compiler
> > 	warnings and Manish's printk patch for ethernet device names shown in email
> > 	(http://www.linux-mips.org/archives/linux-mips/2004-11/msg00116.html).
> 
>  Hmm, shouldn't that be:
> 
> if (sc->rx_hw_checksum == ENABLE)
>         printk(KERN_INFO "%s: enabling TCP rcv checksum\n", sc->sbm_dev->name);
> 
> Otherwise the report doesn't actually reflect the condition.
> 
>  I'll change it thus as obvious.

We're already printing way too much stuff and this is a not very useful
message so why not removing the whole thing for good ...

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sat, 27 Nov 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	drivers/net    : sb1250-mac.c 
> 
> Log message:
> 	Clean up comments, add in new module parameter handling to get rid of compiler
> 	warnings and Manish's printk patch for ethernet device names shown in email
> 	(http://www.linux-mips.org/archives/linux-mips/2004-11/msg00116.html).

 Hmm, shouldn't that be:

if (sc->rx_hw_checksum == ENABLE)
        printk(KERN_INFO "%s: enabling TCP rcv checksum\n", sc->sbm_dev->name);

Otherwise the report doesn't actually reflect the condition.

 I'll change it thus as obvious.

  Maciej

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 21 Oct 2004, Ralf Baechle wrote:

> > I have been consulting with PMC-Sierra and received confirmation that
> > the problems described under errata items 2.15 and 2.16 still exist
> > with rev. 1.2 silicon.
> 
> Linux does not use Hit_Writeback_D and Hit_Writeback_SD so these can't

 Yet?

> possible be a problem.

 Now.  Though the issue can only be revisited once the situation changes, 
indeed.

  Maciej

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Oct 21, 2004 at 11:19:50AM +0200, Thomas Koeller wrote:

> I have been consulting with PMC-Sierra and received confirmation that
> the problems described under errata items 2.15 and 2.16 still exist
> with rev. 1.2 silicon.

Linux does not use Hit_Writeback_D and Hit_Writeback_SD so these can't
possible be a problem.

  Ralf

Re: CVS Update@-mips.org: linux

[Thomas Koeller]

I have been consulting with PMC-Sierra and received confirmation that
the problems described under errata items 2.15 and 2.16 still exist
with rev. 1.2 silicon.

Thomas



On Wednesday 20 October 2004 18:58, Thomas Koeller wrote:
> On Wednesday 20 October 2004 04:34, ralf@linux-mips.org wrote:
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ralf@ftp.linux-mips.org	04/10/20 03:34:25
> >
> > Modified files:
> > 	include/asm-mips: pgtable-bits.h
> >
> > Log message:
> > 	Switch RM9000 to caching mode 5.  Note this requires silicon revision
> > 	1.2 of `Titan'.  Unless somebody really needs backwards compatibility
> > 	with older versions and yells really loud I won't support backward
> > 	compatibility.
>
> Are you referring to items 2.15 and 2.16 described in the
> RM9x2x Silicon Revision Errata 1.1? In case you are, these are still
> present in the errata sheet for rev. 1.2. Could you please clarify this
> point, otherwise I cannot decide whether I need backwards compatibility or
> not.
>
> thanks,
> Thomas

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

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

Re: CVS Update@-mips.org: linux

[Thomas Koeller]

On Wednesday 20 October 2004 04:34, ralf@linux-mips.org wrote:
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/10/20 03:34:25
>
> Modified files:
> 	include/asm-mips: pgtable-bits.h
>
> Log message:
> 	Switch RM9000 to caching mode 5.  Note this requires silicon revision
> 	1.2 of `Titan'.  Unless somebody really needs backwards compatibility
> 	with older versions and yells really loud I won't support backward
> 	compatibility.

Are you referring to items 2.15 and 2.16 described in the
RM9x2x Silicon Revision Errata 1.1? In case you are, these are still present
in the errata sheet for rev. 1.2. Could you please clarify this point,
otherwise I cannot decide whether I need backwards compatibility or not.

thanks,
Thomas

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

Thomas Koeller, Software Development
Basler Vision Technologies

thomas dot koeller at baslerweb dot com
http://www.baslerweb.com

==============================

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 23 Aug 2004, Ralf Baechle wrote:

> Due to PAGE_SHIFT being undefined?  You meant the opposite?

 Yes.  No.  PAGE_SHIFT is defined conditionally based on 
CONFIG_PAGE_SIZE_*, which is of course undefined in a generic set of 
headers.

 With PAGE_SIZE undefined you can fall back to sysconf(_SC_PAGESIZE) or 
the page size in the ELF auxiliary vector (depending on the context).  

> Procps but I have dark memories of other packages doing the same thing, so
> I gave up and kludged the thing the same way other architectures do.
> Even IA-64 which is suffering the same pains with variable page size.

 Do they?  Anyway that's not a way to fix broken software.  Perhaps we 
could do the following hack to teach the resistant:

#ifndef __KERNEL__
#warning PAGE_SIZE is not a user macro, fix your program!
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#endif

but glibc might not be especially happy about such an alias.

 If you really insist on PAGE_SIZE being constant, then please at least
define it to the maximum supported size for the userland, so that page
alignment rules are kept.  I don't see any reason to keep bugs alive,
though.

  Maciej

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Aug 23, 2004 at 05:54:19AM -0400, Kumba wrote:

> procps is probably the trigger of this.  Me and some other Gentoo/MIPS 
> devs/users got into a bit of a heated discussion w/ the procps 
> maintainer, who didn't quite like the fact that A) We don't use 
> "sanitized" kernel headers B) PAGE_SIZE was hidden on MIPS and C) 
> "properly sanitized" headers would provide PAGE_SIZE.  We opted instead 
> for a patch to procps that used sysconf(_SC_PAGESIZE) to fetch the 
> value, and I guess this just didn't rub the right way w/ the maintainer. 

Who happens to be Albert Calahan, just to mention the name.

As for the sanitized kernel headers package he's probably right.  At the
current state of Linux kernel headers - all architectures, not just MIPS -
mail threads like this will be unavoidable if we try to continue
supporting kernel headers in userspace.  I can be convinced to support
such use to the same point as i386 but not a single symbol beyond that.

> I can post the discussions for those interested (or just looking for 
> amusement), and anyone curious enough can look at proc/procps.h in the 
> procps tree for a rather amusing (IMHO) comment on MIPS at the top of 
> the source.

Whoever wrote that has a very screwed idea of the MIPS realities.

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Aug 23, 2004 at 11:29:46AM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Undo change from rev 1.37; some userspace software is expecting
> > 	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
> > 	<asm/page.h>.  Sigh ...
> 
>  Fix that software then, instead of breaking good one (hint -- what is the
> "right" value of PAGE_SHIFT and why it doesn't work for that system over
> there?).  With these macros exported it's hard to guess whether the page
> size can be hardcoded or it should get determined at the run time.  And 
> with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
> Please revert the braindamage.

Due to PAGE_SHIFT being undefined?  You meant the opposite?

>  What software is the offender, BTW?

Procps but I have dark memories of other packages doing the same thing, so
I gave up and kludged the thing the same way other architectures do.
Even IA-64 which is suffering the same pains with variable page size.

  Ralf

Re: CVS Update@-mips.org: linux

[Kumba]

Maciej W. Rozycki wrote:

> On Fri, 20 Aug 2004 ralf@linux-mips.org wrote:
> 
> 
>>Log message:
>>	Undo change from rev 1.37; some userspace software is expecting
>>	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
>>	<asm/page.h>.  Sigh ...
> 
> 
>  Fix that software then, instead of breaking good one (hint -- what is the
> "right" value of PAGE_SHIFT and why it doesn't work for that system over
> there?).  With these macros exported it's hard to guess whether the page
> size can be hardcoded or it should get determined at the run time.  And 
> with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
> Please revert the braindamage.
> 
>  What software is the offender, BTW?
> 
>   Maciej

procps is probably the trigger of this.  Me and some other Gentoo/MIPS 
devs/users got into a bit of a heated discussion w/ the procps 
maintainer, who didn't quite like the fact that A) We don't use 
"sanitized" kernel headers B) PAGE_SIZE was hidden on MIPS and C) 
"properly sanitized" headers would provide PAGE_SIZE.  We opted instead 
for a patch to procps that used sysconf(_SC_PAGESIZE) to fetch the 
value, and I guess this just didn't rub the right way w/ the maintainer. 
  Got me.

I can post the discussions for those interested (or just looking for 
amusement), and anyone curious enough can look at proc/procps.h in the 
procps tree for a rather amusing (IMHO) comment on MIPS at the top of 
the source.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 20 Aug 2004 ralf@linux-mips.org wrote:

> Log message:
> 	Undo change from rev 1.37; some userspace software is expecting
> 	PAGE_SIZE, PAGE_SHIFT and PAGE_MASK to be accessible through
> 	<asm/page.h>.  Sigh ...

 Fix that software then, instead of breaking good one (hint -- what is the
"right" value of PAGE_SHIFT and why it doesn't work for that system over
there?).  With these macros exported it's hard to guess whether the page
size can be hardcoded or it should get determined at the run time.  And 
with glibc you get a compilation error due to PAGE_SHIFT being undefined.  
Please revert the braindamage.

 What software is the offender, BTW?

  Maciej

Re: CVS Update@-mips.org: linux

[Christoph Hellwig]

On Wed, Aug 11, 2004 at 09:28:58PM +0100, ralf@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/08/11 21:28:58
> 
> Modified files:
> 	fs/partitions  : sgi.c 
> 
> Log message:
> 	Handle MD array auto-detection in disk volume headers.

Note that adding more autodetection has been rejected for mainline
multiple times.

RE: CVS Update@-mips.org: linux

[Manish Lachwani]

AFAIK, Alliance Semiconductor got the IP of Sipackets. 

Thanks
Manish

-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
Sent: Wednesday, May 19, 2004 9:43 AM
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 


On Wed, 19 May 2004 ralf@linux-mips.org wrote:

> Modified files:
> 	drivers/pci    : pci.ids 
> 
> Log message:
> 	Alpha processor Inc is dead; vendor ID 0x14d9 is now SiPackets.

 How about importing correct data from the official source?  SiPackets is
dead -- vendor ID 0x14d9 is now Alliance Semiconductor Corporation. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Wed, 19 May 2004 ralf@linux-mips.org wrote:

> Modified files:
> 	drivers/pci    : pci.ids 
> 
> Log message:
> 	Alpha processor Inc is dead; vendor ID 0x14d9 is now SiPackets.

 How about importing correct data from the official source?  SiPackets is
dead -- vendor ID 0x14d9 is now Alliance Semiconductor Corporation. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Wed, 21 Apr 2004, Jun Sun wrote:

> >  In that case, fixing pci_assign_unassigned_resources() was the right way
> > to go, instead of implementing a system-specific workaround.  
> 
> Using pci_auto() represented a different approach, which to many seems more
> correct.  It does assignment first and then scanning.  It is supplied
> as a replacement for broken firmware.

 Well the Alpha port did resource management since its early days, due to
the complexity of Alpha setups (I'm pretty sure DEC was first to put
PCI-PCI bridges into their systems on a regular basis) and firmware
oddities (not necessarily due to brokenness but rather competing
assumptions, although there was an option to run MILO from the system
flash ROM and then the system wouldn't execute a lot of initialization
steps before passing control to Linux), like setting up I/O port
allocations above 0xffff, which would surprise some drivers.  That means
around 1995 or 1996.  So the code has been out there for a long time --
long enough to make any remaining problems resolved.

> At one time a couple of pci_auto()'s existed in more than one arch.  And
> there was a chance to make this approach the official one and completely 
> eliminate pci_assign_unassigned_resources().

 But if it didn't happen, then it means it was not the right approach.

> Having competing approaches co-existing in Linux is a norm.

 Well, it's normal for development series.  For stable series there's an
established way of doing stuff and port maintainers should migrate.  
Actually, there's a "feature freeze" point in the development series
(which you probably know) to let maintainers finish before a stable
release.  In reality it does not always happen as depending on various 
factors maintainers may have more or less resources available, but better 
or worse they work on eliminating obsolete cruft.

 I'm writing of in-tree development here -- people can do research on
alternatives off-tree, of course, including working and testing in stable
series.  If proved to be good, the results are typically merged in the
early days of development series.

> > There are no
> > excuses -- the source is available.
> 
> Please don't always assume other people are more ignorant ....

 This is insulting -- I never assume that.  One has to prove that to me
first.

 In cases like this, I've noticed the trend is to think: "Well, Linus[1]
is too tough to be convinced to accept arbitrary changes, so let's just
code our stuff independently and keep it with system-specific bits."  But 
as I wrote, code is available and you have two proper choices:

1. Fix what's wrong in the existing code.

2. Propose a superior alternative.

#1 may be easier and #2 may provide better results.  But it doesn't happen
-- I hardly ever hear any voice in discussions on the LKML from people
involved in developing for the MIPS platform.

[1] Substitute a subsystem maintainer as needed.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Jun Sun]

On Wed, Apr 21, 2004 at 04:11:29PM +0200, Maciej W. Rozycki wrote:
> On Tue, 20 Apr 2004, Jun Sun wrote:
> 
> > > drivers/pci can do that, you just need to supply a few board specific
> > > functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> > > only b0rked, it also duplicates code.
> > 
> > Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> > It was badly broken in early 2.4 kernels while pci_auto was the only 
> > option.
> 
>  In that case, fixing pci_assign_unassigned_resources() was the right way
> to go, instead of implementing a system-specific workaround.  

Using pci_auto() represented a different approach, which to many seems more
correct.  It does assignment first and then scanning.  It is supplied
as a replacement for broken firmware.

At one time a couple of pci_auto()'s existed in more than one arch.  And
there was a chance to make this approach the official one and completely 
eliminate pci_assign_unassigned_resources().

Having competing approaches co-existing in Linux is a norm.

> There are no
> excuses -- the source is available.
> 

Please don't always assume other people are more ignorant ....

Jun

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 20 Apr 2004, Jun Sun wrote:

> > drivers/pci can do that, you just need to supply a few board specific
> > functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> > only b0rked, it also duplicates code.
> 
> Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> It was badly broken in early 2.4 kernels while pci_auto was the only 
> option.

 In that case, fixing pci_assign_unassigned_resources() was the right way
to go, instead of implementing a system-specific workaround.  There are no
excuses -- the source is available.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Gleb O. Raiko]

Jun Sun wrote:
> 
> Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
> It was badly broken in early 2.4 kernels while pci_auto was the only
> option.

In fact, I have used pci_assign_unassigned_resources() from early 2.4
days. The only code I had to supply was
fixup of PCI-PCI bridge spaces which was done in pcibios_fixup_bus,
something like
        if(!bus->self) /* Primary busses */
                bus->resource[0] = &ioport_resource;
                bus->resource[1] = &iomem_resource;
	else /* busses behind PCI-PCI bridges */
	    for IO, MEM, and PREFETCH spaces:
                bus->resource[i] =
&bus->self->resource[PCI_BRIDGE_RESOURCES+i];
                bus->resource[i]->start =
bus->parent->resource[i]->start;
                bus->resource[i]->end   = bus->parent->resource[i]->end;
                bus->resource[i]->flags =
bus->parent->resource[i]->flags;
                bus->resource[i]->name  = bus->name;


Ah, I had to disable ISA mapping in 2.4.25.

After that, pci_assign_unassigned_resources() assigns all resources
properly. If for some reason, you have to preserve PBAR's values
assigned by a BIOS, setup pci_dev.resource[].parent before invoking
pci_assign_unassigned_resources.
> 
> So at most you can only say "pci_assign_unassigned_resources() can
> finally does what pci_auto does". :)

Exactly.

Regards,
Gleb.

Re: CVS Update@-mips.org: linux

[Jun Sun]

On Tue, Apr 20, 2004 at 10:11:28PM +0200, Ralf Baechle wrote:
> On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:
> 
> > CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
> > to be a choice at the first place.
> > 
> > And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
> > whose firmware do not do a proper or full PCI resource assignment.
> 
> drivers/pci can do that, you just need to supply a few board specific
> functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
> only b0rked, it also duplicates code.
> 

Has anybody succssfully used pci_assign_unassigned_resources() in latest 2.4?
It was badly broken in early 2.4 kernels while pci_auto was the only 
option.

So at most you can only say "pci_assign_unassigned_resources() can
finally does what pci_auto does". :)

Jun

Re: CVS Update@-mips.org: linux

[Pete Popov]

Ralf Baechle wrote:

>On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:
>
>  
>
>>CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
>>to be a choice at the first place.
>>
>>And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
>>whose firmware do not do a proper or full PCI resource assignment.
>>    
>>
>
>drivers/pci can do that, you just need to supply a few board specific
>functions, see for example arch/alpha/kernel/pci.c.  
>
>So pci_auto.c isn't only b0rked, it also duplicates code.
>  
>
I guess I have different take on it, in line with Jun's. Before pci 
auto, I remember new boards going in without proper pci config support 
or with massive amounts of new board specific code. Take a look at the 
gt64xxx code (though I think it's been cleaned up a lot since then). 
After pci auto, adding pci support for a new board became trivial and I 
haven't seen anymore code duplication with new boards adding their own, 
complete, pci resource assignment routines.  Pci auto was added a long 
time ago. If it has outlived its purpose, that's fine, but back then it 
was a major improvement to the mips pci subsystem, imho.

Pete

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Apr 20, 2004 at 10:51:16AM -0700, Jun Sun wrote:

> CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
> to be a choice at the first place.
> 
> And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
> whose firmware do not do a proper or full PCI resource assignment.

drivers/pci can do that, you just need to supply a few board specific
functions, see for example arch/alpha/kernel/pci.c.  So pci_auto.c isn't
only b0rked, it also duplicates code.

  Ralf

Re: CVS Update@-mips.org: linux

[Jun Sun]

On Tue, Apr 20, 2004 at 05:32:25PM +0100, sjhill@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	sjhill@ftp.linux-mips.org	04/04/20 17:32:25
> 
> Modified files:
> 	arch/mips      : Tag: linux_2_4 config-shared.in 
> 
> Log message:
> 	Do not allow CONFIG_PCI_AUTO to be selectable to discourage new users
> 	from using this b0rked code.
> 

CONFIG_PCI_AUTO was meant to a board attribute.  It should not be changed
to be a choice at the first place.

And, the code is not bOrked.  In 2.4 it is a life saver for most MIPS boards
whose firmware do not do a proper or full PCI resource assignment.

Jun

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 22 Mar 2004 ralf@linux-mips.org wrote:

> Log message:
> 	Move check_gcc; it was being used before defined.

 And you've moved it down further?  What's the sense?  Also I feel 
check_gas and check_gcc should be kept together.  I'm checking in an 
update to match what the 32-bit port does.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[freshy98]

Ralf,

Is this made from the error message I had the day before yesterday?
If so, I will try to build a new vmlinux.64 tonight and retry it.

With kind regards,

freshy98


> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	04/03/17 15:30:19
> 
> Modified files:
> 	arch/mips/mm   : Tag: linux_2_4 sc-rm7k.c 
> 	arch/mips64/mm : Tag: linux_2_4 sc-rm7k.c 
> 
> Log message:
> 	RM7000 second level cache was likely to nuke the system if it was
> 	called with caches already enabled.
> 
> 

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

Re: CVS Update@-mips.org: linux

[Yoichi Yuasa]

Hello Steven,

You need to add the following change further.
Please apply this patch to v2.4.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/pci/pci.c linux/arch/mips/pci/pci.c
--- linux-orig/arch/mips/pci/pci.c	2003-06-28 11:26:25.000000000 +0900
+++ linux/arch/mips/pci/pci.c	2004-03-16 12:42:37.000000000 +0900
@@ -129,7 +129,7 @@
 	return pcibios_enable_resources(dev, mask);
 }
 
-#ifdef CONFIG_NEW_PCI
+#ifdef CONFIG_PCI_NEW
 /*
  * Named PCI new and about to die before it's old :-)
  *



On Mon, 15 Mar 2004 20:50:56 +0000
sjhill@linux-mips.org wrote:

> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	sjhill@ftp.linux-mips.org	04/03/15 20:50:56
> 
> Modified files:
> 	arch/mips      : Tag: linux_2_4 config-shared.in defconfig 
> 	                 defconfig-atlas defconfig-bosporus 
> 	                 defconfig-capcella defconfig-cobalt 
> 	                 defconfig-csb250 defconfig-db1000 
> 	                 defconfig-db1100 defconfig-db1500 
> 	                 defconfig-db1550 defconfig-ddb5476 
> 	                 defconfig-ddb5477 defconfig-decstation 
> 	                 defconfig-e55 defconfig-eagle defconfig-ev64120 
> 	                 defconfig-ev96100 defconfig-hp-lj 
> 	                 defconfig-hydrogen3 defconfig-ip22 
> 	                 defconfig-it8172 defconfig-ivr 
> 	                 defconfig-jmr3927 defconfig-lasat 
> 	                 defconfig-malta defconfig-mirage 
> 	                 defconfig-mpc30x defconfig-mtx-1 defconfig-nino 
> 	                 defconfig-ocelot defconfig-osprey 
> 	                 defconfig-pb1000 defconfig-pb1100 
> 	                 defconfig-pb1500 defconfig-pb1550 
> 	                 defconfig-rbtx4927 defconfig-rm200 
> 	                 defconfig-sb1250-swarm defconfig-sead 
> 	                 defconfig-tb0226 defconfig-tb0229 
> 	                 defconfig-ti1500 defconfig-workpad 
> 	                 defconfig-xxs1500 defconfig-yosemite 
> 	arch/mips64    : Tag: linux_2_4 defconfig-atlas 
> 	                 defconfig-decstation defconfig-ip22 
> 	                 defconfig-ip27 defconfig-jaguar defconfig-malta 
> 	                 defconfig-ocelotc defconfig-sb1250-swarm 
> 	                 defconfig-sead 
> 	drivers/net    : Tag: linux_2_4 Config.in 
> 
> Log message:
> 	Remove ~100 lines from the main 'config-shared.in' file to simplify the
> 	PCI configuration option. Update all config files to reflect the change
> 	as well as the stuff for kernel command line and Pb1550 *sigh*. Also
> 	fixed network config directives for 'make xconfig' breakages.
> 
> 

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Wed, Mar 03, 2004 at 03:43:05AM +0000, sjhill@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: signal.c 
> 
> Log message:
> 	Fix conditions to properly handle SA_ONSTACK for the 'sigaction' syscall
> 	when the stack to be switched to is invalid. All the other architectures
> 	do it properly except for MIPS...not anymore.

You missed half the other occurances.

  Ralf

Re: CVS Update@-mips.org: linux

[Christoph Hellwig]

On Sun, Feb 08, 2004 at 06:36:17AM -0800, William Lee Irwin III wrote:
> > Log message:
> > 	Use the defintion of kern_addr_valid() from Linus tree instead of my variant.
> > 	This allows blaming wli for this POS instead of me ;)
> 
> Hey! That bitmap was uninitialized (apart from being zeroed) in mainline.

I know.  The comment was reffering to replacing a

/* XXX(hch): better get rid of this thingy, it's rather fragile.. */

with an

/* XXX: FIXME -- wli */

Re: CVS Update@-mips.org: linux

[William Lee Irwin III]

On Sun, Feb 08, 2004 at 02:34:34PM +0000, hch@linux-mips.org wrote:
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	hch@ftp.linux-mips.org	04/02/08 14:34:34
> Modified files:
> 	include/asm-mips: mmzone.h 
> Log message:
> 	Use the defintion of kern_addr_valid() from Linus tree instead of my variant.
> 	This allows blaming wli for this POS instead of me ;)

Hey! That bitmap was uninitialized (apart from being zeroed) in mainline.


-- wli

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 3 Feb 2004, Ralf Baechle wrote:

> I don't know details but since the person who answered my question was
> directly working on the CPU design I have to take that as authoritative
> information and after all, the systems seems stable.

 OK then.

> Daring a guess, the CPU restarts the pipeline following an eret therefore
> instructions preceeding the eret can't cause the problem.

 That's possible.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Feb 03, 2004 at 04:30:33PM +0100, Maciej W. Rozycki wrote:

> > >  How do we assure tails of interrupt handlers don't trigger the errata?
> > 
> > The problem can only be triggered if instructions surrounding the
> > cacheop use the dcache; exceptions such as interrupts are not relevant.
> 
>  Why?  How is an "eret" with its preceding instructions different to other 
> instructions?  There may be a data cache miss soon before an "eret" and 
> the response buffer may contain data.  And you may get an exeption right 
> before a CACHE instruction.
>
> > Which I'm really happy about.  Disabling interrupts is a problem in cases
> > were we can't avoid page faults.
> 
>  I worry this is unsafe and given the unlikeliness of getting an interrupt
> just between the dummy load and the CACHE instruction, this change creates
> a completely obscure bug that'll bite unpredictably and possibly
> invisibly, just corrupting data, every once and then.  But the situation
> may be not that bad -- what does exactly happen when the erratum gets 
> triggered?  Missing a Create_Dirty_Excl_D operation should itself be a 
> performance hit only, but given the problems reported I suppose data gets 
> corrupted, either in the cache or in the main memory.  Am I right?

I don't know details but since the person who answered my question was
directly working on the CPU design I have to take that as authoritative
information and after all, the systems seems stable.

Daring a guess, the CPU restarts the pipeline following an eret therefore
instructions preceeding the eret can't cause the problem.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 2 Feb 2004, Ralf Baechle wrote:

> >  How do we assure tails of interrupt handlers don't trigger the errata?
> 
> The problem can only be triggered if instructions surrounding the
> cacheop use the dcache; exceptions such as interrupts are not relevant.

 Why?  How is an "eret" with its preceding instructions different to other 
instructions?  There may be a data cache miss soon before an "eret" and 
the response buffer may contain data.  And you may get an exeption right 
before a CACHE instruction.

> Which I'm really happy about.  Disabling interrupts is a problem in cases
> were we can't avoid page faults.

 I worry this is unsafe and given the unlikeliness of getting an interrupt
just between the dummy load and the CACHE instruction, this change creates
a completely obscure bug that'll bite unpredictably and possibly
invisibly, just corrupting data, every once and then.  But the situation
may be not that bad -- what does exactly happen when the erratum gets 
triggered?  Missing a Create_Dirty_Excl_D operation should itself be a 
performance hit only, but given the problems reported I suppose data gets 
corrupted, either in the cache or in the main memory.  Am I right?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Feb 02, 2004 at 04:13:28PM +0100, Maciej W. Rozycki wrote:

> > 	PMC-Sierra says that the workaround for errata #18 of the R4600 V1.7
> > 	and a similar erratum in V2.0 don't require disabling of interrupts,
> > 	so remove that code.
> 
>  How do we assure tails of interrupt handlers don't trigger the errata?

The problem can only be triggered if instructions surrounding the
cacheop use the dcache; exceptions such as interrupts are not relevant.

Which I'm really happy about.  Disabling interrupts is a problem in cases
were we can't avoid page faults.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 2 Feb 2004 ralf@linux-mips.org wrote:

> 	PMC-Sierra says that the workaround for errata #18 of the R4600 V1.7
> 	and a similar erratum in V2.0 don't require disabling of interrupts,
> 	so remove that code.

 How do we assure tails of interrupt handlers don't trigger the errata?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 23 Jan 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips64: Tag: linux_2_4 cpu.h 
> 
> Log message:
> 	Revert change *sigh*.

 But the advantage is now I know 2.6 needs to be fixed -- thanks.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 23 Jan 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips64: Tag: linux_2_4 cpu.h 

 The difference was deliberate.

> 	arch/mips64/kernel: Tag: linux_2_4 proc.c 

 You've downgraded ISO C initializers.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Jan 15, 2004 at 06:27:55AM +0000, ppopov@linux-mips.org wrote:

> Log message:
> 	Sync up latest 2.4 Au1x board files with 2.6. Not all drivers are
> 	synced up yet.

Excellent :-)

  Ralf

Re: CVS Update@-mips.org: linux

[Pete Popov]

Maciej W. Rozycki wrote:

>On Tue, 13 Jan 2004, Dan Aizenstros wrote:
>
>  
>
>>You broke any build that does not define CONFIG_SERIAL_AU1X00
>>by adding an #error in the include/asm-mips/serial.h file.
>>
>>-- Dan A.
>>
>>ppopov@linux-mips.org wrote:
>>
>>    
>>
>>>CVSROOT:	/home/cvs
>>>Module name:	linux
>>>Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22
>>>      
>>>
>
> Thanks for the report.  It looks like a typo.  I've removed the #error
>statement -- Pete please check if that's what's intended.
>  
>
Sorry, typo. Thanks for removing it.

Pete

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 13 Jan 2004, Dan Aizenstros wrote:

> You broke any build that does not define CONFIG_SERIAL_AU1X00
> by adding an #error in the include/asm-mips/serial.h file.
> 
> -- Dan A.
> 
> ppopov@linux-mips.org wrote:
> 
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22

 Thanks for the report.  It looks like a typo.  I've removed the #error
statement -- Pete please check if that's what's intended.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Dan Aizenstros]

Hello,

You broke any build that does not define CONFIG_SERIAL_AU1X00
by adding an #error in the include/asm-mips/serial.h file.

-- Dan A.

ppopov@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22
> 
> Modified files:
> 	arch/mips      : Kconfig Makefile 
> 	arch/mips/au1000/common: clocks.c dbg_io.c dma.c irq.c pci.c 
> 	                         power.c puts.c reset.c setup.c time.c 
> 	arch/mips/au1000/pb1500: board_setup.c irqmap.c 
> 	arch/mips/configs: pb1500_defconfig 
> 	drivers/net    : au1000_eth.c 
> 	drivers/serial : au1x00_uart.c 
> 	include/asm-mips: serial.h 
> Added files:
> 	include/asm-mips/mach-au1x00: au1000.h au1000_dma.h 
> 	                              au1000_gpio.h au1000_pcmcia.h 
> 	                              au1000_usbdev.h 
> 	include/asm-mips/mach-db1x00: db1x00.h 
> 	include/asm-mips/mach-pb1x00: pb1000.h pb1100.h pb1500.h 
> Removed files:
> 	include/asm-mips: au1000.h au1000_dma.h au1000_gpio.h 
> 	                  au1000_pcmcia.h au1000_usbdev.h db1x00.h 
> 	                  pb1000.h pb1100.h pb1500.h 
> 
> Log message:
> 	- moved .h files to appropriate include/asm-mips/mach-xxxx directories
> 	- fixed .c files to pick up new .h path name
> 	- fixed the serial console
> 
> 

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Mon, 2003-11-24 15:18:11 +0000, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20031124151816Z8225418-16706+435@linux-mips.org>:

> Log message:
> 	Merge with Linux "Stoned Beaver" 2.6.0-test10.
> 

Jehova!

Hiding, JBG

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

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

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 3 Nov 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: i8259.h
>
> Log message:
> 	Declare i8259A_lock spinlock.  New inline function i8259_irq to poll
> 	interrupts in a PC-style daisy-chained i8259 configuration where no
> 	better method to execute an interrupt acknowledge cycle is available.

 This is broken -- you do want to check bit #7 for spurious interrupts
instead of doing awkward PIC poking.  Alternatively, just skip the check
-- the condition is rare and handlers need to be able to deal with it
anyway.  It was discussed a few months ago and I proposed a correct patch
similar to your one, but it was rejected, sigh...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 3 Nov 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: i8259.h
>
> Log message:
> 	Declare i8259A_lock spinlock.  New inline function i8259_irq to poll
> 	interrupts in a PC-style daisy-chained i8259 configuration where no
> 	better method to execute an interrupt acknowledge cycle is available.

 This is broken -- you do want to check bit #7 for spurious interrupts
instead of doing awkward PIC poking.  Alternatively, just skip the check
-- the condition is rare and handlers need to be able to deal with it
anyway.  It was discussed a few months ago and I proposed a correct patch
similar to your one, but it was rejected, sigh...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 14 Oct 2003, Ralf Baechle wrote:

> Still want more?  A 3 level tree would then cover 128TB of virtual
> address space already exceedin the hardware limits of all processors but
> the R8000.

 Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
by an implementation, IIRC; probably nothing supports that much yet,
though. ;-)  BTW, is an R8000 spec available online anywhere?

> 64k pagesize stretches the limits even further.   Here a two level
> pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> the capacity of every MIPS processor ever made - and probably sufficient
> for the coming decade :-)

 Further increasing of the page size should result in better performance
due to fewer TLB misses and reduce the memory footprint of page tables,
but the drawback is more memory is wasted for maps.  Whether the end
result is a gain or a loss depends on the actual application of a system,
so I guess we should either leave the size configurable (with a sane
default for those who might have troubles judging what would suit them
best) or only decide on a given size after lots of benchmarking.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Oct 14, 2003 at 11:47:59AM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Config bits of support for TLB page sizes other than 4k.  So not
> > 	functional yet but this is a fairly large project and everybody should
> > 	finally get rid of the assumption that PAGE_SIZE is always 4k.
> 
>  I've already thought we might unconditionally switch to a larger page
> size, e.g. 16kB, for the 64-bit kernel -- I suppose everything that
> supports 64-bit operation also supports larger page sizes, doesn't it?

True.  At 16k pagesize we can also start harvesting other advantages, for
example we'd then know that cpu_has_dc_aliases is never true which will
make the compiler simply throw away large parts of the cache code.

As the result of living in an alias-free universe we could use the nice
recursive page fault technique from very old Linux kernels again,
something that allowed blindigly fast TLB refill handlers.

An additional bonus is the increased coverage of a pagetables with 16k
page size.  A 16k page has space for 2048 pointers.  So in case of a
two level pagetable tree that makes the total capacity 16k*2k*2k = 64GB.
So that means one level of the pagetable tree less than we currently
have, yet enough capacity for everything but the largest jobs.

Still want more?  A 3 level tree would then cover 128TB of virtual
address space already exceedin the hardware limits of all processors but
the R8000.

64k pagesize stretches the limits even further.   Here a two level
pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
the capacity of every MIPS processor ever made - and probably sufficient
for the coming decade :-)

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 10 Oct 2003, Kip Walker wrote:

> This doesn't compile.  Remove the commas.
> 
> Of course, "vt_check" doesn't build anymore either - I'm trying to fix
> that one.

 I can see you have dealt with the problems since.  Thanks.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Fri, Oct 10, 2003 at 12:03:53PM -0700, Kip Walker wrote:

> Curse the "Reply-To" from CVS commit messages.  This wasn't intended for
> the list.

The Reply-To was necessary because linux-cvs isn't a mailing list that
can be posted to, that is mail sent to it will bounce.

  Ralf

Re: CVS Update@-mips.org: linux

[Kip Walker]

Curse the "Reply-To" from CVS commit messages.  This wasn't intended for
the list.

sorry,
Kip

Kip Walker wrote:
> 
> This doesn't compile.  Remove the commas.
> 
> Of course, "vt_check" doesn't build anymore either - I'm trying to fix
> that one.
> 
> Kip
> 
> macro@linux-mips.org wrote:
> >
> > CVSROOT:        /home/cvs
> > Module name:    linux
> > Changes by:     macro@ftp.linux-mips.org        03/10/09 17:07:12
> >
> > Modified files:
> >         arch/mips/kernel: ioctl32.c
> >
> > Log message:
> >         PIO_FONTX and KDFONTOP ioctls.

Re: CVS Update@-mips.org: linux

[Kip Walker]

This doesn't compile.  Remove the commas.

Of course, "vt_check" doesn't build anymore either - I'm trying to fix
that one.

Kip

macro@linux-mips.org wrote:
> 
> CVSROOT:        /home/cvs
> Module name:    linux
> Changes by:     macro@ftp.linux-mips.org        03/10/09 17:07:12
> 
> Modified files:
>         arch/mips/kernel: ioctl32.c
> 
> Log message:
>         PIO_FONTX and KDFONTOP ioctls.

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Sep 09, 2003 at 03:40:44PM +0200, Maciej W. Rozycki wrote:

> > 	Avoid conflict with glibc on bigendian platforms when -O or higher
> > 	is specified.  It's already in 2.6, and I'm not sure why it hasn't
> > 	been seen in 2.4.  The symptom is that this program will not compile
> > 	with -O2:
> > 	
> > 	#include <asm/byteorder.h>
> > 	#include <netinet/in.h>
> > 	int main () { }
> 
>  Is <asm/byteorder.h> ever included by glibc headers?  I hope not and user
> programs *must* not include kernel headers.  Your program is buggy.

I'd not have accepted such a patch for exactly that reason if it wasn't
already in 2.6.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 9 Sep 2003 ralf@linux-mips.org wrote:

> 	Avoid conflict with glibc on bigendian platforms when -O or higher
> 	is specified.  It's already in 2.6, and I'm not sure why it hasn't
> 	been seen in 2.4.  The symptom is that this program will not compile
> 	with -O2:
> 	
> 	#include <asm/byteorder.h>
> 	#include <netinet/in.h>
> 	int main () { }

 Is <asm/byteorder.h> ever included by glibc headers?  I hope not and user
programs *must* not include kernel headers.  Your program is buggy.

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Aug 25, 2003 at 05:59:56PM +0100, kwalker@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	kwalker@ftp.linux-mips.org	03/08/25 17:59:56
> 
> Modified files:
> 	arch/mips/mm-64: init.c 
> 
> Log message:
> 	remove unnecessary HIGHMEM stuff from 64bit version

Stooop, highmem will soon be needed for 64-bit also to handle machines
that can't DMA to the entire memory.

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Wed, Jul 30, 2003 at 09:47:34AM +0200, Maciej W. Rozycki wrote:

> > > > It will flash up on your retina and stay there for a while, waiting
> > > > for your response, if you run `make oldconfig' :-)
> > > 
> > >  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> > > appeased...  Hopefully I won't get disappointed.
> > 
> > Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
> > evolution than revolution ...
> 
>  I'm referring to that menus that will flash up on my retina (if I got the
> meaning right). ;-)

Oh :-)

>  Anyway, it looks like some additional checks and possibly fixes will be
> needed for 64-bit configurations (including changes to my pending
> patches).  And last time I checked 2.5.x had showstopper problems for me
> elsewhere (IDE -- I still use it here and there) -- I doubt they have been
> fixed in the recent 2.6 -test releases. 

True, 2.6 isn't yet a great stability experience ...

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Wed, Jul 30, 2003 at 09:55:26AM +0200, Maciej W. Rozycki wrote:

> > >  I hope `uname -m' will continue to report the correct architecture and
> > > that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> > > and "mips64" a 64-bit one) -- have you considered this?
> > 
> > Not intend to change the behaviour of uname.  It actually changed in CVS,
> > for now consider that a bug ...
> 
>  OK, I will.

Fix is in CVS.

> > We should consider changing the behaviour though.  A machine type of
> > mips64 broke lots of software.  Of course that was all 32-bit softare but
> > it raises the question if returning mips64 is really a good idea?
> 
>  Yes it is.  It is the only way to check if the kernel is 32-bit or 64-bit
> and config.guess needs it for guessing the canonical system name.  That,
> plus checking the default ld emulation lets it (or will let, once written)
> select what is the proper default native configuration: 
> mips{,el}-unknown-linux-gnu, mips64{,el}-unknown-linux-gnu-abin32 or
> mips64{,el}-unknown-linux-gnu-abi64. 
> 
> > As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
> > be choosen like every other config option.
> 
>  Well, I liked the `make "ARCH=mips64"' way, but I suppose I'll have to
> live with your change, sigh... 

Well, that was one of the things that were handy at times.  Considering
the patch I sent to Linus yesterday to Linus did remove 41010 lines of code
that was a tiny price to pay.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Wed, 30 Jul 2003, Ralf Baechle wrote:

> >  I hope `uname -m' will continue to report the correct architecture and
> > that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> > and "mips64" a 64-bit one) -- have you considered this?
> 
> Not intend to change the behaviour of uname.  It actually changed in CVS,
> for now consider that a bug ...

 OK, I will.

> We should consider changing the behaviour though.  A machine type of
> mips64 broke lots of software.  Of course that was all 32-bit softare but
> it raises the question if returning mips64 is really a good idea?

 Yes it is.  It is the only way to check if the kernel is 32-bit or 64-bit
and config.guess needs it for guessing the canonical system name.  That,
plus checking the default ld emulation lets it (or will let, once written)
select what is the proper default native configuration: 
mips{,el}-unknown-linux-gnu, mips64{,el}-unknown-linux-gnu-abin32 or
mips64{,el}-unknown-linux-gnu-abi64. 

> As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
> be choosen like every other config option.

 Well, I liked the `make "ARCH=mips64"' way, but I suppose I'll have to
live with your change, sigh... 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Wed, 30 Jul 2003, Ralf Baechle wrote:

> On Wed, Jul 23, 2003 at 12:51:37AM +0200, Maciej W. Rozycki wrote:
> 
> > > >  Well, as long as one get that far to run a configuration script (BTW,
> > > > what menus are you referring to? -- I haven't seen any).  Right now that's
> > > 
> > > It will flash up on your retina and stay there for a while, waiting for your
> > > response, if you run `make oldconfig' :-)
> > 
> >  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> > appeased...  Hopefully I won't get disappointed.
> 
> Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
> evolution than revolution ...

 I'm referring to that menus that will flash up on my retina (if I got the
meaning right). ;-)

 Anyway, it looks like some additional checks and possibly fixes will be
needed for 64-bit configurations (including changes to my pending
patches).  And last time I checked 2.5.x had showstopper problems for me
elsewhere (IDE -- I still use it here and there) -- I doubt they have been
fixed in the recent 2.6 -test releases. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Jul 22, 2003 at 11:37:44PM +0200, Maciej W. Rozycki wrote:

> > Btw, an old experience repeats - some of the code was identical except
> > inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
> > I rewrote that stuff to use C for this arithmetic.  The result - less
> > inline assembler, more readable code and a file that's identical for
> > both 32-bit and 64-bit.
> 
>  Well, whatever is plain C code (or should be such) should be identical,
> indeed, but macros will differ as will low-level assembly.  Then add
> 64-bit specific options and you get yet more complication. 

You're right, we've got a good bit of assembler code that should just be
C.  So I rewrote some of the code to C.

>  I hope `uname -m' will continue to report the correct architecture and
> that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
> and "mips64" a 64-bit one) -- have you considered this?

Not intend to change the behaviour of uname.  It actually changed in CVS,
for now consider that a bug ...

We should consider changing the behaviour though.  A machine type of
mips64 broke lots of software.  Of course that was all 32-bit softare but
it raises the question if returning mips64 is really a good idea?

As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can
be choosen like every other config option.

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Wed, Jul 23, 2003 at 12:51:37AM +0200, Maciej W. Rozycki wrote:

> > >  Well, as long as one get that far to run a configuration script (BTW,
> > > what menus are you referring to? -- I haven't seen any).  Right now that's
> > 
> > It will flash up on your retina and stay there for a while, waiting for your
> > response, if you run `make oldconfig' :-)
> 
>  Hmm, now I have to speed up my transition to 2.6 to have my curiosity
> appeased...  Hopefully I won't get disappointed.

Well, 2.6 won't be the big leap that 2.4 was for most MIPS users, more
evolution than revolution ...

  Ralf

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Tue, 2003-07-29 13:09:21 +0100, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20030729120925Z8225214-1272+3844@linux-mips.org>:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/07/29 13:09:21
> 
> linux/drivers/media/dvb/ttusb-dec

Are DECstations now shipped with DVB receivers/decoders?

SCNR, JBG

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

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

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 22 Jul 2003, Geert Uytterhoeven wrote:

> >  Well, as long as one get that far to run a configuration script (BTW,
> > what menus are you referring to? -- I haven't seen any).  Right now that's
> 
> It will flash up on your retina and stay there for a while, waiting for your
> response, if you run `make oldconfig' :-)

 Hmm, now I have to speed up my transition to 2.6 to have my curiosity
appeased...  Hopefully I won't get disappointed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Tue, 22 Jul 2003, Maciej W. Rozycki wrote:
> On Tue, 22 Jul 2003, Ralf Baechle wrote:
> > I was thinking about that also.  arch/mips64 and include/asm-mips64 will
> > go away but on the other side there will be an option to configure a
> > 64-bit kernel in the menus - which will hopefully be more visible than
> > just two subdirectories.
> 
>  Well, as long as one get that far to run a configuration script (BTW,
> what menus are you referring to? -- I haven't seen any).  Right now that's

It will flash up on your retina and stay there for a while, waiting for your
response, if you run `make oldconfig' :-)

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: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Tue, 22 Jul 2003, Ralf Baechle wrote:

> And yes, the R6000 is different.  With that in mind R2000 and R4000 look
> like enzygotic twins ...

 ;-)

> > 2. A better visual existence of the 64-bit port; not really a technical
> > advantage, but more a psychological one.  It stops any newcomer wondering
> > whether we support 64-bit systems natively or not. 
> 
> I was thinking about that also.  arch/mips64 and include/asm-mips64 will
> go away but on the other side there will be an option to configure a
> 64-bit kernel in the menus - which will hopefully be more visible than
> just two subdirectories.

 Well, as long as one get that far to run a configuration script (BTW,
what menus are you referring to? -- I haven't seen any).  Right now that's
easily visible straight in the archive which is now even browsable in the
Internet here and there -- Q: "What architectures are supported?" A: "See
the subdirectories of arch/." 

> Btw, an old experience repeats - some of the code was identical except
> inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
> I rewrote that stuff to use C for this arithmetic.  The result - less
> inline assembler, more readable code and a file that's identical for
> both 32-bit and 64-bit.

 Well, whatever is plain C code (or should be such) should be identical,
indeed, but macros will differ as will low-level assembly.  Then add
64-bit specific options and you get yet more complication. 

 I hope `uname -m' will continue to report the correct architecture and
that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
and "mips64" a 64-bit one) -- have you considered this?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Jul 22, 2003 at 09:39:40PM +0200, Maciej W. Rozycki wrote:

> > sparc32 and sparc64 processors and systems are significantly
> > different.  For example, the SRMMU present in v8 CPUs is 100% replaced
> > with a totally different MMU (indeed, totally different instructions,
> > access methods, etc) in v9.  Accordingly there is very little code in
> > common between the two ports, and most of that is in device handling;
> > code that is in drivers/sbus and thus shared anyway.
> 
>  Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
> completely different from the one in later ones, too.  I suspect this is
> true for the R6k as well.  The exception handlers differ a bit as well,
> especially considering the XTLB refill one.  That probably counts as
> nitpicking, though... 

It's also a question of taste - and that one can be discussed forever.
How far do you want to factor our common code, as little as possible
which was our previous approach or extremly aggressive, glibc-like.

And yes, the R6000 is different.  With that in mind R2000 and R4000 look
like enzygotic twins ...

> > Something that made sense for sparc might not make sense for mips.
> 
>  Certainly it needs to be analysed on a case by case basis, avoiding
> blanket assumptions.  Anyway, I still see two reasons for having at least
> a separate top-level directory:
> 
> 1. A better separation of the more straightforward 32-bit Makefile and the
> more complicated 64-bit one.
> 
> 2. A better visual existence of the 64-bit port; not really a technical
> advantage, but more a psychological one.  It stops any newcomer wondering
> whether we support 64-bit systems natively or not. 

I was thinking about that also.  arch/mips64 and include/asm-mips64 will
go away but on the other side there will be an option to configure a
64-bit kernel in the menus - which will hopefully be more visible than
just two subdirectories.

>  There is also no point in having headers in asm-mips consisting of a
> single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
> versions should be present in asm-mips and asm-mips64, respectively.  It's
> easier to make a diff between such separate implementations to verify
> everything's OK. 

Like 80% of the headers could be identical between both files without
lots of trickery.  The current approach is have two physical copies of
these identical files.

Btw, an old experience repeats - some of the code was identical except
inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
I rewrote that stuff to use C for this arithmetic.  The result - less
inline assembler, more readable code and a file that's identical for
both 32-bit and 64-bit.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 21 Jul 2003, Ralf Baechle wrote:

> I even have some hope that with continuing cleanup mm-32 and mm-64, which
> are supposed to contain only things that due to conflicts can't live in
> mm, will finally become empty.

 If that's going to happen, a removal of arch/mips64/mm does make sense,
indeed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 21 Jul 2003, Keith M Wesolowski wrote:

> sparc32 and sparc64 processors and systems are significantly
> different.  For example, the SRMMU present in v8 CPUs is 100% replaced
> with a totally different MMU (indeed, totally different instructions,
> access methods, etc) in v9.  Accordingly there is very little code in
> common between the two ports, and most of that is in device handling;
> code that is in drivers/sbus and thus shared anyway.

 Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
completely different from the one in later ones, too.  I suspect this is
true for the R6k as well.  The exception handlers differ a bit as well,
especially considering the XTLB refill one.  That probably counts as
nitpicking, though... 

> Something that made sense for sparc might not make sense for mips.

 Certainly it needs to be analysed on a case by case basis, avoiding
blanket assumptions.  Anyway, I still see two reasons for having at least
a separate top-level directory:

1. A better separation of the more straightforward 32-bit Makefile and the
more complicated 64-bit one.

2. A better visual existence of the 64-bit port; not really a technical
advantage, but more a psychological one.  It stops any newcomer wondering
whether we support 64-bit systems natively or not. 

 There is also no point in having headers in asm-mips consisting of a
single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
versions should be present in asm-mips and asm-mips64, respectively.  It's
easier to make a diff between such separate implementations to verify
everything's OK. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Tue, 22 Jul 2003 ralf@linux-mips.org wrote:
> Modified files:
> 	arch/mips/mm   : Makefile c-sb1.c pg-r3k.c 
> 	arch/mips/mm-32: pg-r4k.S 
> 	arch/mips/mm-64: init.c 
> Added files:
> 	arch/mips/mm   : pgtable-32.c pgtable-64.c 

Euh, shouldn't these be in mm-32 and mm-64 then?

> Log message:
> 	Move pgd_init and pmd_init to their own files.

Gr{oetje,eeting}s,

						Geert, reading mail, not code

--
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: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Jul 21, 2003 at 05:50:08PM +0200, Maciej W. Rozycki wrote:

>  Well, duplication is certainly undesireable, but is it the result of
> separate arch/mips and arch/mips64 trees or is it a side effect only? 
> These separate trees have an advantage of a clear distinction between
> these architectures.  And arch/sparc vs arch/sparc64 were the first case
> of such a split and they seem to feel quite well. 
> 
>  I'd rather keep arch/mips/{lib,mm} and arch/mips64/{lib,mm} where they
> used to be and add, say, arch/mips/{lib,mm}-generic for common stuff. 

Technically these are probably equivalent.  I just felt having mm-32 and
mm-64 makes it more explicit that something can't be shared but really,
that's just directory names and I don't feel strong about them.
I even have some hope that with continuing cleanup mm-32 and mm-64, which
are supposed to contain only things that due to conflicts can't live in
mm, will finally become empty.

  Ralf

Re: CVS Update@-mips.org: linux

[Keith M Wesolowski]

On Mon, Jul 21, 2003 at 05:50:08PM +0200, Maciej W. Rozycki wrote:

>  Well, duplication is certainly undesireable, but is it the result of
> separate arch/mips and arch/mips64 trees or is it a side effect only? 
> These separate trees have an advantage of a clear distinction between
> these architectures.  And arch/sparc vs arch/sparc64 were the first case
> of such a split and they seem to feel quite well. 

sparc32 and sparc64 processors and systems are significantly
different.  For example, the SRMMU present in v8 CPUs is 100% replaced
with a totally different MMU (indeed, totally different instructions,
access methods, etc) in v9.  Accordingly there is very little code in
common between the two ports, and most of that is in device handling;
code that is in drivers/sbus and thus shared anyway.

Something that made sense for sparc might not make sense for mips.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 21 Jul 2003, Kevin D. Kissell wrote:

> >  Any justifiable reason for getting rid of arch/mips64?
> 
> In my opinion, it should never have existed.  The vast majority
> of MIPS-specific kernel code can be identical for 32-bit and 64-bit
> versions of the architecture.  Creating arch/mips64 (as opposed
> to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
> of modules that then needed to be maintained in parallel - but which 
> often were not.

 Well, duplication is certainly undesireable, but is it the result of
separate arch/mips and arch/mips64 trees or is it a side effect only? 
These separate trees have an advantage of a clear distinction between
these architectures.  And arch/sparc vs arch/sparc64 were the first case
of such a split and they seem to feel quite well. 

 I'd rather keep arch/mips/{lib,mm} and arch/mips64/{lib,mm} where they
used to be and add, say, arch/mips/{lib,mm}-generic for common stuff. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Jul 21, 2003 at 02:12:07PM +0200, Kevin D. Kissell wrote:

> >  Any justifiable reason for getting rid of arch/mips64?
> 
> In my opinion, it should never have existed.  The vast majority
> of MIPS-specific kernel code can be identical for 32-bit and 64-bit
> versions of the architecture.  Creating arch/mips64 (as opposed
> to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
> of modules that then needed to be maintained in parallel - but which 
> often were not.

In retroperspective it was a good think to start with and allowed us to
do some of the really intrusive change necessary without disturbing
the 32-bit stuff.  Now that things are settling down it's time to cleanup.

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Jul 21, 2003 at 12:49:55PM +0200, Maciej W. Rozycki wrote:

> > Log message:
> > 	Coarsly sort out 32-bit-only, 64-bit-only and ``portable'' MIPS memory
> > 	managment code.  Another few thousand lines of code bite the dust and
> > 	it could be even more ...
> 
>  Any justifiable reason for getting rid of arch/mips64?

Code duplication.  Thousands of lines.  I'm fedup of maintaining several
copies of a large number of files.  And stupid patches that keep forcing
things out of sync.  Multiply that pain with 2 for 2.4 and 2.6.  Not fun.

Btw, s390 also merged their two 32-bit and 64-bit architecture flavors
again; similar for parisc; it has been considered for x86-64 also.

  Ralf

Re: CVS Update@-mips.org: linux

[Kevin D. Kissell]

>  Any justifiable reason for getting rid of arch/mips64?

In my opinion, it should never have existed.  The vast majority
of MIPS-specific kernel code can be identical for 32-bit and 64-bit
versions of the architecture.  Creating arch/mips64 (as opposed
to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
of modules that then needed to be maintained in parallel - but which 
often were not.

Re: CVS Update@-mips.org: linux

[Kevin D. Kissell]

>  Any justifiable reason for getting rid of arch/mips64?

In my opinion, it should never have existed.  The vast majority
of MIPS-specific kernel code can be identical for 32-bit and 64-bit
versions of the architecture.  Creating arch/mips64 (as opposed
to arch/mips/mips64 or Ralf's arch/mips/mm-64) caused duplication 
of modules that then needed to be maintained in parallel - but which 
often were not.

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 21 Jul 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips      : Makefile 
> 	arch/mips/mm   : Makefile 
> 	arch/mips64    : Makefile 
> Added files:
> 	arch/mips/mm   : tlb-andes.c 
> 	arch/mips/mm-32: Makefile c-sb1.c c-tx39.c cex-gen.S fault.c 
> 	                 init.c pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips/mm-64: .cvsignore Makefile c-sb1.c fault.c init.c 
> 	                 pg-r4k.c pg-sb1.c tlb-dbg-r4k.c tlb-glue-r4k.S 
> 	                 tlb-glue-sb1.S tlb-r4k.c tlb-sb1.c tlbex-r4k.S 
> Removed files:
> 	arch/mips/mm   : c-sb1.c c-tx39.c cex-gen.S fault.c init.c 
> 	                 pg-r4k.S pg-sb1.c tlb-r4k.c tlb-sb1.c 
> 	                 tlbex-r4k.S 
> 	arch/mips64/mm : .cvsignore Makefile c-r4k.c c-sb1.c cache.c 
> 	                 cerr-sb1.c cex-sb1.S extable.c fault.c init.c 
> 	                 loadmmu.c pg-r4k.c pg-sb1.c pgtable.c sc-ip22.c 
> 	                 sc-r5k.c sc-rm7k.c tlb-andes.c tlb-dbg-r4k.c 
> 	                 tlb-glue-r4k.S tlb-glue-sb1.S tlb-r4k.c 
> 	                 tlb-sb1.c tlbex-r4k.S 
> 
> Log message:
> 	Coarsly sort out 32-bit-only, 64-bit-only and ``portable'' MIPS memory
> 	managment code.  Another few thousand lines of code bite the dust and
> 	it could be even more ...

 Any justifiable reason for getting rid of arch/mips64?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 27 Jun 2003, Kip Walker wrote:

> >  There's still missing a load delay slot filler there.  I'm checking in an
> > obvious fix immediately.
> 
> What about the other back-to-back loads in that file (9 lines above)? 

 Oops -- I've missed that one even though I've browsed through the file. 
Thanks for pointing it out. 

> My CPU doesn't care about the load delay slot, so I didn't think to add

 I hope you haven't realized of the problem rather than ignored it.  I
think the nops should eventually be replaced with macros that would
conditionally expand to nothing.  But correctness first and performance
later. 

> the nop.  At least my patch didn't introduce the problem ;-)

 But it let me notice it.  Better late than never. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Kip Walker]

"Maciej W. Rozycki" wrote:
> 
> On Fri, 27 Jun 2003 kwalker@linux-mips.org wrote:
> 
> > Modified files:
> >       arch/mips/lib  : memcpy.S
> >       arch/mips64/lib: memcpy.S
> >
> > Log message:
> >       fix bug in getting the thread's BUADDR in l_exc case
> 
>  There's still missing a load delay slot filler there.  I'm checking in an
> obvious fix immediately.

What about the other back-to-back loads in that file (9 lines above)? 
My CPU doesn't care about the load delay slot, so I didn't think to add
the nop.  At least my patch didn't introduce the problem ;-)

Kip

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 27 Jun 2003 kwalker@linux-mips.org wrote:

> Modified files:
> 	arch/mips/lib  : memcpy.S 
> 	arch/mips64/lib: memcpy.S 
> 
> Log message:
> 	fix bug in getting the thread's BUADDR in l_exc case

 There's still missing a load delay slot filler there.  I'm checking in an
obvious fix immediately.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Jun 24, 2003 at 10:51:05AM -0700, Pete Popov wrote:

> > > CVSROOT:	/home/cvs
> > > Module name:	linux
> > > Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> > > 
> > > Modified files:
> > > 	drivers/char   : Tag: linux_2_4 Makefile 
> > > 
> > > Log message:
> > > 	Added au1x00-serial.o to the exports list.
> > 
> > There doesn't seem to be a good reason to.  Only the register_serial and
> > unregister_serial are exported and they don't seem to be called from
> > anywhere outside.
> 
> Strange, the kernel wouldn't compile without this. I'll try locally to
> build it again and see what the problem is and if we can fix it without
> modifying the Makefile.

Of course it'll build once you remove the unnecessary symbol exports :-)

  Ralf

Re: CVS Update@-mips.org: linux

[Pete Popov]

On Tue, 2003-06-24 at 02:31, Ralf Baechle wrote:
> On Tue, Jun 24, 2003 at 04:39:11AM +0100, ppopov@linux-mips.org wrote:
> 
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> > 
> > Modified files:
> > 	drivers/char   : Tag: linux_2_4 Makefile 
> > 
> > Log message:
> > 	Added au1x00-serial.o to the exports list.
> 
> There doesn't seem to be a good reason to.  Only the register_serial and
> unregister_serial are exported and they don't seem to be called from
> anywhere outside.

Strange, the kernel wouldn't compile without this. I'll try locally to
build it again and see what the problem is and if we can fix it without
modifying the Makefile.

Pete

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Tue, Jun 24, 2003 at 04:39:11AM +0100, ppopov@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ppopov@ftp.linux-mips.org	03/06/24 04:39:11
> 
> Modified files:
> 	drivers/char   : Tag: linux_2_4 Makefile 
> 
> Log message:
> 	Added au1x00-serial.o to the exports list.

There doesn't seem to be a good reason to.  Only the register_serial and
unregister_serial are exported and they don't seem to be called from
anywhere outside.

  Ralf

Re: CVS Update@-mips.org: linux

[Atsushi Nemoto]

>>>>> On Mon, 16 Jun 2003 10:42:24 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Mon, 16 Jun 2003 10:19:11 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
>>> Modified files:
>>> arch/mips64    : Tag: linux_2_4 Makefile 
>>> include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

>>> Log message:
>>> Support GT64120 boards with 64-bit kernels also.

nemoto> This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.

nemoto> And I doubt that 'unsigned short' is enough for the 'waysize'
nemoto> (especially for scache).  How about this?

Then this is a patch to sync 32-bit version.

diff -ur linux-mips-cvs/arch/mips/mm/c-r4k.c linux.new/arch/mips/mm/c-r4k.c
--- linux-mips-cvs/arch/mips/mm/c-r4k.c	Mon Apr 28 09:44:52 2003
+++ linux.new/arch/mips/mm/c-r4k.c	Mon Jun 16 10:43:21 2003
@@ -26,7 +26,6 @@
 
 /* Primary cache parameters. */
 static unsigned long icache_size, dcache_size, scache_size;
-unsigned long icache_way_size, dcache_way_size, scache_way_size;
 static unsigned long scache_size;
 
 #include <asm/cacheops.h>
@@ -848,8 +847,8 @@
 		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
-	icache_way_size = icache_size / c->icache.ways;
-	dcache_way_size = dcache_size / c->dcache.ways;
+	c->icache.waysize = icache_size / c->icache.ways;
+	c->dcache.waysize = dcache_size / c->dcache.ways;
 
 	c->icache.sets = icache_size / (c->icache.linesz * c->icache.ways);
 	c->dcache.sets = dcache_size / (c->dcache.linesz * c->dcache.ways);
@@ -862,7 +861,7 @@
 	 */
 	if (current_cpu_data.cputype != CPU_R10000 &&
 	    current_cpu_data.cputype != CPU_R12000)
-		if (dcache_way_size > PAGE_SIZE)
+		if (c->dcache.waysize > PAGE_SIZE)
 		        c->dcache.flags |= MIPS_CACHE_ALIASES;
 
 	if (config & 0x8)		/* VI bit */
diff -ur linux-mips-cvs/arch/mips/mm/c-tx39.c linux.new/arch/mips/mm/c-tx39.c
--- linux-mips-cvs/arch/mips/mm/c-tx39.c	Tue May  6 09:40:58 2003
+++ linux.new/arch/mips/mm/c-tx39.c	Mon Jun 16 10:46:54 2003
@@ -25,9 +25,7 @@
 
 /* For R3000 cores with R4000 style caches */
 static unsigned long icache_size, dcache_size;		/* Size in bytes */
-static unsigned long icache_way_size, dcache_way_size;	/* Size divided by ways */
 #define scache_size 0
-#define scache_way_size 0
 
 #include <asm/r4kcache.h>
 
@@ -473,15 +471,15 @@
 		break;
 	}
 
-	icache_way_size = icache_size / current_cpu_data.icache.ways;
-	dcache_way_size = dcache_size / current_cpu_data.dcache.ways;
+	current_cpu_data.icache.waysize = icache_size / current_cpu_data.icache.ways;
+	current_cpu_data.dcache.waysize = dcache_size / current_cpu_data.dcache.ways;
 
 	current_cpu_data.icache.sets =
-		icache_way_size / current_cpu_data.icache.linesz;
+		current_cpu_data.icache.waysize / current_cpu_data.icache.linesz;
 	current_cpu_data.dcache.sets =
-		dcache_way_size / current_cpu_data.dcache.linesz;
+		current_cpu_data.dcache.waysize / current_cpu_data.dcache.linesz;
 
-	if (dcache_way_size > PAGE_SIZE)
+	if (current_cpu_data.dcache.waysize > PAGE_SIZE)
 		current_cpu_data.dcache.flags |= MIPS_CACHE_ALIASES;
 
 	current_cpu_data.icache.waybit = 0;
diff -ur linux-mips-cvs/arch/mips/mm/sc-rm7k.c linux.new/arch/mips/mm/sc-rm7k.c
--- linux-mips-cvs/arch/mips/mm/sc-rm7k.c	Fri Apr 18 10:23:03 2003
+++ linux.new/arch/mips/mm/sc-rm7k.c	Mon Jun 16 10:44:02 2003
@@ -20,8 +20,6 @@
 /* Secondary cache parameters. */
 #define scache_size	(256*1024)	/* Fixed to 256KiB on RM7000 */
 
-extern unsigned long icache_way_size, dcache_way_size;
-
 #include <asm/r4kcache.h>
 
 int rm7k_tcache_enabled;
diff -ur linux-mips-cvs/include/asm-mips/processor.h linux.new/include/asm-mips/processor.h
--- linux-mips-cvs/include/asm-mips/processor.h	Thu May  8 10:28:23 2003
+++ linux.new/include/asm-mips/processor.h	Mon Jun 16 10:43:04 2003
@@ -34,11 +34,12 @@
  * Descriptor for a cache
  */
 struct cache_desc {
-	unsigned short linesz;
-	unsigned short ways;
-	unsigned int sets;
-	unsigned int waybit;	/* Bits to select in a cache set */
-	unsigned int flags;	/* Flags describingcache properties */
+	unsigned short linesz;	/* Size of line in bytes */
+	unsigned short ways;	/* Number of ways */
+	unsigned short sets;	/* Number of lines per set */
+	unsigned short waybit;	/* Bits to select in a cache set */
+	unsigned int waysize;	/* Bytes per way */
+	unsigned int flags;	/* Flags describing cache properties */
 };
 
 /*
diff -ur linux-mips-cvs/include/asm-mips/r4kcache.h linux.new/include/asm-mips/r4kcache.h
--- linux-mips-cvs/include/asm-mips/r4kcache.h	Mon Apr 28 09:44:57 2003
+++ linux.new/include/asm-mips/r4kcache.h	Mon Jun 16 10:42:51 2003
@@ -140,7 +140,7 @@
 static inline void blast_dcache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + dcache_way_size;
+	unsigned long end = start + current_cpu_data.dcache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.dcache.waybit;
 	unsigned long ws_end = current_cpu_data.dcache.ways << 
 	                       current_cpu_data.dcache.waybit;
@@ -179,7 +179,7 @@
 static inline void blast_icache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -218,7 +218,7 @@
 static inline void blast_scache16(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -283,7 +283,7 @@
 static inline void blast_dcache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + dcache_way_size;
+	unsigned long end = start + current_cpu_data.dcache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.dcache.waybit;
 	unsigned long ws_end = current_cpu_data.dcache.ways <<
 	                       current_cpu_data.dcache.waybit;
@@ -322,7 +322,7 @@
 static inline void blast_icache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -361,7 +361,7 @@
 static inline void blast_scache32(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -426,7 +426,7 @@
 static inline void blast_icache64(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + icache_way_size;
+	unsigned long end = start + current_cpu_data.icache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.icache.waybit;
 	unsigned long ws_end = current_cpu_data.icache.ways <<
 	                       current_cpu_data.icache.waybit;
@@ -465,7 +465,7 @@
 static inline void blast_scache64(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
@@ -530,7 +530,7 @@
 static inline void blast_scache128(void)
 {
 	unsigned long start = KSEG0;
-	unsigned long end = start + scache_way_size;
+	unsigned long end = start + current_cpu_data.scache.waysize;
 	unsigned long ws_inc = 1UL << current_cpu_data.scache.waybit;
 	unsigned long ws_end = current_cpu_data.scache.ways << 
 	                       current_cpu_data.scache.waybit;
---
Atsushi Nemoto

Re: CVS Update@-mips.org: linux

[Atsushi Nemoto]

>>>>> On Mon, 16 Jun 2003 10:19:11 +0900 (JST), Atsushi Nemoto <nemoto@toshiba-tops.co.jp> said:
>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
>> Modified files:
>> arch/mips64    : Tag: linux_2_4 Makefile 
>> include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

>> Log message:
>> Support GT64120 boards with 64-bit kernels also.

nemoto> This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.

And I doubt that 'unsigned short' is enough for the 'waysize'
(especially for scache).  How about this?

diff -u linux-mips-cvs/include/asm-mips64/processor.h linux.new/include/asm-mips64/processor.h
--- linux-mips-cvs/include/asm-mips64/processor.h	Mon Jun 16 09:33:42 2003
+++ linux.new/include/asm-mips64/processor.h	Mon Jun 16 10:40:19 2003
@@ -50,8 +50,8 @@
 	unsigned short linesz;	/* Size of line in bytes */
 	unsigned short ways;	/* Number of ways */
 	unsigned short sets;	/* Number of lines per set */
-	unsigned short waysize;	/* Bytes per way */
-	unsigned int waybit;	/* Bits to select in a cache set */
+	unsigned short waybit;	/* Bits to select in a cache set */
+	unsigned int waysize;	/* Bytes per way */
 	unsigned int flags;	/* Flags describing cache properties */
 };
 
---
Atsushi Nemoto

Re: CVS Update@-mips.org: linux

[Atsushi Nemoto]

>>>>> On Sun, 15 Jun 2003 01:47:13 +0100, ralf@linux-mips.org said:
> Modified files:
> 	arch/mips64    : Tag: linux_2_4 Makefile 
> 	include/asm-mips64: Tag: linux_2_4 processor.h r4kcache.h 

> Log message:
> 	Support GT64120 boards with 64-bit kernels also.

This corrupts mips64/mm/c-r4k.c.  Please apply this patch also.


diff -u linux-mips-cvs/arch/mips64/mm/c-r4k.c linux.new/arch/mips64/mm/c-r4k.c
--- linux-mips-cvs/arch/mips64/mm/c-r4k.c	Mon Apr 28 09:44:53 2003
+++ linux.new/arch/mips64/mm/c-r4k.c	Mon Jun 16 09:59:38 2003
@@ -26,7 +26,6 @@
 
 /* Primary cache parameters. */
 static unsigned long icache_size, dcache_size, scache_size;
-unsigned long icache_way_size, dcache_way_size, scache_way_size;
 static unsigned long scache_size;
 
 #include <asm/cacheops.h>
@@ -848,8 +847,8 @@
 		panic("Improper R4000SC processor configuration detected");
 
 	/* compute a couple of other cache variables */
-	icache_way_size = icache_size / c->icache.ways;
-	dcache_way_size = dcache_size / c->dcache.ways;
+	c->icache.waysize = icache_size / c->icache.ways;
+	c->dcache.waysize = dcache_size / c->dcache.ways;
 
 	c->icache.sets = icache_size / (c->icache.linesz * c->icache.ways);
 	c->dcache.sets = dcache_size / (c->dcache.linesz * c->dcache.ways);
@@ -862,7 +861,7 @@
 	 */
 	if (current_cpu_data.cputype != CPU_R10000 &&
 	    current_cpu_data.cputype != CPU_R12000)
-		if (dcache_way_size > PAGE_SIZE)
+		if (c->dcache.waysize > PAGE_SIZE)
 		        c->dcache.flags |= MIPS_CACHE_ALIASES;
 
 	if (config & 0x8)		/* VI bit */
diff -u linux-mips-cvs/arch/mips64/mm/sc-rm7k.c linux.new/arch/mips64/mm/sc-rm7k.c
--- linux-mips-cvs/arch/mips64/mm/sc-rm7k.c	Fri Apr 18 10:23:12 2003
+++ linux.new/arch/mips64/mm/sc-rm7k.c	Mon Jun 16 09:59:59 2003
@@ -20,8 +20,6 @@
 /* Secondary cache parameters. */
 #define scache_size	(256*1024)	/* Fixed to 256KiB on RM7000 */
 
-extern unsigned long icache_way_size, dcache_way_size;
-
 #include <asm/r4kcache.h>
 
 int rm7k_tcache_enabled;
---
Atsushi Nemoto

Re: CVS Update@-mips.org: linux

[ilya]

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

I think in 2.5 serial drivers should leave in drivers/serial
	Ilya.

On Sun, Jun 15, 2003 at 02:57:08PM +0100, ralf@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/06/15 14:57:08
> 
> Modified files:
> 	drivers/char   : Makefile 
> 	arch/mips/au1000/common: Makefile 
> Added files:
> 	drivers/char   : au1x00-serial.c 
> Removed files:
> 	arch/mips/au1000/common: serial.c 
> 
> Log message:
> 	Drivers have some place where they're supposed to life damn...
> 
> 

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

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sat, 14 Jun 2003, Ralf Baechle wrote:

> > We can use some scheme like Geert was proposing, i.e., named after
> > boards and chipsets.  Hack, I think even naming after board vendor
> > is acceptable.
> 
> Chipsets are a too coarse granularity to structure things these days.
> Modern chipsets integrate a large number of logically independant
> functionality.  Frequently such chipsets are ASICs which consist of
> various logically independant functions licensed from several sources
> and possibly multiple chipset / ASICs are being used in a single
> system.  The world just isn't that simple ...

 What's the deal?  E.g. for a PCI chip we can have a separate file for
each function.  And anything that is not related to a system's core, i.e. 
a peripheral device, belongs to drivers/whatever anyway.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 13 Jun 2003, Dan Malek wrote:

> >   arch/mips/platforms/platform1/...
> >                      /platform2/...
> 
>  From my experience with other architectures, fewer intermediate
> directories are often useful, for example:
> 
> 	arch/mips/platforms/board_and_chip_files
> 
> allows a maximum amount of code sharing and minimal duplication.

 What prevents one from sharing code from different directories?

> When you have lots of lower level directories, you often have
> many identical files in them that should be shared, but are not,
> causing support/update challenges.  For example:
> 
> 	arch/mips/platforms/mfg_board_common.[ch]
> 	arch/mips/platforms/mfg_board_type1.[ch]
> 	arch/mips/platforms/mfg_board_type2.[ch]
> 
> keeps all manufacturer shared code in one place, and the board
> files could be quite small.  I have the specific case right now
> with a board vendor that has about six similar boards, all in
> separate directories like this:
> 
> 	arch/mips/au1000/board1/file.c
> 	arch/mips/au1000/board2/file.c
> 	arch/mips/au1000/board3/file.c
> 
> where the code is all identical in those files.  My first move is

 IMO file.c should me moved up one level or to arch/mips/au1000/lib.

> going to be consolidation of all of the "board" directories into a
> single "manufacturer" directory just to eliminate the overhead of
> keeping all of these files consistent on updates.  Then, I'm just
> going to prefix the board type to the unique file names.  I find
> this much easier to maintain and to share code.  Common sense
> file names using a standard manufacturer/board name prefix makes
> the files just as easy to identify as separate directories.

 Identification is not a problem.  Logical separation is.  Directories
were invented for a reason.

> It would be nice to see the defconfig files in their own directory,
> that would be the single most useful way to eliminate some clutter :-)

 It sounds reasonable.  The generic defconfig of course has to be left
where it is now.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Fri, Jun 13, 2003 at 02:44:25PM -0700, Jun Sun wrote:

> Congradualtions!  You will have roughly about 950 files under that
> directory.
> 
> Even with good effort to combine files and promote sharing, I think
> you will still have quite some.
> 
> I think having another directory layer under arch/mips/platforms
> shouldn't be too bad, (although I like arch/mips/machines better).  
> 
> We can use some scheme like Geert was proposing, i.e., named after
> boards and chipsets.  Hack, I think even naming after board vendor
> is acceptable.

Chipsets are a too coarse granularity to structure things these days.
Modern chipsets integrate a large number of logically independant
functionality.  Frequently such chipsets are ASICs which consist of
various logically independant functions licensed from several sources
and possibly multiple chipset / ASICs are being used in a single
system.  The world just isn't that simple ...

  Ralf

Re: CVS Update@-mips.org: linux

[Jun Sun]

On Fri, Jun 13, 2003 at 10:28:03PM +0200, Maciej W. Rozycki wrote:
> On Fri, 13 Jun 2003, Geert Uytterhoeven wrote:
> 
> > So in the future we may see something like this:
> > 
> >   arch/mips/chipset1/...
> >            /chipset2/...
> > 	   /...
> > 	   /board1/...
> > 	   /board2/...
> > 
> > where the board* directories contain the glue code for the specific boards?
> 
>  It looks as a good idea, although possibly an intermediate directory
> would be desireable not to clutter arch/mips too much.  E.g:
> 
>   arch/mips/platforms/platform1/...
>                      /platform2/...
>             ...
>   arch/mips/chipset/chipset1/...
>                    /chipset2/...
> 
> I assume by "chipset" you mean the lone system controller or host bridge. 
>

I agree.

Jun

Re: CVS Update@-mips.org: linux

[Jun Sun]

On Fri, Jun 13, 2003 at 05:00:12PM -0400, Dan Malek wrote:
> Maciej W. Rozycki wrote:
> 
> >  It looks as a good idea, although possibly an intermediate directory
> > would be desireable not to clutter arch/mips too much.  E.g:
> > 
> >   arch/mips/platforms/platform1/...
> >                      /platform2/...
> 
>  From my experience with other architectures, fewer intermediate
> directories are often useful, for example:
> 
> 	arch/mips/platforms/board_and_chip_files
> 
> allows a maximum amount of code sharing and minimal duplication.
> When you have lots of lower level directories, you often have
> many identical files in them that should be shared, but are not,
> causing support/update challenges.  For example:
> 
> 	arch/mips/platforms/mfg_board_common.[ch]
> 	arch/mips/platforms/mfg_board_type1.[ch]
> 	arch/mips/platforms/mfg_board_type2.[ch]
>

Congradualtions!  You will have roughly about 950 files under that
directory.

Even with good effort to combine files and promote sharing, I think
you will still have quite some.

I think having another directory layer under arch/mips/platforms
shouldn't be too bad, (although I like arch/mips/machines better).  

We can use some scheme like Geert was proposing, i.e., named after
boards and chipsets.  Hack, I think even naming after board vendor
is acceptable.


> It would be nice to see the defconfig files in their own directory,
> that would be the single most useful way to eliminate some clutter :-)
>

I second on this.

Jun

Re: CVS Update@-mips.org: linux

[Dan Malek]

Maciej W. Rozycki wrote:

>  It looks as a good idea, although possibly an intermediate directory
> would be desireable not to clutter arch/mips too much.  E.g:
> 
>   arch/mips/platforms/platform1/...
>                      /platform2/...

 From my experience with other architectures, fewer intermediate
directories are often useful, for example:

	arch/mips/platforms/board_and_chip_files

allows a maximum amount of code sharing and minimal duplication.
When you have lots of lower level directories, you often have
many identical files in them that should be shared, but are not,
causing support/update challenges.  For example:

	arch/mips/platforms/mfg_board_common.[ch]
	arch/mips/platforms/mfg_board_type1.[ch]
	arch/mips/platforms/mfg_board_type2.[ch]

keeps all manufacturer shared code in one place, and the board
files could be quite small.  I have the specific case right now
with a board vendor that has about six similar boards, all in
separate directories like this:

	arch/mips/au1000/board1/file.c
	arch/mips/au1000/board2/file.c
	arch/mips/au1000/board3/file.c

where the code is all identical in those files.  My first move is
going to be consolidation of all of the "board" directories into a
single "manufacturer" directory just to eliminate the overhead of
keeping all of these files consistent on updates.  Then, I'm just
going to prefix the board type to the unique file names.  I find
this much easier to maintain and to share code.  Common sense
file names using a standard manufacturer/board name prefix makes
the files just as easy to identify as separate directories.

It would be nice to see the defconfig files in their own directory,
that would be the single most useful way to eliminate some clutter :-)

Thanks.


	-- Dan

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 13 Jun 2003, Geert Uytterhoeven wrote:

> So in the future we may see something like this:
> 
>   arch/mips/chipset1/...
>            /chipset2/...
> 	   /...
> 	   /board1/...
> 	   /board2/...
> 
> where the board* directories contain the glue code for the specific boards?

 It looks as a good idea, although possibly an intermediate directory
would be desireable not to clutter arch/mips too much.  E.g:

  arch/mips/platforms/platform1/...
                     /platform2/...
            ...
  arch/mips/chipset/chipset1/...
                   /chipset2/...

I assume by "chipset" you mean the lone system controller or host bridge. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Fri, 13 Jun 2003, Jun Sun wrote:
> On Fri, Jun 13, 2003 at 04:30:49PM +0200, Ralf Baechle wrote:
> > On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:
> > > Is this really a good idea? You moved board-specific code (`everything related
> > > to one board in a single dir') into one directory? So for a new port, you now
> > > have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> > > 
> > > I agree that extracting common parts and cleaning up the code is a good idea,
> > > though.
> > 
> > It's just toooo much to do in one step, expect forther moving of code
> > to get everything to it's final place.  The amount of code that was
> > being duplicated was just insane and trying to sort boards by chipset
> > was part of the evil.  So MIPS's boards may come with one of several
> > PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
> > Galileo 64120 chipset.  Result?  Each was duplicating the code to support
> > both chipsets into it's arch/mips/foo/ code.  Similar things with code
> > to support various firmware such as PMON etc.
> > 
> > Anyway, suggestions welcome,
> 
> Ralf and I chatted a little before the change.  I think this _may_ be
> a good thing.  It does not hurt to give it whirl first.
> 
> I was trying to promote chipset based grouping, like gt64120/ or ddb5xxx/, 
> but apparently not everybody likes that.  People are still going with 
> company or machine based grouping, which makes chipset code sharing impossible.
> 
> I also realize that chipset based grouping (and sharing) requires more
> design and synchronization between developers, and thus probably harder
> to do.  So in that sense, arch/mips/pci, as a less restrictive mechnism
> for sharing, might work better.
> 
> So I like to view arch/mips/pci as some PCI library routines for 
> chipsets instead of another place for board-specific code to live.

That's fine!  I just didn't realize there was that much chipset sharing between
the different boards. E.g. for Vr41xx, all board code is already in subdirs
within the vr41xx directory.

So in the future we may see something like this:

  arch/mips/chipset1/...
           /chipset2/...
	   /...
	   /board1/...
	   /board2/...

where the board* directories contain the glue code for the specific boards?

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: CVS Update@-mips.org: linux

[Jun Sun]

On Fri, Jun 13, 2003 at 04:30:49PM +0200, Ralf Baechle wrote:
> On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:
> 
> > Is this really a good idea? You moved board-specific code (`everything related
> > to one board in a single dir') into one directory? So for a new port, you now
> > have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> > 
> > I agree that extracting common parts and cleaning up the code is a good idea,
> > though.
> 
> It's just toooo much to do in one step, expect forther moving of code
> to get everything to it's final place.  The amount of code that was
> being duplicated was just insane and trying to sort boards by chipset
> was part of the evil.  So MIPS's boards may come with one of several
> PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
> Galileo 64120 chipset.  Result?  Each was duplicating the code to support
> both chipsets into it's arch/mips/foo/ code.  Similar things with code
> to support various firmware such as PMON etc.
> 
> Anyway, suggestions welcome,
>

Ralf and I chatted a little before the change.  I think this _may_ be
a good thing.  It does not hurt to give it whirl first.

I was trying to promote chipset based grouping, like gt64120/ or ddb5xxx/, 
but apparently not everybody likes that.  People are still going with 
company or machine based grouping, which makes chipset code sharing impossible.

I also realize that chipset based grouping (and sharing) requires more
design and synchronization between developers, and thus probably harder
to do.  So in that sense, arch/mips/pci, as a less restrictive mechnism
for sharing, might work better.

So I like to view arch/mips/pci as some PCI library routines for 
chipsets instead of another place for board-specific code to live.

Jun

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Fri, Jun 13, 2003 at 04:19:46PM +0200, Geert Uytterhoeven wrote:

> Is this really a good idea? You moved board-specific code (`everything related
> to one board in a single dir') into one directory? So for a new port, you now
> have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.
> 
> I agree that extracting common parts and cleaning up the code is a good idea,
> though.

It's just toooo much to do in one step, expect forther moving of code
to get everything to it's final place.  The amount of code that was
being duplicated was just insane and trying to sort boards by chipset
was part of the evil.  So MIPS's boards may come with one of several
PCI chipsets and the Lasat systems may have either a NEC Nile4 or a
Galileo 64120 chipset.  Result?  Each was duplicating the code to support
both chipsets into it's arch/mips/foo/ code.  Similar things with code
to support various firmware such as PMON etc.

Anyway, suggestions welcome,

  Ralf

Re: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Fri, 13 Jun 2003 ralf@linux-mips.org wrote:
> 	Consolidate all the MIPS PCI code in arch/mips/pci.

Is this really a good idea? You moved board-specific code (`everything related
to one board in a single dir') into one directory? So for a new port, you now
have to add a arch/mips/<board>/ directory, and add files to arch/mips/pci/.

I agree that extracting common parts and cleaning up the code is a good idea,
though.

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: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Mon, 9 Jun 2003, Maciej W. Rozycki wrote:
> On Thu, 5 Jun 2003 ralf@linux-mips.org wrote:
> > Log message:
> > 	Merge with Linux 2.5.70.
> 
>  Others have been faster, but anyway: congratulations and thanks a lot for

Indeed, congratulations!

> your hard work. 

And now comes an even harder part: feeding back upstream... ;-)

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: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 5 Jun 2003 ralf@linux-mips.org wrote:

> Log message:
> 	Merge with Linux 2.5.70.

 Others have been faster, but anyway: congratulations and thanks a lot for
your hard work. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Jun 05, 2003 at 09:45:16PM +0200, Jan-Benedict Glaw wrote:

> While talking to a coworker today, I called that harakiri merging. You
> did a great job, Ralf! Do you want to get inter-BKxx patches from me or
> do you prefer to only import evenly versioned Linus patches?

In general I try to keep the merging overhead low by not following all
the -bk releases.

  Ralf

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Thu, 2003-06-05 20:42:23 +0200, Guido Guenther <agx@sigxcpu.org>
wrote in message <20030605184223.GB29450@bogon.ms20.nix>:
> On Thu, Jun 05, 2003 at 07:24:15PM +0100, ralf@linux-mips.org wrote:
> > 	Merge with Linux 2.5.70.
> Ralf - Merge-o-mat - Bächle, you make my day!

Seconding that:)

While talking to a coworker today, I called that harakiri merging. You
did a great job, Ralf! Do you want to get inter-BKxx patches from me or
do you prefer to only import evenly versioned Linus patches?

MfG, JBG

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

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

Re: CVS Update@-mips.org: linux

[Guido Guenther]

On Thu, Jun 05, 2003 at 07:24:15PM +0100, ralf@linux-mips.org wrote:
> 	Merge with Linux 2.5.70.
Ralf - Merge-o-mat - Bächle, you make my day!
 -- Guido

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Sun, 2003-06-01 17:56:29 +0200, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20030601155629.GA26900@linux-mips.org>:
> On Sun, Jun 01, 2003 at 04:25:53PM +0200, Jan-Benedict Glaw wrote:
> 
> > MfG, JBG
> > PS: Thinking about feeding arch with Linus' tree, the parisc one and
> > l-m.org's CVS tree just to evaluate if the holy merge can be done at all
> > (cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).
> 
> Please don't feed anything that's maintained on linux-mips.org to Linus.
> Having to sort out what of all the patches flowing forward and backward
> is bogus and not would become a huge pain for me.

I do know that and I'm for sure far away from pushing patches upwards.
_But_ I want to pull things. This way, I can *early* unhide problems
some archs imply to common code and thus I can ask their maintainers to
not let major (upcoming) problems out of their eyes...

> > Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
> > plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
> > which gets complete log incl. patch sent to.
> 
> An item on my to do list since a long time ...

Here's even some requestor! That'd help me a lot, I think.

Ralf, you've been a fire fighter, right? I'm near over-heating just
right now...

MfG, JBG

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

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

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sun, Jun 01, 2003 at 04:25:53PM +0200, Jan-Benedict Glaw wrote:

> MfG, JBG
> PS: Thinking about feeding arch with Linus' tree, the parisc one and
> l-m.org's CVS tree just to evaluate if the holy merge can be done at all
> (cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).

Please don't feed anything that's maintained on linux-mips.org to Linus.
Having to sort out what of all the patches flowing forward and backward
is bogus and not would become a huge pain for me.

> Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
> plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
> which gets complete log incl. patch sent to.

An item on my to do list since a long time ...

  Ralf

Re: CVS Update@-mips.org: linux

[Jan-Benedict Glaw]

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

On Sun, 2003-06-01 13:07:46 +0100, ralf@linux-mips.org <ralf@linux-mips.org>
wrote in message <20030601120750Z8225197-1272+2136@linux-mips.org>:

> Log message:
> 	Merge with Linux 2.5.50.

Today's hero: Bacchus!

MfG, JBG
PS: Thinking about feeding arch with Linus' tree, the parisc one and
l-m.org's CVS tree just to evaluate if the holy merge can be done at all
(cf. http://www.lug-owl.de/~jbglaw/linux-ports/ ).

Currently, I'm thinking about a 2.5.<x>-port<n> tree which I basically
plan to feed by CVS/bk/... log mails. While at it, I'm asking for a list
which gets complete log incl. patch sent to.

Bacchus?

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

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

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sat, 17 May 2003, Thiemo Seufer wrote:

> > Log message:
> > 	Remove egcs 1.1.2 workarounds from 32-bit compat code.
> 
> Ah, endlich! Welche gcc Version wird nun die empfohlene?

 Marvelous, indeed.  You should be satisfied with patched 2.95.x as I am
so far, or if you are brave enough, you may try 3.3.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Thiemo Seufer]

ralf@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	03/05/16 23:19:22
> 
> Modified files:
> 	arch/mips64/kernel: linux32.c 
> 
> Log message:
> 	Remove egcs 1.1.2 workarounds from 32-bit compat code.

Ah, endlich! Welche gcc Version wird nun die empfohlene?


Thiemo

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 28 Apr 2003 ralf@linux-mips.org wrote:

> Log message:
> 	Somhow those ll/sc counters in their current form are rather useless as
> 	they're only per system, not per thread so for now I'm removing them.
> 	Yell if somebody minds - I just don't think they're really useful in
> 	their current form ...

 One use is to check if the emulation is used at all.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Apr 28, 2003 at 07:25:03PM +0900, Atsushi Nemoto wrote:

> ralf> 	Fix build for MIPS III.
> 
> It seems the .mips4 was added in wrong place (both 2.4 and 2.5).
> This patch is for 2.4.  Please apply to both tree.  Thank you.

Thanks for reminding me of this one, I had already had an identical patch
applie to my tree but didn't commit it due to problems with the CVS
archive in the past days.  That's also the explanation for a few lost or
delayed commit notifications, btw.

  Ralf

Re: CVS Update@-mips.org: linux

[Atsushi Nemoto]

>>>>> On Thu, 24 Apr 2003 12:47:50 +0100, ralf@linux-mips.org said:
ralf> Modified files:
ralf> 	arch/mips64/mm : Tag: linux_2_4 pg-r4k.c 

ralf> Log message:
ralf> 	Fix build for MIPS III.

It seems the .mips4 was added in wrong place (both 2.4 and 2.5).
This patch is for 2.4.  Please apply to both tree.  Thank you.

diff -u linux-mips/arch/mips64/mm/pg-r4k.c linux.new/arch/mips64/mm/
--- linux-mips-cvs/arch/mips64/mm/pg-r4k.c	Mon Apr 28 09:44:54 2003
+++ linux.new/arch/mips64/mm/pg-r4k.c	Mon Apr 28 19:15:22 2003
@@ -337,8 +337,6 @@
 	unsigned long dummy1, dummy2, reg1, reg2;
 
 	__asm__ __volatile__(
-		".set\tpush\n\t"
-		".set\tmips4\n\t"
 		".set\tnoreorder\n\t"
 		".set\tnoat\n\t"
 		"daddiu\t$1,%0,%6\n"
@@ -365,7 +363,8 @@
 		"sd\t%2,-16(%0)\n\t"
 		"bne\t$1,%0,1b\n\t"
 		" sd\t%3,-8(%0)\n\t"
-		".set\tpop"
+		".set\tat\n\t"
+		".set\treorder"
 		:"=r" (dummy1), "=r" (dummy2), "=&r" (reg1), "=&r" (reg2)
 		:"0" (to), "1" (from), "I" (PAGE_SIZE),
 		 "i" (Create_Dirty_Excl_D));
@@ -676,6 +675,8 @@
 	unsigned long dummy1, dummy2, reg1, reg2, reg3, reg4;
 
 	__asm__ __volatile__(
+		".set\tpush\n\t"
+		".set\tmips4\n\t"
 		".set\tnoreorder\n\t"
 		".set\tnoat\n\t"
 		"daddiu\t$1,%0,%8\n"
@@ -700,8 +701,7 @@
 		"sd\t%4,-16(%0)\n\t"
 		"bne\t$1,%0,1b\n\t"
 		" sd\t%5,-8(%0)\n\t"
-		".set\tat\n\t"
-		".set\treorder"
+		".set\tpop"
 		:"=r" (dummy1), "=r" (dummy2), "=&r" (reg1), "=&r" (reg2),
 		 "=&r" (reg3), "=&r" (reg4)
 		:"0" (to), "1" (from), "I" (PAGE_SIZE));
---
Atsushi Nemoto

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Apr 21, 2003 at 01:57:28PM +0100, sjhill@linux-mips.org wrote:

> Modified files:
> 	drivers/net    : Tag: linux_2_4 au1000_eth.c 
> 
> Log message:
> 	Reserve the ethernet port address, no it's actual virtual address.

That's a kludge on top of a kludge.  This driver like so many others is
mixing up all sort of concepts of I/O in a creative way to the point
where things coincidentally happen to work:

 - Addresses in au1x00_iflist are KSEG1 addresses that is virtual addresses.
   So that is a properly ioremapped address, right?  No ...
 - struct au1if only has an unsigned int.  Decide - if this is a virtual
   address then use unsigned long.
 - au1000_probe1 passes those addresses (with your patch: converted to a
   physical address) to request_resource.  Physical addresses and ports are
   different things.  You're using request_resource, so that address must
   be an I/O port, right?
 - ((unsigned long)AU1000_MAC1_ENABLE) - code like that is treating as
   a virtual address again ...

That's just inconsistenst and seems to have done without much understanding
the difference between memory mappend I/O and I/O ports.  I suggest to use
physical addresses and ioremap only and forget about that pre-8088 I/O port
legacy ...

  Ralf

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Mon, Apr 14, 2003 at 01:57:01PM +0200, Maciej W. Rozycki wrote:

>  I find it bogus to include <linux/smp.h> in code that has no slightest
> possibility to ever meet an SMP configuration.  I think <asm/processor.h>
> should be fixed instead.
> 
>  Following is a fix -- Ralf, I hope that's OK.

I completly agree.  Without your patch it's just a question of time until
we hit more build problems.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Sun, 13 Apr 2003, Karsten Merker wrote:

> > Modified files:
> > 	drivers/char   : Tag: linux_2_4 dz.c 
> > 	drivers/tc     : Tag: linux_2_4 zs.c 
> > 
> > Log message:
> > 	Set .owner in case the code gets modularized.  Patch by Hanna Linder.
> 
> I guess something went wrong here. Maciej, you are trying to set a field
> "owner" in a struct tty_driver, which does not have an "owner" field.
> This results in dz.c and zs.c not compiling.

 Yep, I noticed it yesterday -- the fix should have been applied to 2.5
only.  I'm committing a reversion immediately. 

> uses current_cpu_data instead of mips_cpu but does not define it. To get
> them defined, inclusion of <asm/processor.h> and <linux/smp.h> is needed.

 I find it bogus to include <linux/smp.h> in code that has no slightest
possibility to ever meet an SMP configuration.  I think <asm/processor.h>
should be fixed instead.

 Following is a fix -- Ralf, I hope that's OK.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.21-pre4-20030411-dec-cpu_data-1
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/arch/mips/dec/prom/init.c linux-mips-2.4.21-pre4-20030411/arch/mips/dec/prom/init.c
--- linux-mips-2.4.21-pre4-20030411.macro/arch/mips/dec/prom/init.c	2003-04-07 02:56:23.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/arch/mips/dec/prom/init.c	2003-04-13 19:40:03.000000000 +0000
@@ -10,6 +10,8 @@
 
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
+#include <asm/processor.h>
+
 #include <asm/dec/prom.h>
 
 
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/processor.h linux-mips-2.4.21-pre4-20030411/include/asm-mips/processor.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips/processor.h	2003-04-10 02:57:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips/processor.h	2003-04-13 19:52:53.000000000 +0000
@@ -22,7 +22,9 @@
 #define current_text_addr() ({ __label__ _l; _l: &&_l;})
 
 #ifndef __ASSEMBLY__
+#include <linux/smp.h>
 #include <linux/threads.h>
+
 #include <asm/cachectl.h>
 #include <asm/mipsregs.h>
 #include <asm/reg.h>
diff -up --recursive --new-file linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/processor.h linux-mips-2.4.21-pre4-20030411/include/asm-mips64/processor.h
--- linux-mips-2.4.21-pre4-20030411.macro/include/asm-mips64/processor.h	2003-04-13 18:48:34.000000000 +0000
+++ linux-mips-2.4.21-pre4-20030411/include/asm-mips64/processor.h	2003-04-13 19:52:10.000000000 +0000
@@ -31,6 +31,8 @@
 })
 
 #ifndef __ASSEMBLY__
+#include <linux/smp.h>
+
 #include <asm/cachectl.h>
 #include <asm/mipsregs.h>
 #include <asm/reg.h>

RE: CVS Update@-mips.org: linux

[Wayne Chen]

I would like to un-register.

wayne
 
   


-----Original Message-----
From: ralf@linux-mips.org [mailto:ralf@linux-mips.org]
Sent: Sunday, April 13, 2003 4:50 AM
To: linux-cvs@linux-mips.org
Subject: CVS Update@-mips.org: linux 



CVSROOT:	/home/cvs
Module name:	linux
Changes by:	ralf@ftp.linux-mips.org	03/04/12 21:49:57

Modified files:
	arch/mips/mm   : Makefile c-r4k.c loadmmu.c 
	arch/mips64/mm : Makefile c-r4k.c loadmmu.c 
Removed files:
	arch/mips/mm   : c-mips3264.c pg-mips3264.c 
	arch/mips64/mm : c-mips3264.c pg-mips3264.c 
	include/asm-mips: mips3264-cache.h 
	include/asm-mips64: mips3264-cache.h 

Log message:
	Send mips3264 back into the hell it came from ...

RE: CVS Update@-mips.org: linux

[Wayne Chen]

I would like to un-register.

wayne
 
   


-----Original Message-----
From: ralf@linux-mips.org [mailto:ralf@linux-mips.org]
Sent: Sunday, April 13, 2003 4:50 AM
To: linux-cvs@linux-mips.org
Subject: CVS Update@-mips.org: linux 



CVSROOT:	/home/cvs
Module name:	linux
Changes by:	ralf@ftp.linux-mips.org	03/04/12 21:49:57

Modified files:
	arch/mips/mm   : Makefile c-r4k.c loadmmu.c 
	arch/mips64/mm : Makefile c-r4k.c loadmmu.c 
Removed files:
	arch/mips/mm   : c-mips3264.c pg-mips3264.c 
	arch/mips64/mm : c-mips3264.c pg-mips3264.c 
	include/asm-mips: mips3264-cache.h 
	include/asm-mips64: mips3264-cache.h 

Log message:
	Send mips3264 back into the hell it came from ...

Re: CVS Update@-mips.org: linux

[Karsten Merker]

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

On Wed, Apr 02, 2003 at 01:03:08PM +0100, macro@linux-mips.org wrote:

> Changes by:	macro@ftp.linux-mips.org	03/04/02 13:03:08
> 
> Modified files:
> 	drivers/char   : Tag: linux_2_4 dz.c 
> 	drivers/tc     : Tag: linux_2_4 zs.c 
> 
> Log message:
> 	Set .owner in case the code gets modularized.  Patch by Hanna Linder.

I guess something went wrong here. Maciej, you are trying to set a field
"owner" in a struct tty_driver, which does not have an "owner" field.
This results in dz.c and zs.c not compiling.

Besides this problem, Ralf's recent changes regarding the CPU infos
broke the build for DECstations:

http://cvs.linux-mips.org/cvsweb/linux/arch/mips/dec/prom/init.c.diff?r1=1.8&r2=1.9&f=h

uses current_cpu_data instead of mips_cpu but does not define it. To get
them defined, inclusion of <asm/processor.h> and <linux/smp.h> is needed.

Appended is a small patch which makes the CVS compileable again.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

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

diff -Nur linux.orig/arch/mips/dec/prom/init.c linux/arch/mips/dec/prom/init.c
--- linux.orig/arch/mips/dec/prom/init.c	Mon Apr  7 02:17:06 2003
+++ linux/arch/mips/dec/prom/init.c	Sun Apr 13 16:51:11 2003
@@ -11,7 +11,8 @@
 #include <asm/bootinfo.h>
 #include <asm/cpu.h>
 #include <asm/dec/prom.h>
-
+#include <asm/processor.h>
+#include <linux/smp.h>
 
 int (*__rex_bootinit)(void);
 int (*__rex_bootread)(void);
diff -Nur linux.orig/drivers/char/dz.c linux/drivers/char/dz.c
--- linux.orig/drivers/char/dz.c	Wed Apr  2 14:03:00 2003
+++ linux/drivers/char/dz.c	Sun Apr 13 15:20:43 2003
@@ -1310,7 +1310,7 @@
 
 	memset(&serial_driver, 0, sizeof(struct tty_driver));
 	serial_driver.magic = TTY_DRIVER_MAGIC;
-	serial_driver.owner = THIS_MODULE;
+/*	serial_driver.owner = THIS_MODULE; */
 #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
 	serial_driver.name = "ttyS";
 #else
diff -Nur linux.orig/drivers/tc/zs.c linux/drivers/tc/zs.c
--- linux.orig/drivers/tc/zs.c	Wed Apr  2 14:03:04 2003
+++ linux/drivers/tc/zs.c	Sun Apr 13 15:20:57 2003
@@ -1888,7 +1888,7 @@
 
 	memset(&serial_driver, 0, sizeof(struct tty_driver));
 	serial_driver.magic = TTY_DRIVER_MAGIC;
-	serial_driver.owner = THIS_MODULE;
+/*	serial_driver.owner = THIS_MODULE; */
 #if (LINUX_VERSION_CODE > 0x2032D && defined(CONFIG_DEVFS_FS))
 	serial_driver.name = "tts/%d";
 #else

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Apr 03, 2003 at 06:47:21PM +0200, Maciej W. Rozycki wrote:

> > The length of the burst is encoded in the bus command sent out by the
> > R4000 at the beginning of a read or write cycle.  For the system to
> > work, the memory controller has to be able to do the right thing for
> > both of the lengths which might happen...
> [...]
> > This is true: for L2-equipped chips I assume you can't see the
> > difference between I- and D-.
> 
>  Ah sure -- now I see where a fault in my consideration is.  While
> thinking of SC chips, I forgot of the existence of PC ones -- certainly if
> the Magnum used a PC configuration, its chipset could easily observe a
> change of a p-cache line size.

The Magum was using a PC processor.  There also was some server version of
the system based on the SC CPU but afair it was sold as Millenium 4000
but aside of the CPU it was essentially the same.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 3 Apr 2003, Dominic Sweetman wrote:

> The length of the burst is encoded in the bus command sent out by the
> R4000 at the beginning of a read or write cycle.  For the system to
> work, the memory controller has to be able to do the right thing for
> both of the lengths which might happen...
[...]
> This is true: for L2-equipped chips I assume you can't see the
> difference between I- and D-.

 Ah sure -- now I see where a fault in my consideration is.  While
thinking of SC chips, I forgot of the existence of PC ones -- certainly if
the Magnum used a PC configuration, its chipset could easily observe a
change of a p-cache line size.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Dominic Sweetman]

Maciej W. Rozycki (macro@ds2.pg.gda.pl) writes:

> Hmm, that's even more interesting -- how can instruction fetches be
> distinguished from data reads externally???

The length of the burst is encoded in the bus command sent out by the
R4000 at the beginning of a read or write cycle.  For the system to
work, the memory controller has to be able to do the right thing for
both of the lengths which might happen...

It's very hard to see how a system could fail to work by making the
I-cache line the same size as a D-cache line.

> Then again, the memory controller shouldn't be able to observe
> inter-cache data moves.

This is true: for L2-equipped chips I assume you can't see the
difference between I- and D-.

--
Dominic
MIPS Technologies UK.

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 3 Apr 2003, Ralf Baechle wrote:

> >  Hmm, why -- is such a change observable externally in any way?  Of
> > course you can't switch the other way if the s-cache uses a line width of
> > 16 bytes.  Maybe that's the case with the Magnum?
> 
> It's a hardware problem with the memory controller I was told by one of
> it's developpers.  That forced them to run the machine with an different
> line size for D-cache and I-Cache.  There's various revs of the Magnum's
> memory controller and only one of them got all the cases right ...

 Hmm, that's even more interesting -- how can instruction fetches be
distinguished from data reads externally???  Then again, the memory
controller shouldn't be able to observe inter-cache data moves.  Strange.

> Maybe DECstation and other SGI hardware got that better?

 No problem testing, I suppose.

> >  Why?  It isn't that obvious especially as a p-cache miss costs a single
> > cycle only.
> 
> During my recent work on the cache code I found the execution time of
> cache flushing code to be quite a bit higher than previously assumed so
> larger lines would help reducing that also.

 This can be benchmarked -- there may be some gain for p-cache flushes
indeed. 

> > > working truly correct we also should no longer see VCE exceptions on
> > > R4000SC processors - the reason why Indys are still a valuable test tool.
> > 
> >  As are DECstations which use the opposite endianness -- so you can test
> > code both ways.
> 
> A bunch of evaluation boards that support running in the other endianess
> and way exceed the performance of any R4000-based platform.  Just having
> to flip a switch on the board is very handy.

 I was referring to testing cache and VCE code specifically -- you won't
get that from usual evaluation boards.

 Note that with evil /dev/mem maps you should still be able to force VCEs
if needed. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Apr 03, 2003 at 04:48:21PM +0200, Maciej W. Rozycki wrote:

> > I know of one machine where changing the size of the cacheline is supposed
> > not to work, that's the MIPS Magnum 4000 and it's close relatives.
> 
>  Hmm, why -- is such a change observable externally in any way?  Of
> course you can't switch the other way if the s-cache uses a line width of
> 16 bytes.  Maybe that's the case with the Magnum?

It's a hardware problem with the memory controller I was told by one of
it's developpers.  That forced them to run the machine with an different
line size for D-cache and I-Cache.  There's various revs of the Magnum's
memory controller and only one of them got all the cases right ...

Maybe DECstation and other SGI hardware got that better?

> > Anyway, I put the check there for the unlikely case there are broken
> > systems out there.  In practice I assume vendors were aware of this
> > problem and the check is purely theoretical and for paranoid correctness's
> > sake.
> 
>  Still V3.0 should be taken into account.

Ok.

> > It seems like changing the configuration to larger cache lines where
> > possible should improve performance somewhat.  If all the cache code is
> 
>  Why?  It isn't that obvious especially as a p-cache miss costs a single
> cycle only.

During my recent work on the cache code I found the execution time of
cache flushing code to be quite a bit higher than previously assumed so
larger lines would help reducing that also.

> > working truly correct we also should no longer see VCE exceptions on
> > R4000SC processors - the reason why Indys are still a valuable test tool.
> 
>  As are DECstations which use the opposite endianness -- so you can test
> code both ways.

A bunch of evaluation boards that support running in the other endianess
and way exceed the performance of any R4000-based platform.  Just having
to flip a switch on the board is very handy.

  Ralf

Re: CVS Update@-mips.org: linux

[Juan Quintela]

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Thu, Apr 03, 2003 at 04:11:02PM +0200, Maciej W. Rozycki wrote:
>> Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
>> #5.  But then it applies to V3.0, too.
>> 
>> Then the bit is r/w, so how about toggling it instead of panicking? 
>> With an informational message like:
>> 
>> printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
>> the R4000...\n");
>> printk(KERN_ERR "... fixing up to 16-byte size.\n");
>> 
>> Of course that probably requires a temporary cache inhibition and
>> invalidation.

ralf> I know of one machine where changing the size of the cacheline is supposed
ralf> not to work, that's the MIPS Magnum 4000 and it's close relatives.

ralf> Anyway, I put the check there for the unlikely case there are broken
ralf> systems out there.  In practice I assume vendors were aware of this
ralf> problem and the check is purely theoretical and for paranoid correctness's
ralf> sake.

ralf> It seems like changing the configuration to larger cache lines where
ralf> possible should improve performance somewhat.  If all the cache code is
ralf> working truly correct we also should no longer see VCE exceptions on
ralf> R4000SC processors - the reason why Indys are still a valuable test tool.

I still got lot of them :(

VCED exceptions         : 1544376
VCEI exceptions         : 92380

That machine was booted yesterday night.  I haven't login on it,
i.e. only normal daemons for a nfsrooted machine running.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 3 Apr 2003, Ralf Baechle wrote:

> I know of one machine where changing the size of the cacheline is supposed
> not to work, that's the MIPS Magnum 4000 and it's close relatives.

 Hmm, why -- is such a change observable externally in any way?  Of
course you can't switch the other way if the s-cache uses a line width of
16 bytes.  Maybe that's the case with the Magnum?

> Anyway, I put the check there for the unlikely case there are broken
> systems out there.  In practice I assume vendors were aware of this
> problem and the check is purely theoretical and for paranoid correctness's
> sake.

 Still V3.0 should be taken into account.

> It seems like changing the configuration to larger cache lines where
> possible should improve performance somewhat.  If all the cache code is

 Why?  It isn't that obvious especially as a p-cache miss costs a single
cycle only.

> working truly correct we also should no longer see VCE exceptions on
> R4000SC processors - the reason why Indys are still a valuable test tool.

 As are DECstations which use the opposite endianness -- so you can test
code both ways.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Thu, Apr 03, 2003 at 04:11:02PM +0200, Maciej W. Rozycki wrote:

>  Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
> #5.  But then it applies to V3.0, too.
> 
>  Then the bit is r/w, so how about toggling it instead of panicking? 
> With an informational message like:
> 
> printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
> the R4000...\n");
> printk(KERN_ERR "... fixing up to 16-byte size.\n");
> 
> Of course that probably requires a temporary cache inhibition and
> invalidation.

I know of one machine where changing the size of the cacheline is supposed
not to work, that's the MIPS Magnum 4000 and it's close relatives.

Anyway, I put the check there for the unlikely case there are broken
systems out there.  In practice I assume vendors were aware of this
problem and the check is purely theoretical and for paranoid correctness's
sake.

It seems like changing the configuration to larger cache lines where
possible should improve performance somewhat.  If all the cache code is
working truly correct we also should no longer see VCE exceptions on
R4000SC processors - the reason why Indys are still a valuable test tool.

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 3 Apr 2003 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips/mm   : Tag: linux_2_4 c-r4k.c 
> 	arch/mips64/mm : Tag: linux_2_4 c-r4k.c 
> 
> Log message:
> 	Add check for R4000 V2.2 errata #2.

 Hmm, erratum #2 is about status output pins.  I suppose you mean erratum
#5.  But then it applies to V3.0, too.

 Then the bit is r/w, so how about toggling it instead of panicking? 
With an informational message like:

printk(KERN_ERR "Firmware bug: 32-byte I-cache line size unsupported for
the R4000...\n");
printk(KERN_ERR "... fixing up to 16-byte size.\n");

Of course that probably requires a temporary cache inhibition and
invalidation.

 Would you care to code that or should I look into it?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 6 Mar 2003 kwalker@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: Tag: linux_2_4 war.h 
> 	include/asm-mips64: Tag: linux_2_4 war.h 
> 	drivers/char   : Tag: linux_2_4 Config.in Makefile 
> 	                 sb1250_duart.c 
> Added files:
> 	drivers/char   : Tag: linux_2_4 mips_rtc.c 
> 
> Log message:
> 	many uart fixes, add workaround

 Hmm, how does mips_rtc.c relate to the rest of the commit?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Fri, 21 Feb 2003, Kip Walker wrote:

> Suggestions and corrections are welcome.  I'm not an ABI/binutils
> expert.  FYI, I let Ralf eyeball this before checking it in.

 False alarm -- sorry for the confusion.  The ELF flags for MIPS are
twisted and inconsistent due to historical reasons (or ad hoc hacks) and
it seems they fooled me this time.  We could actually adjust
binfmt_elfo32.c a bit instead. 

> "Maciej W. Rozycki" wrote:
> > 
> > > Modified files:
> > >       include/asm-mips64: Tag: linux_2_4 a.out.h elf.h processor.h
> > >       arch/mips64/kernel: Tag: linux_2_4 process.c signal.c
> > >
> > > Log message:
> > >       Represent ABI (o32,n32,n64) in thread mflags using 2 bits:
> > >       MF_32BIT_REGS, MF_32BIT_ADDR.
> > 
> >  Why do you assume no ABI set for ELF32 means n32?  Historically it means
> > o32 and arch/mips64/kernel/binfmt_elfo32.c treats it as such.  Also a
> > brief study of binutils reveals the interpretation is the same for IRIX
> > which does not handle the EF_MIPS_ABI mask.

 Please try to reply below original text, BTW.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Kip Walker]

Suggestions and corrections are welcome.  I'm not an ABI/binutils
expert.  FYI, I let Ralf eyeball this before checking it in.

Kip

"Maciej W. Rozycki" wrote:
> 
> On Thu, 20 Feb 2003 kwalker@linux-mips.org wrote:
> 
> > Modified files:
> >       include/asm-mips64: Tag: linux_2_4 a.out.h elf.h processor.h
> >       arch/mips64/kernel: Tag: linux_2_4 process.c signal.c
> >
> > Log message:
> >       Represent ABI (o32,n32,n64) in thread mflags using 2 bits:
> >       MF_32BIT_REGS, MF_32BIT_ADDR.
> 
>  Why do you assume no ABI set for ELF32 means n32?  Historically it means
> o32 and arch/mips64/kernel/binfmt_elfo32.c treats it as such.  Also a
> brief study of binutils reveals the interpretation is the same for IRIX
> which does not handle the EF_MIPS_ABI mask.
> 
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Thu, 20 Feb 2003 kwalker@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips64: Tag: linux_2_4 a.out.h elf.h processor.h 
> 	arch/mips64/kernel: Tag: linux_2_4 process.c signal.c 
> 
> Log message:
> 	Represent ABI (o32,n32,n64) in thread mflags using 2 bits:
> 	MF_32BIT_REGS, MF_32BIT_ADDR.

 Why do you assume no ABI set for ELF32 means n32?  Historically it means
o32 and arch/mips64/kernel/binfmt_elfo32.c treats it as such.  Also a
brief study of binutils reveals the interpretation is the same for IRIX
which does not handle the EF_MIPS_ABI mask. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Pete Popov]

On Mon, 2003-02-17 at 05:46, Ralf Baechle wrote:
> On Sun, Feb 16, 2003 at 06:25:24AM +0000, ppopov@linux-mips.org wrote:
> 
> > Modified files:
> > 	drivers/mtd/maps: Tag: linux_2_4 Config.in Makefile 
> > Added files:
> > 	drivers/mtd/maps: Tag: linux_2_4 db1x00-flash.c 
> > 
> > Log message:
> > 	Added Db1x00 mtd driver support. The driver supports all supported
> > 	flash densities, but only the default 64Mb has been tested at this
> > 	time.
> 
> #include <stdrant.h> you forgot 2.5 :-)

Sorry. Dan _is_ working on 2.5. I'll start testing the builds on 2.4 and
2.5 before committing the patches.

Pete

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sun, Feb 16, 2003 at 06:25:24AM +0000, ppopov@linux-mips.org wrote:

> Modified files:
> 	drivers/mtd/maps: Tag: linux_2_4 Config.in Makefile 
> Added files:
> 	drivers/mtd/maps: Tag: linux_2_4 db1x00-flash.c 
> 
> Log message:
> 	Added Db1x00 mtd driver support. The driver supports all supported
> 	flash densities, but only the default 64Mb has been tested at this
> 	time.

#include <stdrant.h> you forgot 2.5 :-)

  Ralf

Re: CVS Update@-mips.org: linux

[Maciej W. Rozycki]

On Mon, 27 Jan 2003, Ralf Baechle wrote:

> > Log message:
> > 	Fix a restoration of assembler's settings in csum_ipv6_magic().
> 
> Wow, how did you catch this one - running IPv6?

 I do run IPv6 -- I get to my 32-bit box with SSH over IPv6 just to make
sure I'll find more bugs (the previous one was the multicast filter). ;-) 
I even have ipv6.o as a module (which also triggered bugs in the past). 
Will have to try with the 64-bit box. ;-)))

 But this bug I've actually spotted studying compiler's diagnostic output
-- a "Macro instruction expanded into multiple instructions in a branch
delay slot" warning isn't normal for a .c file. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: CVS Update@-mips.org: linux

[Ralf Baechle]

On Sun, Jan 26, 2003 at 05:36:11PM +0000, macro@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: Tag: linux_2_4 checksum.h 
> 	include/asm-mips64: Tag: linux_2_4 checksum.h 
> 
> Log message:
> 	Fix a restoration of assembler's settings in csum_ipv6_magic().

Wow, how did you catch this one - running IPv6?

  Ralf

Re: CVS Update@-mips.org: linux

[Geert Uytterhoeven]

On Sat, 2 Nov 2002 ralf@linux-mips.org wrote:
> Log message:
> 	Merge with Linux 2.5.45.

Congratulations!!! That was a very fast merge cycle!

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