Re: CVS Update@linux-mips.org: linux

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 08, 2005 at 10:17:05AM +0100, ths@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/07/08 10:17:05
> 
> Modified files:
> 	include/asm-mips: checksum.h 
> 
> Log message:
> 	Protect noat assembly with .set push/pop and make it somewhat readable.

It doesn't need protction.

 Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 8 Jul 2005, Ralf Baechle wrote:

> > Log message:
> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> 
> It doesn't need protction.

 Are you absolutely sure future versions of GCC won't default to ".set 
noat" for inline asm?  I am not; in fact the opposite is not unlikely.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 8 Jul 2005, Ralf Baechle wrote:
>> > Log message:
>> > 	Protect noat assembly with .set push/pop and make it somewhat readable.
>> 
>> It doesn't need protction.
>
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?

Yes ;)  All hell would break loose otherwise. ;)

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 08, 2005 at 01:12:55PM +0100, Maciej W. Rozycki wrote:

> > > 	Protect noat assembly with .set push/pop and make it somewhat readable.
> > 
> > It doesn't need protction.
> 
>  Are you absolutely sure future versions of GCC won't default to ".set 
> noat" for inline asm?  I am not; in fact the opposite is not unlikely.

Indeed - but everybody is free to shoot himself into the foot.  With
uzis even.  Does that make it a good idea?

  Ralf

Benchmarking RM9000

[Alex Gonzalez]

Hi,

I am doing some basic benchmarking tests on our RM9000 based platform,
running on just one of the two cores (non-smp kernel).

I would be very interesting in seeing some comparative data as we seem
to experience some performance problems.

Even if no data is available, any comments on this results will also be
appreciated.

Thanks,
Alex

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

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
                                                                                                                                                       
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          360.48  :       9.24  :       3.04
STRING SORT         :           31.23  :      13.95  :       2.16
BITFIELD            :      8.4132e+07  :      14.43  :       3.01
FP EMULATION        :          32.921  :      15.80  :       3.65
FOURIER             :            3383  :       3.85  :       2.16
ASSIGNMENT          :          4.2422  :      16.14  :       4.19
IDEA                :          1543.3  :      23.60  :       7.01
HUFFMAN             :          382.56  :      10.61  :       3.39
NEURAL NET          :          3.7153  :       5.97  :       2.51
LU DECOMPOSITION    :          209.28  :      10.84  :       7.83
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 14.242
FLOATING-POINT INDEX: 6.291
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 :
L2 Cache            :
OS                  : Linux 2.6.12-rc3
C compiler          : gcc version 3.3.5
libc                : libc-2.3.5.so
MEMORY INDEX        : 3.010
INTEGER INDEX       : 4.026
FLOATING-POINT INDEX: 3.489
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Re: Benchmarking RM9000

[Laurence Darby]

Alex Gonzalez wrote:

> Hi,
> 
> I am doing some basic benchmarking tests on our RM9000 based platform,
> running on just one of the two cores (non-smp kernel).

<snip>

> TEST                : Iterations/sec.  : Old Index   : New Index
>                     :                  : Pentium 90* : AMD K6/233*
> --------------------:------------------:-------------:------------>
> NUMERIC SORT        :          360.48  :       9.24  :       3.04


I'd expect a K6 to be able to do more Iterations per second than a
Pentium 90, not fewer. 


Laurence

Re: Benchmarking RM9000

[Alex Gonzalez]

The performance of our video application is well below our expectations.
We are still doing some profiling work on it, but we are also looking at
other possibilities.

What other benchmarking tool would you recommend?

Currently it's a NFS mounted system, but even if we could use a block
device the access speed wouldn't be more than 1.5 Mbps, so that is a
limitation for the benchmark.

Alex

On Fri, 2005-07-08 at 14:01, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 01:25:49PM +0100, Alex Gonzalez wrote:
> 
> > I am doing some basic benchmarking tests on our RM9000 based platform,
> > running on just one of the two cores (non-smp kernel).
> > 
> > I would be very interesting in seeing some comparative data as we seem
> > to experience some performance problems.
> 
> What exactly are those performance issues?
> 
> If I recall right how to read bytebench numbers, your Bytebench numbers
> are look roughly ok, at least in first approximation.  That benchmark
> has become uncommon so I don't have any numbers at hand to compare with.
> 
>   Ralf

Re: Benchmarking RM9000

[Ralf Baechle]

On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:

> The performance of our video application is well below our expectations.
> We are still doing some profiling work on it, but we are also looking at
> other possibilities.
> 
> What other benchmarking tool would you recommend?
> 
> Currently it's a NFS mounted system, but even if we could use a block
> device the access speed wouldn't be more than 1.5 Mbps, so that is a
> limitation for the benchmark.

As a shot into the dark ...

Make sure you exploit the RM9000's write-gathering capabilities when
writing into the frame buffer.  If the frame buffer happens to be on
a PCI device you're probably performing uncached writes which will
slow down the thing to a crawl.

  Ralf

Re: Benchmarking RM9000

[Alex Gonzalez]

Thanks for all the feedback.

I enclose new results from the lmbench testing.

Answering some suggestions,

I won't use gmplayer as a benchmarking tool. The platform has no
graphics adapter. We're developing a streaming video application in an
embedded platform (no hdd either).

I'll check that the driver is using the write-gather functionality to
move data from/to the ethernet adapter.

As before, I'd appreciate some other results from modern systems to
compare with.

Regards,
Alex

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


 
                 L M B E N C H  3 . 0   S U M M A R Y
                 ------------------------------------
                 (Alpha software, do not distribute)
 
Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes
--------- ------------- ----------------------- ---- ----- ----- ------ ----
192.168.1 Linux 2.6.12-          mips-linux-gnu  985     4    32 1.4200    1
 
Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
192.168.1 Linux 2.6.12-  985 0.19 0.49 4.29 150. 25.4 0.65 3.76 828. 5032 16.K
 
Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr
                          bit   add    mul    div    mod
--------- ------------- ------ ------ ------ ------ ------
192.168.1 Linux 2.6.12- 1.0200 1.0200 4.1500   43.5   41.5
 
Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 6.0700   22.3   41.7
 
Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------
192.168.1 Linux 2.6.12- 6.0700 9.1100   37.4   62.0
 
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
192.168.1 Linux 2.6.12- 0.8400 5.6600 8.2600   22.6  235.2    58.9   242.3
 
*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
192.168.1 Linux 2.6.12- 0.840 6.775 13.4              38.0       143.
                                                                                                                                                       
File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
192.168.1 Linux 2.6.12-                              4926.0 0.622 2.59860  16.6
                                                                                                                                                       
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
192.168.1 Linux 2.6.12- 141. 292. 57.2  140.5  224.7   97.1   88.2 224. 155.4
                                                                                                                                                       
Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
192.168.1 Linux 2.6.12-   985 3.0750   45.4  109.5       254.9



On Mon, 2005-07-11 at 00:14, Ralf Baechle wrote:
> On Fri, Jul 08, 2005 at 03:42:29PM +0100, Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our expectations.
> > We are still doing some profiling work on it, but we are also looking at
> > other possibilities.
> > 
> > What other benchmarking tool would you recommend?
> > 
> > Currently it's a NFS mounted system, but even if we could use a block
> > device the access speed wouldn't be more than 1.5 Mbps, so that is a
> > limitation for the benchmark.
> 
> As a shot into the dark ...
> 
> Make sure you exploit the RM9000's write-gathering capabilities when
> writing into the frame buffer.  If the frame buffer happens to be on
> a PCI device you're probably performing uncached writes which will
> slow down the thing to a crawl.
> 
>   Ralf

Re: Benchmarking RM9000

[Ralf Rösch]

>As before, I'd appreciate some other results from modern systems to
>compare with.
>
>  
>
Alex, below you can find our LMBENCH 3.0-a4 test results. 
Our machine is a Toshiba TX4937 based system (in the hope "modern enough") running with 
333MHz CPU-Clock and 133 MHz SDRAM-Clock (64bit).
The bench was run on the Debian based mipsel-distribution.
I'm surprised about the big difference in test results compared to your RM9000 system.
I would expect that your system should be much faster and I think there must be
a blocking part (hardware, software)  in your system. 

Regards
  Ralf (Roesch)

                 L M B E N C H  3 . 0   S U M M A R Y

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

         (Alpha software, do not distribute)

Basic system parameters
------------------------------------------------------------------------------
Host                 OS Description              Mhz  tlb  cache  mem   scal
                                                     pages line   par   load
                                                           bytes  
--------- ------------- ----------------------- ---- ----- ----- ------ ----
debian-mi  Linux 2.6.12        mipsel-linux-gnu  326     4    32 1.0700    1

Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
debian-mi  Linux 2.6.12  326 0.41 1.22 8.37 9.96 78.1 1.85 7.77 1437 8018 36.K

Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr  
                          bit   add    mul    div    mod   
--------- ------------- ------ ------ ------ ------ ------ 
debian-mi  Linux 2.6.12 3.0600 0.0500   18.3  122.4  124.8

Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------ 
debian-mi  Linux 2.6.12   15.6   15.1   64.9  126.7

Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------ 
debian-mi  Linux 2.6.12   24.7   24.2  106.5  217.8

Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
debian-mi  Linux 2.6.12 1.1100   29.8   28.4   71.2   18.6    70.2    24.5

*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
debian-mi  Linux 2.6.12 1.110  16.4 35.3  73.8 205.7 146.8 313.1 560.

File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
debian-mi  Linux 2.6.12  252.1  349.2  753.6  536.2   69.0K 1.830 5.18150  44.3

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
debian-mi  Linux 2.6.12 41.0 42.0 36.5   55.7  166.1   89.8   89.0 166. 153.4

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
debian-mi  Linux 2.6.12   326 6.3470  125.0  127.1       302.4    No L2 cache?

Re: Benchmarking RM9000

[Laurence Darby]

Alex Gonzalez wrote:

> The performance of our video application is well below our
> expectations. We are still doing some profiling work on it, but we
> are also looking at other possibilities.
> 
> What other benchmarking tool would you recommend?


There's lmbench, available only from 
http://ftp.debian.org/debian/pool/non-free/l/lmbench/lmbench_2.0-patch2.orig.tar.gz
(the debian package itself doesn't work, and its main ftp site seems to
be down)

glxgears is nice and simple for 3d bmarks.

mplayer may be useful with its -benchmark option. Its docs, though
mostly x86 specific, are still interesting for video performance
issues.


Laurence

Re: Benchmarking RM9000

[Dominik 'Rathann' Mierzejewski]

On Mon, Jul 11, 2005 at 12:09:59PM +0100, Laurence Darby wrote:
> Alex Gonzalez wrote:
> 
> > The performance of our video application is well below our
> > expectations. We are still doing some profiling work on it, but we
> > are also looking at other possibilities.
> > 
> > What other benchmarking tool would you recommend?
[...] 
> mplayer may be useful with its -benchmark option. Its docs, though
> mostly x86 specific, are still interesting for video performance
> issues.

If you do use mplayer, please send all useful feedback to
mplayer-users at mplayerhq.hu, too, please.

We (MPlayer team) are always interested in mplayer operation on other
architectures.

Regards,
R.

-- 
Dominik 'Rathann' Mierzejewski <rathann*at*icm.edu.pl>
Interdisciplinary Centre for Mathematical and Computational Modelling
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810

Re: CVS Update@linux-mips.org: linux

[Matej Kupljen]

Hi

> Modified files:
> 	arch/mips/au1000/common: platform.c 
> 
> Log message:
> 	smc91x platform support; requires patch to smc91x.h which was sent
> 	upstream.

Can I see the patch, or where was it send?

BR,
Matej

Re: CVS Update@linux-mips.org: linux

[Jerry]

>[In reply to "CVS Update@linux-mips.org: linux" from ppopov@linux-mips.org <ppopov@linux-mips.org> to linux-cvs@linux-mips.org <linux-cvs@linux-mips.org>  20.09.2005 3:20]

> Log message:
>         Au1200 fb driver. Updated db1200 defconfig to include driver by
>         default.

Looks like a some early versions. Anyway good news that i'is in the
tree. The bad news that it mostly unusable and needs a lot of work.
(I don't think one can use it with IOCTL code defined in .c file :) )

All society now waits for mae driver.


   ()_()
 -( ^,^ )- -[21398845]- -<The Bat! 3.51.10>- -<20.09.2005 11:11>-
  (") (")

Re: CVS Update@linux-mips.org: linux

[Pete Popov]

On Tue, 2005-09-20 at 11:19 +0300, Jerry wrote:
> >[In reply to "CVS Update@linux-mips.org: linux" from ppopov@linux-mips.org <ppopov@linux-mips.org> to linux-cvs@linux-mips.org <linux-cvs@linux-mips.org>  20.09.2005 3:20]
> 
> > Log message:
> >         Au1200 fb driver. Updated db1200 defconfig to include driver by
> >         default.
> 
> Looks like a some early versions. Anyway good news that i'is in the
> tree. The bad news that it mostly unusable and needs a lot of work.
> (I don't think one can use it with IOCTL code defined in .c file :) )

What's mostly unusable? I only did cosmetic cleanups of this one and
gave it a quick test. Seemed to work fine. Let me know what you've
tested and didn't work for you and we'll fix it at some point.

> All society now waits for mae driver.

Pete

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 2 Sep 2005 ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/mm   : c-r4k.c 
> 
> Log message:
> 	Fix r4600 revision bitmask.

 This change is broken.  The new masked out value may match a 
MIPS32/MIPS64 architecture CPU.  What was wrong with the old mask?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 2 Sep 2005 ths@linux-mips.org wrote:
> 
> > Modified files:
> > 	arch/mips/mm   : c-r4k.c 
> > 
> > Log message:
> > 	Fix r4600 revision bitmask.
> 
>  This change is broken.  The new masked out value may match a 
> MIPS32/MIPS64 architecture CPU.  What was wrong with the old mask?

Hm, I made it the same as is used in pg-r4k.c without looking up
the meaning of the high bits.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 2 Sep 2005, Thiemo Seufer wrote:

> Hm, I made it the same as is used in pg-r4k.c without looking up
> the meaning of the high bits.

 You have picked up the wrong variation. ;-)  Thanks for fixing up.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Thu, Sep 01, 2005 at 09:56:30AM +0100, ths@linux-mips.org wrote:

> diff -urN linux/include/asm-mips/mach-ip22/spaces.h linux/include/asm-mips/mach-ip22/spaces.h
> --- linux/include/asm-mips/mach-ip22/spaces.h	2005/07/14 12:05:11	1.3
> +++ linux/include/asm-mips/mach-ip22/spaces.h	2005/09/01 08:56:18	1.4
> @@ -44,7 +44,7 @@
>  #define CAC_BASE		0xffffffff80000000
>  #define IO_BASE			0xffffffffa0000000
>  #define UNCAC_BASE		0xffffffffa0000000
> -#define MAP_BASE		0xffffffffc0000000
> +#define MAP_BASE		0xc000000000000000

You just broke the R5000.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Thu, Sep 01, 2005 at 12:18:36PM +0100, Ralf Baechle wrote:

> You just broke the R5000.

Forgot it, was thinking of something else, the ll/sc in XKPHYS bug ...

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Sat, 20 Aug 2005 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: irq_cpu.c 
> 
> Log message:
> 	MT bulletproofing; MT also uses the software interrupts.

 Well, since they use a different controller structure and different 
functions, the user-visible name should be different too, shouldn't it?  
To be original ;-) -- how about "MIPS-MT"?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Aug 22, 2005 at 10:18:01AM +0100, Maciej W. Rozycki wrote:

> > Log message:
> > 	MT bulletproofing; MT also uses the software interrupts.
> 
>  Well, since they use a different controller structure and different 
> functions, the user-visible name should be different too, shouldn't it?  
> To be original ;-) -- how about "MIPS-MT"?

Thought about but then it's still hammering at the same old bits which
now just have received a different use.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Mon, 22 Aug 2005, Ralf Baechle wrote:

> >  Well, since they use a different controller structure and different 
> > functions, the user-visible name should be different too, shouldn't it?  
> > To be original ;-) -- how about "MIPS-MT"?
> 
> Thought about but then it's still hammering at the same old bits which
> now just have received a different use.

 Using another structure is enough for justification -- it's a different 
"controller".  Similarly the two variations of interrupts handled in 
arch/mips/dec/ioasic-irq.c are almost the same (the difference is even 
smaller than here), but using separate structures made me use different 
names.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Wed, 27 Jul 2005 ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: cpu-probe.c 
> 
> Log message:
> 	R4600 has 32 FPRs.

 That was a strange omission.  Hmm...

  Maciej

Re: CVS Update@linux-mips.org: linux

[Niels Sterrenburg]

Hi Ralf and or others,

Do you detect and fix these trailing whitespaces with a script ?
If so can you tell me where I can find it (or send it)?

Thanks in advance,

Niels Sterrenburg

>
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	05/07/25 22:36:00
>
> Modified files:
> 	include/asm-mips/mach-generic: kernel-entry-init.h
> 	include/asm-mips/mach-ip27: kernel-entry-init.h
> 	include/asm-mips/mach-pnx8550: glb.h kernel-entry-init.h nand.h
> 	                               pci.h usb.h
> 	arch/mips/au1000/common: irq.c
> 	arch/mips/pci  : ops-pnx8550.c
> 	arch/mips/philips/pnx8550/common: gdb_hook.c int.c pci.c proc.c
> 	                                  prom.c setup.c
> 	arch/mips/philips/pnx8550/jbs: board_setup.c init.c
>
> Log message:
> 	Fixup the trailing whitespace mess.
>
>
>

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Wed, 27 Jul 2005, Niels Sterrenburg wrote:
> Do you detect and fix these trailing whitespaces with a script ?

For detection, if you use vim, you want to add

    let c_space_errors=1

to your .vimrc and make the superfluous spacing hurt your eyes.

> If so can you tell me where I can find it (or send it)?

sed(1) is your friend ;-)

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

[Maciej W. Rozycki]

On Wed, 27 Jul 2005, Geert Uytterhoeven wrote:

> > If so can you tell me where I can find it (or send it)?
> 
> sed(1) is your friend ;-)

 And s/// works from vi, too.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Wed, Jul 27, 2005 at 05:33:06PM +0200, Niels Sterrenburg wrote:

> Do you detect and fix these trailing whitespaces with a script ?
> If so can you tell me where I can find it (or send it)?

Well, here's my nuke-trailing-whitespace skript.  Pretty small - 80% of it
is the legalese and a brief comment.  In case you're using quilt you
can do something like

  nuke-trailing-whitespace `quilt files`
  quilt refresh --diffstat

to clean a particular patch

  Ralf

#! /bin/bash
#
# Copyright (C) 2002 by Ralf Baechle (ralf@linux-mips.org)
#
#  This program is free software; you can redistribute  it and/or modify it
#  under  the terms of  the GNU General  Public License as published by the
#  Free Software Foundation;  either version 2 of the  License, or (at your
#  option) any later version.
#
#  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR IMPLIED
#  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
#  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT, INDIRECT,
#  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
#  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
#  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
#  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
#  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
#  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
#  You should have received a copy of the  GNU General Public License along
#  with this program; if not, write  to the Free Software Foundation, Inc.,
#  675 Mass Ave, Cambridge, MA 02139, USA.
#
# nuke-trailing-whitespace - Nuke trailing whitespace in sourcecode
#
# Usage: nuke-trailing-whitespace [file]...
#

find $*  -name CVS -prune -o -type f -print | \
	fgrep -v defconfig |
	xargs --no-run-if-empty -- perl -pi -e 's/[ \t]+$//'

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Wed, 27 Jul 2005, Ralf Baechle wrote:

> Well, here's my nuke-trailing-whitespace skript.  Pretty small - 80% of it
> is the legalese and a brief comment.  In case you're using quilt you
> can do something like
> 
>   nuke-trailing-whitespace `quilt files`
>   quilt refresh --diffstat
> 
> to clean a particular patch

 It doesn't wipe other rubbish like spaces followed by tabs, though -- 
e.g. ones that would match "^ \t".  Perhaps `indent' could help with them, 
but I trust my fingers and eyes instead. ;-)

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Wed, Jul 27, 2005 at 07:03:16PM +0100, Maciej W. Rozycki wrote:

>  It doesn't wipe other rubbish like spaces followed by tabs, though -- 
> e.g. ones that would match "^ \t".  Perhaps `indent' could help with them, 
> but I trust my fingers and eyes instead. ;-)

Of course it does:

[ralf@box ~]$ echo -ne '  \t\t' | perl -pi -e 's/[ \t]+$//' | od -x
0000000
[ralf@box ~]$

  Ralf

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Wed, 27 Jul 2005, Ralf Baechle wrote:
> On Wed, Jul 27, 2005 at 07:03:16PM +0100, Maciej W. Rozycki wrote:
> >  It doesn't wipe other rubbish like spaces followed by tabs, though -- 
> > e.g. ones that would match "^ \t".  Perhaps `indent' could help with them, 
> > but I trust my fingers and eyes instead. ;-)
> 
> Of course it does:
> 
> [ralf@box ~]$ echo -ne '  \t\t' | perl -pi -e 's/[ \t]+$//' | od -x
> 0000000
> [ralf@box ~]$

Maciej meant spaces followed by tabs that do not end a line, e.g.

| tux$ echo -ne '  \t\tx' | perl -pi -e 's/[ \t]+$//' | od -x
| 0000000 2020 0909 0078
| 0000005

These are a bit more difficult to auto-remove, since simply removing them may
change indentation (modulo 8).

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

[Maciej W. Rozycki]

On Thu, 28 Jul 2005, Geert Uytterhoeven wrote:

> Maciej meant spaces followed by tabs that do not end a line, e.g.

 Indeed.

> These are a bit more difficult to auto-remove, since simply removing them may
> change indentation (modulo 8).

 I've found it quite efficient to do it with `vim' and conditional regexp 
substitution.  This way you can see what gets changed and if indentation 
needs to be fixed up afterwards, you can do this immediately.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Thu, Jul 28, 2005 at 11:13:53AM +0100, Maciej W. Rozycki wrote:

> > Maciej meant spaces followed by tabs that do not end a line, e.g.
> 
>  Indeed.

Oh, I quite intensionally left those alone for now.  And if needed there's
always unexpand(1).

  Ralf

Re: CVS Update@linux-mips.org: linux

[Niels Sterrenburg]

Hi all,

Quite a big threat this question generated (and that for some spaces) :-)

I've adapted my vimrc and check ralfs script when creating patches.

Thanks for all the feedback,

Niels Sterrenburg

> On Wed, 27 Jul 2005, Ralf Baechle wrote:
>> On Wed, Jul 27, 2005 at 07:03:16PM +0100, Maciej W. Rozycki wrote:
>> >  It doesn't wipe other rubbish like spaces followed by tabs, though --
>> > e.g. ones that would match "^ \t".  Perhaps `indent' could help with
>> them,
>> > but I trust my fingers and eyes instead. ;-)
>>
>> Of course it does:
>>
>> [ralf@box ~]$ echo -ne '  \t\t' | perl -pi -e 's/[ \t]+$//' | od -x
>> 0000000
>> [ralf@box ~]$
>
> Maciej meant spaces followed by tabs that do not end a line, e.g.
>
> | tux$ echo -ne '  \t\tx' | perl -pi -e 's/[ \t]+$//' | od -x
> | 0000000 2020 0909 0078
> | 0000005
>
> These are a bit more difficult to auto-remove, since simply removing them
> may
> change indentation (modulo 8).
>
> 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@linux-mips.org: linux

[Ralf Baechle]

On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: binfmt_elfo32.c 
> 	include/asm-mips: elf.h 
> 
> Log message:
> 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.

Remarkably bad idea after the old definitions are already being used since
over a decade.

Btw, I don't recall approving that patch ...

  Ralf

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> 
> > Modified files:
> > 	arch/mips/kernel: binfmt_elfo32.c 
> > 	include/asm-mips: elf.h 
> > 
> > Log message:
> > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> 
> Remarkably bad idea after the old definitions are already being used since
> over a decade.

Well, kernel headers are less widely used than others, and everywhere
else it is E_*. Since
 - kernel headers in general aren't meant as an interface for userland,
 - the definition is inconsistent to the userland one,
 - the in-kernel use seems to be limited to the ELF binary object
   loader and probably third party modules loaders
I found moving to a consistent definition to be more useful than
keeping the old inconsistent one.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 22, 2005 at 02:10:30PM +0200, Thiemo Seufer wrote:
> Date:	Fri, 22 Jul 2005 14:10:30 +0200
> To:	Ralf Baechle <ralf@linux-mips.org>
> Cc:	linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: text/plain; charset=us-ascii
> From:	Thiemo Seufer <ths@networkno.de>
> 
> Ralf Baechle wrote:
> > On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> > 
> > > Modified files:
> > > 	arch/mips/kernel: binfmt_elfo32.c 
> > > 	include/asm-mips: elf.h 
> > > 
> > > Log message:
> > > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> > 
> > Remarkably bad idea after the old definitions are already being used since
> > over a decade.
> 
> Well, kernel headers are less widely used than others, and everywhere
> else it is E_*. Since
>  - kernel headers in general aren't meant as an interface for userland,
>  - the definition is inconsistent to the userland one,

Glibc is the only thing elf.h that defines the E_* names at all and
explicitly says "don't use".

>  - the in-kernel use seems to be limited to the ELF binary object
>    loader and probably third party modules loaders
> I found moving to a consistent definition to be more useful than
> keeping the old inconsistent one.

I think you're confusing binutils's internal definitions with the use
everywhere else.

Mind pulling that patch?

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 22 Jul 2005, Ralf Baechle wrote:

> >  - the in-kernel use seems to be limited to the ELF binary object
> >    loader and probably third party modules loaders
> > I found moving to a consistent definition to be more useful than
> > keeping the old inconsistent one.
> 
> I think you're confusing binutils's internal definitions with the use
> everywhere else.

 In particular when in doubt please refer to ELF standards which state 
"EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
-- you should see the pattern.  There is no mention of the "E_" prefix in 
the standards.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 22, 2005 at 02:24:48PM +0100, Maciej W. Rozycki wrote:

> > >  - the in-kernel use seems to be limited to the ELF binary object
> > >    loader and probably third party modules loaders
> > > I found moving to a consistent definition to be more useful than
> > > keeping the old inconsistent one.
> > 
> > I think you're confusing binutils's internal definitions with the use
> > everywhere else.
> 
>  In particular when in doubt please refer to ELF standards which state 
> "EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
> file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
> -- you should see the pattern.  There is no mention of the "E_" prefix in 
> the standards.

Which makes me wonder why glibc has the E_ definitions.  Other operating
systems that I looked up don't.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 02:24:48PM +0100, Maciej W. Rozycki wrote:
> 
> > > >  - the in-kernel use seems to be limited to the ELF binary object
> > > >    loader and probably third party modules loaders
> > > > I found moving to a consistent definition to be more useful than
> > > > keeping the old inconsistent one.
> > > 
> > > I think you're confusing binutils's internal definitions with the use
> > > everywhere else.
> > 
> >  In particular when in doubt please refer to ELF standards which state 
> > "EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
> > file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
> > -- you should see the pattern.  There is no mention of the "E_" prefix in 
> > the standards.
> 
> Which makes me wonder why glibc has the E_ definitions.  Other operating
> systems that I looked up don't.

The MIPS ELF ABI supplement mandates those bits to be zero (for MIPS I),
consequentially it doesn't need to specify names for them.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 22 Jul 2005, Ralf Baechle wrote:

> Which makes me wonder why glibc has the E_ definitions.  Other operating
> systems that I looked up don't.

 Well, we can scan old change logs and then throw darts at a likeness of 
the offender. ;-)  Oh -- and we could ask the person, too.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 02:10:30PM +0200, Thiemo Seufer wrote:
> > Date:	Fri, 22 Jul 2005 14:10:30 +0200
> > To:	Ralf Baechle <ralf@linux-mips.org>
> > Cc:	linux-mips@linux-mips.org
> > Subject: Re: CVS Update@linux-mips.org: linux
> > Content-Type: text/plain; charset=us-ascii
> > From:	Thiemo Seufer <ths@networkno.de>
> > 
> > Ralf Baechle wrote:
> > > On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> > > 
> > > > Modified files:
> > > > 	arch/mips/kernel: binfmt_elfo32.c 
> > > > 	include/asm-mips: elf.h 
> > > > 
> > > > Log message:
> > > > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> > > 
> > > Remarkably bad idea after the old definitions are already being used since
> > > over a decade.
> > 
> > Well, kernel headers are less widely used than others, and everywhere
> > else it is E_*. Since
> >  - kernel headers in general aren't meant as an interface for userland,
> >  - the definition is inconsistent to the userland one,
> 
> Glibc is the only thing elf.h that defines the E_* names at all and
> explicitly says "don't use".

It looks like things are worse than just different naming:

Glibc prefers:
#define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
#define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
#define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
#define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
#define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
#define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
#define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */

and knows also but depreciates:
#define E_MIPS_ARCH_1     0x00000000    /* -mips1 code.  */
#define E_MIPS_ARCH_2     0x10000000    /* -mips2 code.  */
#define E_MIPS_ARCH_3     0x20000000    /* -mips3 code.  */
#define E_MIPS_ARCH_4     0x30000000    /* -mips4 code.  */
#define E_MIPS_ARCH_5     0x40000000    /* -mips5 code.  */
#define E_MIPS_ARCH_32    0x60000000    /* MIPS32 code.  */
#define E_MIPS_ARCH_64    0x70000000    /* MIPS64 code.  */

Gcc/binutils actually create:
#define E_MIPS_ARCH_1           0x00000000
#define E_MIPS_ARCH_2           0x10000000
#define E_MIPS_ARCH_3           0x20000000
#define E_MIPS_ARCH_4           0x30000000
#define E_MIPS_ARCH_5           0x40000000
#define E_MIPS_ARCH_32          0x50000000
#define E_MIPS_ARCH_64          0x60000000
#define E_MIPS_ARCH_32R2        0x70000000
#define E_MIPS_ARCH_64R2        0x80000000

The kernel has (had):
#define EF_MIPS_ARCH_1	0x00000000      /* -mips1 code.  */
#define EF_MIPS_ARCH_2	0x10000000      /* -mips2 code.  */
#define EF_MIPS_ARCH_3	0x20000000      /* -mips3 code.  */
#define EF_MIPS_ARCH_4	0x30000000      /* -mips4 code.  */
#define EF_MIPS_ARCH_5	0x40000000      /* -mips5 code.  */
#define EF_MIPS_ARCH_32	0x50000000      /* MIPS32 code.  */
#define EF_MIPS_ARCH_64	0x60000000      /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2     0x70000000	/* MIPS32 R2 code.  */
#define EF_MIPS_ARCH_64R2     0x80000000	/* MIPS64 R2 code.  */

so glibc misinterprets E(F)_MIPS_ARCH_{32,64} as used by the toolchain.

> >  - the in-kernel use seems to be limited to the ELF binary object
> >    loader and probably third party modules loaders
> > I found moving to a consistent definition to be more useful than
> > keeping the old inconsistent one.
> 
> I think you're confusing binutils's internal definitions with the use
> everywhere else.
> 
> Mind pulling that patch?

I would prefer to have the same consistent set of names for all users.

Maciej made the point that the EF_ prefix is common for ELF header flag
defines, this suggests to standardize on the defines the kernels had
previously. This might break glibc's ld.so for third party toolchains
which followed the glibc definitions (if they actually exist).

Comments?


Thiemo

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Thu, Jul 21, 2005 at 04:36:37PM +0100, ths@linux-mips.org wrote:

> Log message:
> 	#ifdef looks better than #if. :-)
> 
> diff -urN linux/include/asm-mips/reg.h linux/include/asm-mips/reg.h
> --- linux/include/asm-mips/reg.h	2005/07/14 12:05:09	1.6
> +++ linux/include/asm-mips/reg.h	2005/07/21 15:36:30	1.7
> @@ -70,7 +70,7 @@
>  
>  #endif
>  
> -#if CONFIG_64BIT
> +#ifdef CONFIG_64BIT

It's can be a bug, depending on the exact use, so generally it's shot
to kill.

 Ralf

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

Hi Pete,

On Thu, 14 Jul 2005 18:48:00 +0100
ppopov@linux-mips.org wrote:

> 
> Log message:
> 	Philips PNX8550 support: MIPS32-like core with 2 Trimedias on it.

I think the following include path is better.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c a/arch/mips/philips/pnx8550/common/gdb_hook.c
--- a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/gdb_hook.c	2005-07-15 23:44:03.361056952 +0900
@@ -31,7 +31,7 @@
 #include <asm/serial.h>
 #include <asm/io.h>
 
-#include <asm/mach-pnx8550/uart.h>
+#include <uart.h>
 
 static struct serial_state rs_table[RS_TABLE_SIZE] = {
 	SERIAL_PORT_DFNS	/* Defined in serial.h */
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/int.c a/arch/mips/philips/pnx8550/common/int.c
--- a-orig/arch/mips/philips/pnx8550/common/int.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/int.c	2005-07-15 23:44:32.008701848 +0900
@@ -35,8 +35,8 @@
 
 #include <asm/io.h>
 #include <asm/gdb-stub.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <uart.h>
 
 extern asmlinkage void cp0_irqdispatch(void);
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/pci.c a/arch/mips/philips/pnx8550/common/pci.c
--- a-orig/arch/mips/philips/pnx8550/common/pci.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/pci.c	2005-07-15 23:44:52.444595120 +0900
@@ -24,9 +24,9 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 
-#include <asm/mach-pnx8550/pci.h>
-#include <asm/mach-pnx8550/glb.h>
-#include <asm/mach-pnx8550/nand.h>
+#include <pci.h>
+#include <glb.h>
+#include <nand.h>
 
 static struct resource pci_io_resource = {
 	"pci IO space",
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/platform.c a/arch/mips/philips/pnx8550/common/platform.c
--- a-orig/arch/mips/philips/pnx8550/common/platform.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/platform.c	2005-07-15 23:45:16.826888448 +0900
@@ -17,9 +17,9 @@
 #include <linux/init.h>
 #include <linux/resource.h>
 
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/usb.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <usb.h>
+#include <uart.h>
 
 static struct resource pnx8550_usb_ohci_resources[] = {
 	[0] = {
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/proc.c a/arch/mips/philips/pnx8550/common/proc.c
--- a-orig/arch/mips/philips/pnx8550/common/proc.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/proc.c	2005-07-15 23:45:33.076418144 +0900
@@ -24,8 +24,8 @@
 
 #include <asm/io.h>
 #include <asm/gdb-stub.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <int.h>
+#include <uart.h>
 
 
 static int pnx8550_timers_read (char* page, char** start, off_t offset, int count, int* eof, void* data)
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/prom.c a/arch/mips/philips/pnx8550/common/prom.c
--- a-orig/arch/mips/philips/pnx8550/common/prom.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/prom.c	2005-07-15 23:45:44.729646584 +0900
@@ -15,7 +15,7 @@
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>
-#include <asm/mach-pnx8550/uart.h>
+#include <uart.h>
 
 /* #define DEBUG_CMDLINE */
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/reset.c a/arch/mips/philips/pnx8550/common/reset.c
--- a-orig/arch/mips/philips/pnx8550/common/reset.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/reset.c	2005-07-15 23:45:55.884950720 +0900
@@ -23,7 +23,7 @@
 #include <linux/config.h>
 #include <linux/slab.h>
 #include <asm/reboot.h>
-#include <asm/mach-pnx8550/glb.h>
+#include <glb.h>
 
 void pnx8550_machine_restart(char *command)
 {
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/setup.c a/arch/mips/philips/pnx8550/common/setup.c
--- a-orig/arch/mips/philips/pnx8550/common/setup.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/setup.c	2005-07-15 23:43:38.693806944 +0900
@@ -33,11 +33,11 @@
 #include <asm/pgtable.h>
 #include <asm/time.h>
 
-#include <asm/mach-pnx8550/glb.h>
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/pci.h>
-#include <asm/mach-pnx8550/uart.h>
-#include <asm/mach-pnx8550/nand.h>
+#include <glb.h>
+#include <int.h>
+#include <pci.h>
+#include <uart.h>
+#include <nand.h>
 
 extern void prom_printf(char *fmt, ...);
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/common/time.c a/arch/mips/philips/pnx8550/common/time.c
--- a-orig/arch/mips/philips/pnx8550/common/time.c	2005-07-15 02:47:58.000000000 +0900
+++ a/arch/mips/philips/pnx8550/common/time.c	2005-07-15 23:46:11.606560672 +0900
@@ -31,8 +31,8 @@
 #include <asm/div64.h>
 #include <asm/debug.h>
 
-#include <asm/mach-pnx8550/int.h>
-#include <asm/mach-pnx8550/cm.h>
+#include <int.h>
+#include <cm.h>
 
 extern unsigned int mips_hpt_frequency;
 
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c a/arch/mips/philips/pnx8550/jbs/board_setup.c
--- a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c	2005-07-15 02:47:59.000000000 +0900
+++ a/arch/mips/philips/pnx8550/jbs/board_setup.c	2005-07-15 23:46:28.102052976 +0900
@@ -39,7 +39,7 @@
 #include <asm/reboot.h>
 #include <asm/pgtable.h>
 
-#include <asm/mach-pnx8550/glb.h>
+#include <glb.h>
 
 /* CP0 hazard avoidance. */
 #define BARRIER __asm__ __volatile__(".set noreorder\n\t" \
diff -urN -X dontdiff a-orig/arch/mips/philips/pnx8550/jbs/irqmap.c a/arch/mips/philips/pnx8550/jbs/irqmap.c
--- a-orig/arch/mips/philips/pnx8550/jbs/irqmap.c	2005-07-15 02:47:59.000000000 +0900
+++ a/arch/mips/philips/pnx8550/jbs/irqmap.c	2005-07-15 23:46:38.463477800 +0900
@@ -26,7 +26,7 @@
  */
 
 #include <linux/init.h>
-#include <asm/mach-pnx8550/int.h>
+#include <int.h>
 
 char irq_tab_jbs[][5] __initdata = {
  [8] =	{ -1, PNX8550_INT_PCI_INTA, 0xff, 0xff, 0xff},

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Sat, Jul 16, 2005 at 12:16:21AM +0900, Yoichi Yuasa wrote:
> Date:	Sat, 16 Jul 2005 00:16:21 +0900
> From:	Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> To:	ppopov@linux-mips.org
> Cc:	yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: text/plain; charset=US-ASCII
> 
> Hi Pete,
> 
> On Thu, 14 Jul 2005 18:48:00 +0100
> ppopov@linux-mips.org wrote:
> 
> > 
> > Log message:
> > 	Philips PNX8550 support: MIPS32-like core with 2 Trimedias on it.
> 
> I think the following include path is better.

>  
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>

What to use really depends on what you want.  I originally created the
mach-* directories to have a place platform-specific header files
instead of infinitely long #ifdef mess.  A buch of -I gcc options are
used to create a search path from the most specific to the most generic
files at the end.  If that's the intend, use the <file.h> form.  If
however the intend is to include a specific file then the prefered
form is <patch/mach-foo/file.h> which avoids the danger of accidently
picking up something else and also is slightly easier for the compiler.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Pete Popov]

--- Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hi Pete,
> 
> On Thu, 14 Jul 2005 18:48:00 +0100
> ppopov@linux-mips.org wrote:
> 
> > 
> > Log message:
> > 	Philips PNX8550 support: MIPS32-like core with 2
> Trimedias on it.
> 
> I think the following include path is better.

Thanks :)! I thought I cleaned up everything ;)

Pete

> 
> Yoichi
> 
> Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> 
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> a/arch/mips/philips/pnx8550/common/gdb_hook.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 23:44:03.361056952 +0900
> @@ -31,7 +31,7 @@
>  #include <asm/serial.h>
>  #include <asm/io.h>
>  
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  static struct serial_state rs_table[RS_TABLE_SIZE]
> = {
>  	SERIAL_PORT_DFNS	/* Defined in serial.h */
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/int.c
> a/arch/mips/philips/pnx8550/common/int.c
> --- a-orig/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 23:44:32.008701848 +0900
> @@ -35,8 +35,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  extern asmlinkage void cp0_irqdispatch(void);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/pci.c
> a/arch/mips/philips/pnx8550/common/pci.c
> --- a-orig/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 23:44:52.444595120 +0900
> @@ -24,9 +24,9 @@
>  #include <linux/kernel.h>
>  #include <linux/init.h>
>  
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <pci.h>
> +#include <glb.h>
> +#include <nand.h>
>  
>  static struct resource pci_io_resource = {
>  	"pci IO space",
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> a/arch/mips/philips/pnx8550/common/platform.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 23:45:16.826888448 +0900
> @@ -17,9 +17,9 @@
>  #include <linux/init.h>
>  #include <linux/resource.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/usb.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <usb.h>
> +#include <uart.h>
>  
>  static struct resource pnx8550_usb_ohci_resources[]
> = {
>  	[0] = {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/proc.c
> a/arch/mips/philips/pnx8550/common/proc.c
> --- a-orig/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 23:45:33.076418144 +0900
> @@ -24,8 +24,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  
>  static int pnx8550_timers_read (char* page, char**
> start, off_t offset, int count, int* eof, void*
> data)
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/prom.c
> a/arch/mips/philips/pnx8550/common/prom.c
> --- a-orig/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 23:45:44.729646584 +0900
> @@ -15,7 +15,7 @@
>  #include <linux/string.h>
>  
>  #include <asm/bootinfo.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  /* #define DEBUG_CMDLINE */
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/reset.c
> a/arch/mips/philips/pnx8550/common/reset.c
> --- a-orig/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 23:45:55.884950720 +0900
> @@ -23,7 +23,7 @@
>  #include <linux/config.h>
>  #include <linux/slab.h>
>  #include <asm/reboot.h>
> -#include <asm/mach-pnx8550/glb.h>
> +#include <glb.h>
>  
>  void pnx8550_machine_restart(char *command)
>  {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/setup.c
> a/arch/mips/philips/pnx8550/common/setup.c
> --- a-orig/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 23:43:38.693806944 +0900
> @@ -33,11 +33,11 @@
>  #include <asm/pgtable.h>
>  #include <asm/time.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/uart.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <glb.h>
> +#include <int.h>
> +#include <pci.h>
> +#include <uart.h>
> +#include <nand.h>
>  
>  extern void prom_printf(char *fmt, ...);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/time.c
> a/arch/mips/philips/pnx8550/common/time.c
> --- a-orig/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 23:46:11.606560672 +0900
> @@ -31,8 +31,8 @@
>  #include <asm/div64.h>
>  #include <asm/debug.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/cm.h>
> +#include <int.h>
> +#include <cm.h>
>  
>  extern unsigned int mips_hpt_frequency;
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> a/arch/mips/philips/pnx8550/jbs/board_setup.c
> ---
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 02:47:59.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 23:46:28.102052976 +0900
> @@ -39,7 +39,7 @@
>  #include <asm/reboot.h>
>  #include <asm/pgtable.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> 
=== message truncated ===

Re: CVS Update@linux-mips.org: linux

[Pete Popov]

--- Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hi Pete,
> 
> On Thu, 14 Jul 2005 18:48:00 +0100
> ppopov@linux-mips.org wrote:
> 
> > 
> > Log message:
> > 	Philips PNX8550 support: MIPS32-like core with 2
> Trimedias on it.
> 
> I think the following include path is better.

Thanks :)! I thought I cleaned up everything ;)

Pete

> 
> Yoichi
> 
> Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
> 
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> a/arch/mips/philips/pnx8550/common/gdb_hook.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/gdb_hook.c
> 2005-07-15 23:44:03.361056952 +0900
> @@ -31,7 +31,7 @@
>  #include <asm/serial.h>
>  #include <asm/io.h>
>  
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  static struct serial_state rs_table[RS_TABLE_SIZE]
> = {
>  	SERIAL_PORT_DFNS	/* Defined in serial.h */
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/int.c
> a/arch/mips/philips/pnx8550/common/int.c
> --- a-orig/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/int.c
> 2005-07-15 23:44:32.008701848 +0900
> @@ -35,8 +35,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  extern asmlinkage void cp0_irqdispatch(void);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/pci.c
> a/arch/mips/philips/pnx8550/common/pci.c
> --- a-orig/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/pci.c
> 2005-07-15 23:44:52.444595120 +0900
> @@ -24,9 +24,9 @@
>  #include <linux/kernel.h>
>  #include <linux/init.h>
>  
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <pci.h>
> +#include <glb.h>
> +#include <nand.h>
>  
>  static struct resource pci_io_resource = {
>  	"pci IO space",
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> a/arch/mips/philips/pnx8550/common/platform.c
> ---
> a-orig/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/platform.c
> 2005-07-15 23:45:16.826888448 +0900
> @@ -17,9 +17,9 @@
>  #include <linux/init.h>
>  #include <linux/resource.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/usb.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <usb.h>
> +#include <uart.h>
>  
>  static struct resource pnx8550_usb_ohci_resources[]
> = {
>  	[0] = {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/proc.c
> a/arch/mips/philips/pnx8550/common/proc.c
> --- a-orig/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/proc.c
> 2005-07-15 23:45:33.076418144 +0900
> @@ -24,8 +24,8 @@
>  
>  #include <asm/io.h>
>  #include <asm/gdb-stub.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <int.h>
> +#include <uart.h>
>  
>  
>  static int pnx8550_timers_read (char* page, char**
> start, off_t offset, int count, int* eof, void*
> data)
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/prom.c
> a/arch/mips/philips/pnx8550/common/prom.c
> --- a-orig/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/prom.c
> 2005-07-15 23:45:44.729646584 +0900
> @@ -15,7 +15,7 @@
>  #include <linux/string.h>
>  
>  #include <asm/bootinfo.h>
> -#include <asm/mach-pnx8550/uart.h>
> +#include <uart.h>
>  
>  /* #define DEBUG_CMDLINE */
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/reset.c
> a/arch/mips/philips/pnx8550/common/reset.c
> --- a-orig/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/reset.c
> 2005-07-15 23:45:55.884950720 +0900
> @@ -23,7 +23,7 @@
>  #include <linux/config.h>
>  #include <linux/slab.h>
>  #include <asm/reboot.h>
> -#include <asm/mach-pnx8550/glb.h>
> +#include <glb.h>
>  
>  void pnx8550_machine_restart(char *command)
>  {
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/setup.c
> a/arch/mips/philips/pnx8550/common/setup.c
> --- a-orig/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/setup.c
> 2005-07-15 23:43:38.693806944 +0900
> @@ -33,11 +33,11 @@
>  #include <asm/pgtable.h>
>  #include <asm/time.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/pci.h>
> -#include <asm/mach-pnx8550/uart.h>
> -#include <asm/mach-pnx8550/nand.h>
> +#include <glb.h>
> +#include <int.h>
> +#include <pci.h>
> +#include <uart.h>
> +#include <nand.h>
>  
>  extern void prom_printf(char *fmt, ...);
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/common/time.c
> a/arch/mips/philips/pnx8550/common/time.c
> --- a-orig/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 02:47:58.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/common/time.c
> 2005-07-15 23:46:11.606560672 +0900
> @@ -31,8 +31,8 @@
>  #include <asm/div64.h>
>  #include <asm/debug.h>
>  
> -#include <asm/mach-pnx8550/int.h>
> -#include <asm/mach-pnx8550/cm.h>
> +#include <int.h>
> +#include <cm.h>
>  
>  extern unsigned int mips_hpt_frequency;
>  
> diff -urN -X dontdiff
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> a/arch/mips/philips/pnx8550/jbs/board_setup.c
> ---
> a-orig/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 02:47:59.000000000 +0900
> +++ a/arch/mips/philips/pnx8550/jbs/board_setup.c
> 2005-07-15 23:46:28.102052976 +0900
> @@ -39,7 +39,7 @@
>  #include <asm/reboot.h>
>  #include <asm/pgtable.h>
>  
> -#include <asm/mach-pnx8550/glb.h>
> 
=== message truncated ===

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 14 Jul 2005 ppopov@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: pgtable.h 
> 	include/asm-mips/mach-au1x00: ioremap.h 
> 
> Log message:
> 	Fix the fixup_bigphys_addr compile problem.

 Hmm, I think you should include <ioremap.h> instead as that's the header 
and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Pete Popov]

On Thu, 2005-07-14 at 16:35 +0100, Maciej W. Rozycki wrote:
> On Thu, 14 Jul 2005 ppopov@linux-mips.org wrote:
> 
> > Modified files:
> > 	include/asm-mips: pgtable.h 
> > 	include/asm-mips/mach-au1x00: ioremap.h 
> > 
> > Log message:
> > 	Fix the fixup_bigphys_addr compile problem.
> 
>  Hmm, I think you should include <ioremap.h> instead as that's the header 
> and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.

I think I did and it couldn't pick up the right one since we have the
generic one and then the cpu specific version.

Pete

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 14 Jul 2005, Pete Popov wrote:

> >  Hmm, I think you should include <ioremap.h> instead as that's the header 
> > and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.
> 
> I think I did and it couldn't pick up the right one since we have the
> generic one and then the cpu specific version.

 That would be strange -- the system-specific one (note it's not 
CPU-specific) should precede the generic one in the inclusion path list.  
And how does <asm/io.h> pick the right one then?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Pete Popov]

On Thu, 2005-07-14 at 16:59 +0100, Maciej W. Rozycki wrote:
> On Thu, 14 Jul 2005, Pete Popov wrote:
> 
> > >  Hmm, I think you should include <ioremap.h> instead as that's the header 
> > > and not <asm/io.h> that provides the necessary bit for <asm/pgtable.h>.
> > 
> > I think I did and it couldn't pick up the right one since we have the
> > generic one and then the cpu specific version.
> 
>  That would be strange -- the system-specific one (note it's not 
> CPU-specific) should precede the generic one in the inclusion path list.  
> And how does <asm/io.h> pick the right one then?

No idea, didn't spend enough time on it. I'll do another compile with
ioremap.h instead and see what the problem was and if it can be easily
fixed.

Pete

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Tue, 12 Jul 2005 ralf@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: interrupt.h 
> 
> Log message:
> 	Use ei / di MIPS32 R2 instructions if available.

 Are you sure you don't want something like:

	andi	$1, \\flags, 1
	beqz    $1, 1f                                     
	 di                                                     
	ei                                                      
1:                                                             

instead for local_irq_restore?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Jul 11, 2005 at 06:06:07PM +0100, macro@linux-mips.org wrote:

> Modified files:
> 	arch/mips/configs: decstation_defconfig 
> 
> Log message:
> 	Who needs module versions?

Generally considered a good idea ...

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Mon, 11 Jul 2005, Ralf Baechle wrote:

> > Log message:
> > 	Who needs module versions?
> 
> Generally considered a good idea ...

 Generally most useful for binary-only modules.  Do we have any for the 
DECstation?  If you update "vmlinux", you can also update modules.  Other 
platforms get away without versioning by default -- I see no reason to be 
different here.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Jul 11, 2005 at 06:44:31PM +0100, Maciej W. Rozycki wrote:

> > Generally considered a good idea ...
> 
>  Generally most useful for binary-only modules.  Do we have any for the 
> DECstation?  If you update "vmlinux", you can also update modules.  Other 
> platforms get away without versioning by default -- I see no reason to be 
> different here.

If there's a mistake that people can do they will rarely miss that
opportunity.  Desperate users tend to move modules from their
distribution into a kernel built from CVS or change kernel config options
and somehow manage to keep a few modules built with the old options etc.
It's no fun receiving bug reports only to later figure out it was just
a silly pilot error, so for anything that's going to the net I really
keep that option on.

Of course I'd disable it for a closed appliance nor do I keep it turned
on for my own builds.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Mon, 11 Jul 2005, Ralf Baechle wrote:

> If there's a mistake that people can do they will rarely miss that
> opportunity.  Desperate users tend to move modules from their
> distribution into a kernel built from CVS or change kernel config options
> and somehow manage to keep a few modules built with the old options etc.

 Hmm...

> It's no fun receiving bug reports only to later figure out it was just
> a silly pilot error, so for anything that's going to the net I really
> keep that option on.

 Well, I receive virtually zero bug reports for the DECstation.  The code 
must be perfect. ;-)

> Of course I'd disable it for a closed appliance nor do I keep it turned
> on for my own builds.

 We'll see.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Mon, 11 Jul 2005, Ralf Baechle wrote:
> 
> > If there's a mistake that people can do they will rarely miss that
> > opportunity.  Desperate users tend to move modules from their
> > distribution into a kernel built from CVS or change kernel config options
> > and somehow manage to keep a few modules built with the old options etc.
> 
>  Hmm...
> 
> > It's no fun receiving bug reports only to later figure out it was just
> > a silly pilot error, so for anything that's going to the net I really
> > keep that option on.
> 
>  Well, I receive virtually zero bug reports for the DECstation.  The code 
> must be perfect. ;-)

I hope to change that with a 2.6 DECstation kernel for Debian. :-)


Thiemo

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Mon, 11 Jul 2005, Thiemo Seufer wrote:

> >  Well, I receive virtually zero bug reports for the DECstation.  The code 
> > must be perfect. ;-)
> 
> I hope to change that with a 2.6 DECstation kernel for Debian. :-)

 Oh, no, no, no...  I definitely object you making the code imperfect.  
Over my dead body!

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Jul 11, 2005 at 09:35:31AM +0100, ths@linux-mips.org wrote:
> From:	ths@linux-mips.org
> To:	linux-cvs-patches@linux-mips.org
> Subject: CVS Update@linux-mips.org: linux
> Date:	Mon, 11 Jul 2005 09:35:31 +0100
> 
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/07/11 09:35:25
> 
> Modified files:
> 	.              : Makefile 
> 
> Log message:
> 	Use the mainline way to handle this.

Yanked.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 7 Jul 2005 ths@linux-mips.org wrote:

> Log message:
> 	Hack to make compiles for the other endianness easier.

 Why have you complicated it that much?  AFAIK:

cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -meb
cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mel

would work just fine with all GCC versions supported (i.e. including 
2.95.x).  It's true "-EL" and "-EB" are broken, also with 4.0.0 (not sure 
if afterwards) -- it's related to an incorrect setup for the default specs 
for Linux, but it can be avoided using these alternative options as above.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005 ths@linux-mips.org wrote:
> 
> > Log message:
> > 	Hack to make compiles for the other endianness easier.
> 
>  Why have you complicated it that much?  AFAIK:
> 
> cflags-$(CONFIG_CPU_BIG_ENDIAN)		+= -meb
> cflags-$(CONFIG_CPU_LITTLE_ENDIAN)	+= -mel
> 
> would work just fine with all GCC versions supported (i.e. including 
> 2.95.x).  It's true "-EL" and "-EB" are broken, also with 4.0.0 (not sure 
> if afterwards) -- it's related to an incorrect setup for the default specs 
> for Linux, but it can be avoided using these alternative options as above.

-mel/-meb aren't documented.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 7 Jul 2005, Thiemo Seufer wrote:

> -mel/-meb aren't documented.

 They are:

$ gcc -v --help 2>/dev/null | egrep 'mel|meb'
  -mel                      Use little-endian byte order
  -meb                      Use big-endian byte order

They are not in the info pages, but that should probably be considered an 
accidental omission.  Is using something that's documented but doesn't 
work, to the contrary, any better?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > -mel/-meb aren't documented.
> 
>  They are:
> 
> $ gcc -v --help 2>/dev/null | egrep 'mel|meb'
>   -mel                      Use little-endian byte order
>   -meb                      Use big-endian byte order
> 
> They are not in the info pages, but that should probably be considered an 
> accidental omission.  Is using something that's documented but doesn't 
> work, to the contrary, any better?

Probably not. It's just that I've never seen actual use of -mel/-meb yet.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 7 Jul 2005, Thiemo Seufer wrote:

> > They are not in the info pages, but that should probably be considered an 
> > accidental omission.  Is using something that's documented but doesn't 
> > work, to the contrary, any better?
> 
> Probably not. It's just that I've never seen actual use of -mel/-meb yet.

 Good -- it means you haven't been watching over my shoulder. ;-)  I've 
used them several times for big-endian builds with my toolchain, which, as 
you may be aware, has been exclusively little-endian so far.

 And they are actually used to implement these "-EL" and "-EB" options.  
Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
generally imply target-specific options.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > > They are not in the info pages, but that should probably be considered an 
> > > accidental omission.  Is using something that's documented but doesn't 
> > > work, to the contrary, any better?
> > 
> > Probably not. It's just that I've never seen actual use of -mel/-meb yet.
> 
>  Good -- it means you haven't been watching over my shoulder. ;-)  I've 
> used them several times for big-endian builds with my toolchain, which, as 
> you may be aware, has been exclusively little-endian so far.
> 
>  And they are actually used to implement these "-EL" and "-EB" options.  
> Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> generally imply target-specific options.

Other gcc targets use IIRC -BE and -LE. It might be worthwile to document
-mel/-meb better, use them generally in gcc, and then mark the uppercase
options as deprecated.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle DL5RB]

On Thu, Jul 07, 2005 at 02:01:11PM +0100, Maciej W. Rozycki wrote:
> Date:	Thu, 7 Jul 2005 14:01:11 +0100 (BST)
> From:	"Maciej W. Rozycki" <macro@linux-mips.org>
> To:	Thiemo Seufer <ths@networkno.de>
> Cc:	linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Thu, 7 Jul 2005, Thiemo Seufer wrote:
> 
> > > They are not in the info pages, but that should probably be considered an 
> > > accidental omission.  Is using something that's documented but doesn't 
> > > work, to the contrary, any better?
> > 
> > Probably not. It's just that I've never seen actual use of -mel/-meb yet.
> 
>  Good -- it means you haven't been watching over my shoulder. ;-)  I've 
> used them several times for big-endian builds with my toolchain, which, as 
> you may be aware, has been exclusively little-endian so far.
> 
>  And they are actually used to implement these "-EL" and "-EB" options.  
> Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> generally imply target-specific options.

-EB / -EL are traditionally the options that all MIPS compilers including
non-gcc compilers, seem to support.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Thu, 7 Jul 2005, Ralf Baechle DL5RB wrote:

> >  And they are actually used to implement these "-EL" and "-EB" options.  
> > Frankly I find "-mel" and "-meb" more consistent with the others as "-m*" 
> > generally imply target-specific options.
> 
> -EB / -EL are traditionally the options that all MIPS compilers including
> non-gcc compilers, seem to support.

 That's probably why they are there in GCC at all, but they are rather 
inconsistent with the rest of GCC options and we rely on GCC for builds 
anyway, so who cares?

  Maciej

Re: CVS Update@linux-mips.org: linux

[Richard Sandiford]

Ralf Baechle DL5RB <ralf@linux-mips.org> writes:
> -EB / -EL are traditionally the options that all MIPS compilers including
> non-gcc compilers, seem to support.

Right.  I've always thought of them as the canonical options for gcc
as well.  I think the only reason internal compilers like cc1 have
-mel and -meb is because gcc's target options system has traditionally
required every target option to begin with "-m".  (That's no longer
a restriction in 4.1 FWIW.)

So contrary to what was said upthread, I've always treated
the omission of these options from invoke.texi as deliberate.
They're really internal compiler flags rather than user flags.
You should use -EL and -EB instead.

Richard

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 8 Jul 2005, Richard Sandiford wrote:

> Right.  I've always thought of them as the canonical options for gcc
> as well.  I think the only reason internal compilers like cc1 have
> -mel and -meb is because gcc's target options system has traditionally
> required every target option to begin with "-m".  (That's no longer
> a restriction in 4.1 FWIW.)

 I'm not sure relaxing this restriction is actually a good idea -- there 
may be tools external to GCC that make this assumption for additional 
handling of options passed to GCC.  I could imagine libtool being 
sensitive, for example (but that's just an assumption -- I haven't checked 
it).  And this classification of options -- "-f*" for optimization tweaks 
and "-m*" for target-dependent ones -- seems to be useful for humans (or 
at least one), too, as one does not to have to resort to documentation for 
every option encountered in Makefiles to have an idea about it.

> So contrary to what was said upthread, I've always treated
> the omission of these options from invoke.texi as deliberate.

 OK, I stand corrected.

> They're really internal compiler flags rather than user flags.

 Which actually happen to work...

> You should use -EL and -EB instead.

 ... unlike these.

 FWIW, I prepared the following patch for GCC 3.4.x the other day -- would 
you care to verify whether it's still needed for 4.x?  It may be worth 
applying to 3.4, too -- I think the branch hasn't got closed yet, has it?

2005-07-08  Maciej W. Rozycki  <macro@mips.com>

	* config/mips/linux.h (CC1_SPEC): Override defaults from
	config/linux.h.

 Unfortunately it won't let us remove the newly introduced hackery from 
Linux as (unlike you) we need to support versions back to 2.95.x.  
Therefore I sustain my proposal to use "-mel" and "-meb" as more reliable 
-- I'm pretty sure they used to work for 2.95.x, too.

  Maciej

gcc-3.4.4-20050617-linux-cc1-spec-0.patch
--- gcc/gcc/config/mips/linux.h	30 Jul 2004 15:33:08 -0000
+++ gcc/gcc/config/mips/linux.h	17 Jun 2005 19:59:20 -0000
@@ -101,6 +101,16 @@ Boston, MA 02111-1307, USA.  */
 %{fPIC|fPIE|fpic|fpie:-D__PIC__ -D__pic__} \
 %{pthread:-D_REENTRANT}"
 
+/* Merged from linux.h and mips/mips.h.  */
+#undef CC1_SPEC
+#define CC1_SPEC "\
+%{profile:-p} \
+%{gline:%{!g:%{!g0:%{!g1:%{!g2: -g1}}}}} \
+%{mips16*:%{!fno-section-relative-addressing:-fsection-relative-addressing -fno-common}} \
+%{fsection-relative-addressing:-fno-common} \
+%{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} \
+%(subtarget_cc1_spec)"
+
 /* From iris5.h */
 /* -G is incompatible with -KPIC which is the default, so only allow objects
    in the small data section if the user explicitly asks for it.  */

Re: CVS Update@linux-mips.org: linux

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
> On Fri, 8 Jul 2005, Richard Sandiford wrote:
>> Right.  I've always thought of them as the canonical options for gcc
>> as well.  I think the only reason internal compilers like cc1 have
>> -mel and -meb is because gcc's target options system has traditionally
>> required every target option to begin with "-m".  (That's no longer
>> a restriction in 4.1 FWIW.)
>
>  I'm not sure relaxing this restriction is actually a good idea -- there 
> may be tools external to GCC that make this assumption for additional
> handling of options passed to GCC.

Oh, I agree that targets shouldn't gratuitously add non -m options.
All I meant was that, if a target does decide to support compatibility
options like -EB or -EL (or -BE or -LE), the new intrastructure allows
you to do it directly, rather than introduce internal forwarding options
like -meb or -mel.  Forwarding options can cause the sort of confusion
we've seen here.

If we have a clean slate, and no compatibility worries, I agree that
it's better to use -m options across the board.

>  FWIW, I prepared the following patch for GCC 3.4.x the other day -- would 
> you care to verify whether it's still needed for 4.x?  It may be worth
> applying to 3.4, too -- I think the branch hasn't got closed yet, has it?

A quick look at the code suggests that it is still needed for 4.x, yes.

> 2005-07-08  Maciej W. Rozycki  <macro@mips.com>
>
> 	* config/mips/linux.h (CC1_SPEC): Override defaults from
> 	config/linux.h.

Looks reasonable, but I think you should just set SUBTARGET_CC1_SPEC
to the normal linux.h definition of CC1_SPEC.  There shouldn't be
any need to redefine CC1_SPEC itself (with all the mips.h duplication
that that implies).  It'll be easier to keep things in sync that way.

>  Unfortunately it won't let us remove the newly introduced hackery from 
> Linux as (unlike you) we need to support versions back to 2.95.x.

Understood.

Richard

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 8 Jul 2005, Richard Sandiford wrote:

> > 2005-07-08  Maciej W. Rozycki  <macro@mips.com>
> >
> > 	* config/mips/linux.h (CC1_SPEC): Override defaults from
> > 	config/linux.h.
> 
> Looks reasonable, but I think you should just set SUBTARGET_CC1_SPEC
> to the normal linux.h definition of CC1_SPEC.  There shouldn't be
> any need to redefine CC1_SPEC itself (with all the mips.h duplication
> that that implies).  It'll be easier to keep things in sync that way.

 The problem is config/linux.h defines CC1_SPEC before config/mips.h is 
included and as a result the latter does not redefine it.  I feared 
changing "#ifdef CC1_SPEC ... #endif" to "#undef CC1_SPEC" would break 
other targets -- there are too many of them and the dependencies are too 
scattered for me to dare fiddling with this macro (proof-reading is futile 
and testing every configuration impossible).  At least this change is 
guaranteed to affect only Linux.  But I would encourage you, as the 
maintainer, to get a more consistent general arrangement and I can do 
testing for configurations I have access to.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Sat, 18 Jun 2005 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips/configs: decstation_defconfig 
> 
> Log message:
> 	Grrr..  Update the bloody thing when you change the kconfig files.

 Who cares at this point, anyway?... ;-)

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Sun, Jun 05, 2005 at 04:57:20AM +0100, sjhill@linux-mips.org wrote:

> Modified files:
> 	arch/mips      : Kconfig 
> 
> Log message:
> 	The DbAu1500 board also support big endian. Gee, imagine that.

Maybe.  In the past our Kconfig rsp. Config.in was not endianess-aware,
so I did make a few mistakes when I added that.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jun 03, 2005 at 03:21:13AM +0100, ths@linux-mips.org wrote:

> Log message:
> 	Fix R4[04]00 hazards breakage.
> 
> diff -urN linux/arch/mips/mm/tlbex-r4k.S linux/arch/mips/mm/tlbex-r4k.S
> --- linux/arch/mips/mm/Attic/tlbex-r4k.S	2004/11/25 22:18:38	1.2.2.19
> +++ linux/arch/mips/mm/Attic/tlbex-r4k.S	2005/06/03 02:21:06	1.2.2.20
> @@ -186,6 +186,7 @@
>  	P_MTC0	k1, CP0_ENTRYLO1		# load it
>  	mtc0_tlbw_hazard
>  	tlbwr					# write random tlb entry
> +	nop
>  	tlbw_eret_hazard

I did previously object to a similar patch - why not fix tlbw_eret_hazard
instead.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Jun 03, 2005 at 03:21:13AM +0100, ths@linux-mips.org wrote:
> 
> > Log message:
> > 	Fix R4[04]00 hazards breakage.
> > 
> > diff -urN linux/arch/mips/mm/tlbex-r4k.S linux/arch/mips/mm/tlbex-r4k.S
> > --- linux/arch/mips/mm/Attic/tlbex-r4k.S	2004/11/25 22:18:38	1.2.2.19
> > +++ linux/arch/mips/mm/Attic/tlbex-r4k.S	2005/06/03 02:21:06	1.2.2.20
> > @@ -186,6 +186,7 @@
> >  	P_MTC0	k1, CP0_ENTRYLO1		# load it
> >  	mtc0_tlbw_hazard
> >  	tlbwr					# write random tlb entry
> > +	nop
> >  	tlbw_eret_hazard
> 
> I did previously object to a similar patch

I didn't know that, IIRC a similiar patch went in 2.6 before the synthesized
TLB handlers were done.

> - why not fix tlbw_eret_hazard instead.

Like this?


Thiemo


Index: arch/mips/mm/tlbex-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/Attic/tlbex-r4k.S,v
retrieving revision 1.2.2.20
diff -u -p -r1.2.2.20 tlbex-r4k.S
--- arch/mips/mm/tlbex-r4k.S	3 Jun 2005 02:21:06 -0000	1.2.2.20
+++ arch/mips/mm/tlbex-r4k.S	3 Jun 2005 10:16:28 -0000
@@ -186,7 +186,6 @@
 	P_MTC0	k1, CP0_ENTRYLO1		# load it
 	mtc0_tlbw_hazard
 	tlbwr					# write random tlb entry
-	nop
 	tlbw_eret_hazard
 	eret
 	END(except_vec0_r4000)
@@ -468,7 +467,6 @@ invalid_tlbl:
 	PTE_RELOAD(k1, k0)
 	mtc0_tlbw_hazard
 	tlbwi
-	nop
 	tlbw_eret_hazard
 	.set	mips3
 	eret
@@ -493,7 +491,6 @@ nopage_tlbl:
 	PTE_RELOAD(k1, k0)
 	mtc0_tlbw_hazard
 	tlbwi
-	nop
 	tlbw_eret_hazard
 	.set	mips3
 	eret
@@ -523,7 +520,6 @@ nopage_tlbs:
 	PTE_RELOAD(k1, k0)
 	mtc0_tlbw_hazard
 	tlbwi
-	nop
 	tlbw_eret_hazard
 	.set	mips3
 	eret
Index: arch/mips64/mm/tlbex-r4k.S
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/Attic/tlbex-r4k.S,v
retrieving revision 1.1.2.20
diff -u -p -r1.1.2.20 tlbex-r4k.S
--- arch/mips64/mm/tlbex-r4k.S	3 Jun 2005 02:21:07 -0000	1.1.2.20
+++ arch/mips64/mm/tlbex-r4k.S	3 Jun 2005 10:16:28 -0000
@@ -125,6 +125,33 @@ LEAF(except_vec1_r4k)
 	 nop
 END(except_vec1_r4k)
 
+	__FINIT
+
+	.align  5
+LEAF(handle_vec1_r4k)
+	.set    noat
+	LOAD_PTE2 k1 k0 9f
+	ld	k0, 0(k1)			# get even pte
+	ld	k1, 8(k1)			# get odd pte
+	PTE_RELOAD k0 k1
+	mtc0_tlbw_hazard
+	tlbwr
+	tlbw_eret_hazard
+	eret
+
+9:						# handle the vmalloc range
+	LOAD_KPTE2 k1 k0 invalid_vmalloc_address
+	ld	k0, 0(k1)			# get even pte
+	ld	k1, 8(k1)			# get odd pte
+	PTE_RELOAD k0 k1
+	mtc0_tlbw_hazard
+	tlbwr
+	tlbw_eret_hazard
+	eret
+END(handle_vec1_r4k)
+
+	__INIT
+
 LEAF(except_vec1_sb1)
 #if BCM1250_M3_WAR
 	dmfc0	k0, CP0_BADVADDR
@@ -134,18 +161,17 @@ LEAF(except_vec1_sb1)
 	bnez	k0, 1f
 #endif
 	.set    noat
-	dla     k0, handle_vec1_r4k
+	dla     k0, handle_vec1_sb1
 	jr      k0
 	 nop
 
 1:	eret
-	nop
 END(except_vec1_sb1)
 
 	__FINIT
 
 	.align  5
-LEAF(handle_vec1_r4k)
+LEAF(handle_vec1_sb1)
 	.set    noat
 	LOAD_PTE2 k1 k0 9f
 	ld	k0, 0(k1)			# get even pte
@@ -153,7 +179,6 @@ LEAF(handle_vec1_r4k)
 	PTE_RELOAD k0 k1
 	mtc0_tlbw_hazard
 	tlbwr
-1:	tlbw_eret_hazard
 	eret
 
 9:						# handle the vmalloc range
@@ -163,10 +188,8 @@ LEAF(handle_vec1_r4k)
 	PTE_RELOAD k0 k1
 	mtc0_tlbw_hazard
 	tlbwr
-	nop
-1:	tlbw_eret_hazard
 	eret
-END(handle_vec1_r4k)
+END(handle_vec1_sb1)
 
 
 	__INIT
@@ -194,7 +217,6 @@ LEAF(handle_vec1_r10k)
 	PTE_RELOAD k0 k1
 	mtc0_tlbw_hazard
 	tlbwr
-	tlbw_eret_hazard
 	eret
 
 9:						# handle the vmalloc range
@@ -204,7 +226,6 @@ LEAF(handle_vec1_r10k)
 	PTE_RELOAD k0 k1
 	mtc0_tlbw_hazard
 	tlbwr
-	tlbw_eret_hazard
 	eret
 END(handle_vec1_r10k)
 
Index: include/asm-mips/hazards.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/hazards.h,v
retrieving revision 1.1.2.3
diff -u -p -r1.1.2.3 hazards.h
--- include/asm-mips/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
+++ include/asm-mips/hazards.h	3 Jun 2005 10:16:28 -0000
@@ -46,6 +46,7 @@
 #define mtc0_tlbw_hazard						\
 	b	. + 8
 #define tlbw_eret_hazard
+	nop
 #endif
 
 /*
Index: include/asm-mips64/hazards.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/Attic/hazards.h,v
retrieving revision 1.1.2.3
diff -u -p -r1.1.2.3 hazards.h
--- include/asm-mips64/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
+++ include/asm-mips64/hazards.h	3 Jun 2005 10:16:28 -0000
@@ -46,6 +46,7 @@
 #define mtc0_tlbw_hazard						\
 	b	. + 8
 #define tlbw_eret_hazard
+	nop
 #endif
 
 /*

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jun 03, 2005 at 12:21:40PM +0200, Thiemo Seufer wrote:

> > I did previously object to a similar patch
> 
> I didn't know that, IIRC a similiar patch went in 2.6 before the synthesized
> TLB handlers were done.
> 
> > - why not fix tlbw_eret_hazard instead.
> 
> Like this?

Yes, that seems more like it.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Fri, 3 Jun 2005, Thiemo Seufer wrote:
> --- include/asm-mips/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
> +++ include/asm-mips/hazards.h	3 Jun 2005 10:16:28 -0000
> @@ -46,6 +46,7 @@
>  #define mtc0_tlbw_hazard						\
>  	b	. + 8
>  #define tlbw_eret_hazard

Missing backslash at end of line?

> +	nop
>  #endif
>  
>  /*
> Index: include/asm-mips64/hazards.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips64/Attic/hazards.h,v
> retrieving revision 1.1.2.3
> diff -u -p -r1.1.2.3 hazards.h
> --- include/asm-mips64/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
> +++ include/asm-mips64/hazards.h	3 Jun 2005 10:16:28 -0000
> @@ -46,6 +46,7 @@
>  #define mtc0_tlbw_hazard						\
>  	b	. + 8
>  #define tlbw_eret_hazard

Missing backslash at end of line?

> +	nop
>  #endif

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

[Ralf Baechle]

On Fri, Jun 03, 2005 at 01:12:03PM +0200, Geert Uytterhoeven wrote:

> On Fri, 3 Jun 2005, Thiemo Seufer wrote:
> > --- include/asm-mips/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
> > +++ include/asm-mips/hazards.h	3 Jun 2005 10:16:28 -0000
> > @@ -46,6 +46,7 @@
> >  #define mtc0_tlbw_hazard						\
> >  	b	. + 8
> >  #define tlbw_eret_hazard
> 
> Missing backslash at end of line?


Some processors have a 0-cycle hazard between a tlb write and eret.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Fri, 3 Jun 2005, Ralf Baechle wrote:
> On Fri, Jun 03, 2005 at 01:12:03PM +0200, Geert Uytterhoeven wrote:
> > On Fri, 3 Jun 2005, Thiemo Seufer wrote:
> > > --- include/asm-mips/hazards.h	3 Jun 2005 02:21:07 -0000	1.1.2.3
> > > +++ include/asm-mips/hazards.h	3 Jun 2005 10:16:28 -0000
> > > @@ -46,6 +46,7 @@
> > >  #define mtc0_tlbw_hazard						\
> > >  	b	. + 8
> > >  #define tlbw_eret_hazard
> > 
> > Missing backslash at end of line?
> 
> 
> Some processors have a 0-cycle hazard between a tlb write and eret.

I understand. But unless I'm mistaken, the compiler will complain about the
lonely `nop' if the preceding line doesn't end with a backslash.

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

[Maciej W. Rozycki]

On Fri, 6 May 2005 ralf@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	05/05/06 15:31:13
> 
> Modified files:
> 	arch/mips/kernel: cpu-probe.c 
> 
> Log message:
> 	No point in checking cpu_has_tlb before we've computed the CPU options.

 ???  decode_config0() sets up the CPU option in question, so doing a 
check after decode_configs() is fine.

> 	So for now we just unconditionally set the option - Linux wouldn't
> 	work without a TLB anyway.

 I don't like the idea -- bits shouldn't be scattered all over the place, 
so that all the places need to be chased and fixed once conditions change.  

 Instead of polluting all the cpu_probe_*() functions, it should actually 
be moved to decode_config0().  I can apply a suitable fix.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 6 May 2005, Maciej W. Rozycki wrote:

>  Instead of polluting all the cpu_probe_*() functions, it should actually 
> be moved to decode_config0().  I can apply a suitable fix.

 How about this?

  Maciej

patch-mips-2.6.12-rc3-20050506-4ktlb-0
Index: arch/mips/kernel/cpu-probe.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/cpu-probe.c,v
retrieving revision 1.46
diff -u -p -r1.46 cpu-probe.c
--- arch/mips/kernel/cpu-probe.c	6 May 2005 14:31:13 -0000	1.46
+++ arch/mips/kernel/cpu-probe.c	6 May 2005 18:10:01 -0000
@@ -429,7 +429,7 @@ static inline unsigned int decode_config
 	config0 = read_c0_config();
 
 	if (((config0 & MIPS_CONF_MT) >> 7) == 1)
-		c->options |= MIPS_CPU_TLB;
+		c->options |= MIPS_CPU_TLB | MIPS_CPU_4KTLB;
 	isa = (config0 & MIPS_CONF_AT) >> 13;
 	switch (isa) {
 	case 0:
@@ -515,7 +515,6 @@ static inline void decode_configs(struct
 static inline void cpu_probe_mips(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_4KC:
 		c->cputype = CPU_4KC;
@@ -549,7 +548,6 @@ static inline void cpu_probe_mips(struct
 static inline void cpu_probe_alchemy(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_AU1_REV1:
 	case PRID_IMP_AU1_REV2:
@@ -580,7 +578,6 @@ static inline void cpu_probe_alchemy(str
 static inline void cpu_probe_sibyte(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SB1:
 		c->cputype = CPU_SB1;
@@ -595,7 +592,6 @@ static inline void cpu_probe_sibyte(stru
 static inline void cpu_probe_sandcraft(struct cpuinfo_mips *c)
 {
 	decode_configs(c);
-	c->options |= MIPS_CPU_4KTLB;
 	switch (c->processor_id & 0xff00) {
 	case PRID_IMP_SR71000:
 		c->cputype = CPU_SR71000;

Re: CVS Update@linux-mips.org: linux

[Christoph Hellwig]

On Tue, Apr 12, 2005 at 03:00:38PM +0100, ths@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ths@ftp.linux-mips.org	05/04/12 15:00:38
> 
> Modified files:
> 	drivers/scsi   : sgiwd93.c 
> Removed files:
> 	drivers/scsi   : sgiwd93.h 
> 
> Log message:
> 	Enable proc support, minor code cleanup.

Haven't seen the diffs, but please don't add new ->proc_info methods.
It's deprecated and will go away in the not very distant future.

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Christoph Hellwig wrote:
> On Tue, Apr 12, 2005 at 03:00:38PM +0100, ths@linux-mips.org wrote:
> > 
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ths@ftp.linux-mips.org	05/04/12 15:00:38
> > 
> > Modified files:
> > 	drivers/scsi   : sgiwd93.c 
> > Removed files:
> > 	drivers/scsi   : sgiwd93.h 
> > 
> > Log message:
> > 	Enable proc support, minor code cleanup.
> 
> Haven't seen the diffs, but please don't add new ->proc_info methods.
> It's deprecated and will go away in the not very distant future.

The comments in scsi_host.s leave no doubt about that. :-)
The function isn't exactly new, the sgiwd driver reuses the generic
wd function.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

macro@linux-mips.org wrote:
> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	macro@ftp.linux-mips.org	05/04/01 18:53:33
> 
> Modified files:
> 	arch/mips/mm   : pg-sb1.c 
> 
> Log message:
> 	Remove useless casts.  Fix formatting.

This patch leads for 64bit kernels to:

  CC      arch/mips/mm/pg-sb1.o
arch/mips/mm/pg-sb1.c: In function `sb1_dma_init':
arch/mips/mm/pg-sb1.c:220: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c:225: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type
arch/mips/mm/pg-sb1.c:226: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type
arch/mips/mm/pg-sb1.c:227: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type
arch/mips/mm/pg-sb1.c: In function `clear_page':
arch/mips/mm/pg-sb1.c:233: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c:237: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c: In function `copy_page':
arch/mips/mm/pg-sb1.c:257: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c:258: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c:262: warning: cast from pointer to integer of different size
arch/mips/mm/pg-sb1.c:263: warning: cast from pointer to integer of different size

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Sat, 2 Apr 2005, Thiemo Seufer wrote:

> > Log message:
> > 	Remove useless casts.  Fix formatting.
> 
> This patch leads for 64bit kernels to:
> 
>   CC      arch/mips/mm/pg-sb1.o
> arch/mips/mm/pg-sb1.c: In function `sb1_dma_init':
> arch/mips/mm/pg-sb1.c:220: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c:225: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type
> arch/mips/mm/pg-sb1.c:226: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type
> arch/mips/mm/pg-sb1.c:227: warning: passing arg 2 of `__raw_writeq' discards qualifiers from pointer target type

 Thanks for pointing this out.  That "const" shouldn't be on "base_reg" 
there, of course.  I'm committing a fix right now.  My apologies for 
inadequate testing.

> arch/mips/mm/pg-sb1.c: In function `clear_page':
> arch/mips/mm/pg-sb1.c:233: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c:237: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c: In function `copy_page':
> arch/mips/mm/pg-sb1.c:257: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c:258: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c:262: warning: cast from pointer to integer of different size
> arch/mips/mm/pg-sb1.c:263: warning: cast from pointer to integer of different size

 These are unrelated.  Essentially "CPHYSADDR(foo)" expands to 
"(int)(foo)" (that is, after having removed some unrelated bits) and it's 
not going to work in a portable way if "foo" is a pointer...  Thanks for 
your report though -- this code needs a rewrite for a proper 64-bit 
support and I'll try to have a look at it.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 4 Mar 2005 ralf@linux-mips.org wrote:

> Log message:
> 	On Qube2700 Galileo hangs if we access slot #6.

 Device #31 is reserved with Galileo controllers for generating special 
cycles.  Thus it's a feature rather than an erratum and I think it's worth 
being properly documented in the sources.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 25 Feb 2005 ths@linux-mips.org wrote:

> Modified files:
> 	drivers/i2c/busses: i2c-sibyte.c 
> 
> Log message:
> 	Fix 64bit builds.

 Well, these should actually be converted to ioremap()...

  Maciej

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 25 Feb 2005 ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/mm   : pg-sb1.c 
> 
> Log message:
> 	Fix initialization. Unbreak the wait-for-completion loops. Code cleanup.

 Don't use a cast on IOADDR() -- it already returns "void *".  The casts 
obfuscate code and make it difficult to spot incorrect use if the API ever 
changes.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Feb 14, 2005 at 03:53:03AM +0000, macro@linux-mips.org wrote:

> Modified files:
> 	arch/mips64/kernel: Tag: linux_2_4 scall_o32.S 
> 
> Log message:
> 	Gas no longer supports redefining macros.

Bulletproofing 2.4 against newer tools is something that only makes limited
sense, especially wrt. to gcc 3.4 and newer.  Chances for any such changes
to be accepted upstream are slim - and the kernel has traditionally been
easily affected by overoptimization, so I recommend against gcc 3.4.  The
recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto
gcc 3.3 is reasonable and can be considered well tested.

  Ralf

Re: CVS Update@linux-mips.org: linux

[sjhill]

> Bulletproofing 2.4 against newer tools is something that only makes limited
> sense, especially wrt. to gcc 3.4 and newer.  Chances for any such changes
> to be accepted upstream are slim - and the kernel has traditionally been
> easily affected by overoptimization, so I recommend against gcc 3.4.  The
> recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto
> gcc 3.3 is reasonable and can be considered well tested.
> 
gcc 3.2 has problems with certain optimizations as well. 3.2 should be
used with caution.

-Steve

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Mon, 14 Feb 2005, Ralf Baechle wrote:

> > Modified files:
> > 	arch/mips64/kernel: Tag: linux_2_4 scall_o32.S 
> > 
> > Log message:
> > 	Gas no longer supports redefining macros.
> 
> Bulletproofing 2.4 against newer tools is something that only makes limited
> sense, especially wrt. to gcc 3.4 and newer.  Chances for any such changes
> to be accepted upstream are slim - and the kernel has traditionally been
> easily affected by overoptimization, so I recommend against gcc 3.4.  The
> recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto
> gcc 3.3 is reasonable and can be considered well tested.

 I do agree in general, but given that the construct I've used has been 
supported by gas since 1995, there is no point in keeping our code broken.  
And binutils actually quite rarely trigger problems with Linux, while 
they've got improved significantly with the last few releases; unlike with 
GCC it's normally a good idea to use the latest version of binutils.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Mon, Feb 14, 2005 at 04:06:51PM +0000, Maciej W. Rozycki wrote:

> > Bulletproofing 2.4 against newer tools is something that only makes limited
> > sense, especially wrt. to gcc 3.4 and newer.  Chances for any such changes
> > to be accepted upstream are slim - and the kernel has traditionally been
> > easily affected by overoptimization, so I recommend against gcc 3.4.  The
> > recommended compiler for 2.4 is still gcc 2.95.3 but except gcc 3.0 upto
> > gcc 3.3 is reasonable and can be considered well tested.
> 
>  I do agree in general, but given that the construct I've used has been 
> supported by gas since 1995, there is no point in keeping our code broken.  
> And binutils actually quite rarely trigger problems with Linux, while 
> they've got improved significantly with the last few releases; unlike with 
> GCC it's normally a good idea to use the latest version of binutils.

I wasn't objecting to your patch; it's just that I expect some users to
upgrade to a recent binutils and gcc at the same time and that has good
chances to end up in a nice firework ;-)

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Sun, 13 Feb 2005 ralf@linux-mips.org wrote:

> Modified files:
> 	arch/mips      : Kconfig 
> 
> Log message:
> 	If you want RM7000 better fix it to build first ...

 It works for me -- if you want a fix, then tell me what exactly is wrong.  
Perhaps your compiler is broken.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

Hi Ralf,

On Sat, 15 Jan 2005 01:31:06 +0000
ralf@linux-mips.org wrote:

> 
> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ralf@ftp.linux-mips.org	05/01/15 01:31:06
> 
> Modified files:
> 	drivers/net    : big_sur_ge.h gt64240eth.h 
> 	include/asm-mips: gt64120.h hardirq.h spinlock.h unistd.h 
> 	include/asm-mips/mach-atlas: mc146818rtc.h 
> 	include/asm-mips/mach-au1x00: au1000.h au1xxx_dbdma.h 
> 	                              au1xxx_psc.h 
> 	include/asm-mips/mach-db1x00: db1x00.h 
> 	include/asm-mips/mach-ip32: cpu-feature-overrides.h spaces.h 
> 	include/asm-mips/mach-mips: cpu-feature-overrides.h 
> 	include/asm-mips/mach-pb1x00: pb1550.h 
> 	include/asm-mips/vr41xx: cmbvr4133.h vrc4173.h 
> 	arch/mips/au1000/common: au1xxx_irqmap.c cputable.c dbdma.c 
> 	                         dma.c platform.c sleeper.S 
> 	arch/mips/au1000/mtx-1: init.c 
> 	arch/mips/au1000/pb1550: board_setup.c 
> 	arch/mips/ddb5xxx/ddb5074: irq.c setup.c 
> 	arch/mips/ddb5xxx/ddb5476: setup.c 
> 	arch/mips/dec  : setup.c 
> 	arch/mips/dec/boot: decstation.c 
> 	arch/mips/galileo-boards/ev96100: time.c 
> 	arch/mips/gt64120/momenco_ocelot: irq.c 
> 	arch/mips/ite-boards/generic: irq.c 
> 	arch/mips/kernel: binfmt_elfn32.c binfmt_elfo32.c mips_ksyms.c 
> 	                  semaphore.c smp.c time.c 
> 	arch/mips/mips-boards/atlas: atlas_int.c 
> 	arch/mips/mips-boards/generic: gdb_hook.c 
> 	arch/mips/mips-boards/malta: malta_int.c 
> 	arch/mips/mm   : cex-sb1.S dma-ip32.c pg-r4k.c pgtable.c 
> 	                 tlb-andes.c tlb-sb1.c 
> 	arch/mips/momentum/ocelot_3: reset.c setup.c 
> 	arch/mips/momentum/ocelot_c: irq.c 
> 	arch/mips/momentum/ocelot_g: gt-irq.c irq.c 
> 	arch/mips/pci  : fixup-atlas.c ops-msc.c 
> 	arch/mips/pmc-sierra/yosemite: atmel_read_eeprom.h irq.c 
> 	arch/mips/sgi-ip27: ip27-memory.c ip27-timer.c 
> 	arch/mips/vr4181/common: irq.c 
> 	arch/mips/vr4181/osprey: setup.c 
> 	arch/mips/vr41xx/common: giu.c icu.c ksyms.c vrc4173.c 
> 	drivers/scsi   : wd33c93.h 
> 
> Log message:
> 	Fix use rsp. non-use of <linux/config.h>.

arch/mips/vr41xx/common/giu.c and icu.c need <linux/config.h>
I,m going to update 2 files soon.
 
Please get back 2 files.

Yoichi

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Wed, 19 Jan 2005, Yoichi Yuasa wrote:

> arch/mips/vr41xx/common/giu.c and icu.c need <linux/config.h>
> I,m going to update 2 files soon.

 Neither of these uses any CONFIG_* macros.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

On Wed, 19 Jan 2005 05:04:32 +0000 (GMT)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

> On Wed, 19 Jan 2005, Yoichi Yuasa wrote:
> 
> > arch/mips/vr41xx/common/giu.c and icu.c need <linux/config.h>
> > I,m going to update 2 files soon.
> 
>  Neither of these uses any CONFIG_* macros.

I'm making patch for giu.c and icu.c.
These patches need it. 

I'll send these patches as soon as possible.

Yoichi

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Wed, 19 Jan 2005, Yoichi Yuasa wrote:

> >  Neither of these uses any CONFIG_* macros.
> 
> I'm making patch for giu.c and icu.c.
> These patches need it. 

 Then please just include what you need within these patches.  That's the 
usual way of doing stuff.

  Maciej

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

Hi Maciej,

On Wed, 19 Jan 2005 05:35:29 +0000 (GMT)
"Maciej W. Rozycki" <macro@linux-mips.org> wrote:

> On Wed, 19 Jan 2005, Yoichi Yuasa wrote:
> 
> > >  Neither of these uses any CONFIG_* macros.
> > 
> > I'm making patch for giu.c and icu.c.
> > These patches need it. 
> 
>  Then please just include what you need within these patches.  That's the 
> usual way of doing stuff.

Ok, I'll send a patch including get back and add new line.

Thanks,

Yoichi

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

Hello Ralf and Maciej,

On Wed, 19 Jan 2005 15:21:51 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hi Maciej,
> 
> On Wed, 19 Jan 2005 05:35:29 +0000 (GMT)
> "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> 
> > On Wed, 19 Jan 2005, Yoichi Yuasa wrote:
> > 
> > > >  Neither of these uses any CONFIG_* macros.
> > > 
> > > I'm making patch for giu.c and icu.c.
> > > These patches need it. 
> > 
> >  Then please just include what you need within these patches.  That's the 
> > usual way of doing stuff.
> 
> Ok, I'll send a patch including get back and add new line.

Sorry for the delay.
Next I'll send giu.c update.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig
--- a-orig/arch/mips/vr41xx/Kconfig	Mon Jan 31 05:45:36 2005
+++ a/arch/mips/vr41xx/Kconfig	Tue Mar  8 01:34:14 2005
@@ -97,6 +97,10 @@
 	bool "Add PCI control unit support of NEC VR4100 series"
 	depends on MACH_VR41XX && PCI
 
+config GPIO_VR41XX
+	bool "Add General-purpose I/O unit support of NEC VR4100 series"
+	depends on MACH_VR41XX
+
 config VRC4171
 	tristate "Add NEC VRC4171 companion chip support"
 	depends on MACH_VR41XX && ISA
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/Makefile a/arch/mips/vr41xx/common/Makefile
--- a-orig/arch/mips/vr41xx/common/Makefile	Thu Feb 26 00:23:50 2004
+++ a/arch/mips/vr41xx/common/Makefile	Fri Mar  4 17:29:00 2005
@@ -2,7 +2,8 @@
 # Makefile for common code of the NEC VR4100 series.
 #
 
-obj-y				+= bcu.o cmu.o giu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o
+obj-y				+= bcu.o cmu.o icu.o init.o int-handler.o ksyms.o pmu.o rtc.o
+obj-$(CONFIG_GPIO_VR41XX)	+= giu.o
 obj-$(CONFIG_SERIAL_8250)	+= serial.o
 obj-$(CONFIG_VRC4171)		+= vrc4171.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/icu.c a/arch/mips/vr41xx/common/icu.c
--- a-orig/arch/mips/vr41xx/common/icu.c	Sun Jan 16 22:34:31 2005
+++ a/arch/mips/vr41xx/common/icu.c	Tue Mar  8 01:08:13 2005
@@ -3,8 +3,7 @@
  *
  *  Copyright (C) 2001-2002  MontaVista Software Inc.
  *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
- *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org)
+ *  Copyright (C) 2003-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -29,6 +28,7 @@
  *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *  - Coped with INTASSIGN of NEC VR4133.
  */
+#include <linux/config.h>
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
@@ -45,8 +45,10 @@
 
 extern asmlinkage void vr41xx_handle_interrupt(void);
 
+#ifdef CONFIG_GPIO_VR41XX
 extern void init_vr41xx_giuint_irq(void);
 extern void giuint_irq_dispatch(struct pt_regs *regs);
+#endif
 
 static uint32_t icu1_base;
 static uint32_t icu2_base;
@@ -672,9 +674,11 @@
 		for (i = 0; i < 16; i++) {
 			if (intnum == sysint1_assign[i] &&
 			    (mask1 & ((uint16_t)1 << i))) {
+#ifdef CONFIG_GPIO_VR41XX
 				if (i == 8)
 					giuint_irq_dispatch(regs);
 				else
+#endif
 					do_IRQ(SYSINT1_IRQ(i), regs);
 				return;
 			}
@@ -698,8 +702,10 @@
 
 /*=======================================================================*/
 
-static int __init vr41xx_icu_init(void)
+static inline void init_vr41xx_icu_irq(void)
 {
+	int i;
+
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
@@ -723,17 +729,6 @@
 	write_icu2(0, MSYSINT2REG);
 	write_icu2(0xffff, MGIUINTHREG);
 
-	return 0;
-}
-
-early_initcall(vr41xx_icu_init);
-
-/*=======================================================================*/
-
-static inline void init_vr41xx_icu_irq(void)
-{
-	int i;
-
 	for (i = SYSINT1_IRQ_BASE; i <= SYSINT1_IRQ_LAST; i++)
 		irq_desc[i].handler = &sysint1_irq_type;
 
@@ -751,7 +746,9 @@
 {
 	mips_cpu_irq_init(MIPS_CPU_IRQ_BASE);
 	init_vr41xx_icu_irq();
+#ifdef CONFIG_GPIO_VR41XX
 	init_vr41xx_giuint_irq();
+#endif
 
 	set_except_vector(0, vr41xx_handle_interrupt);
 }

Re: CVS Update@linux-mips.org: linux

[Yoichi Yuasa]

Hello again,

On Tue, 8 Mar 2005 01:44:20 +0900
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:

> Hello Ralf and Maciej,
> 
> On Wed, 19 Jan 2005 15:21:51 +0900
> Yoichi Yuasa <yuasa@hh.iij4u.or.jp> wrote:
> 
> > Hi Maciej,
> > 
> > On Wed, 19 Jan 2005 05:35:29 +0000 (GMT)
> > "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> > 
> > > On Wed, 19 Jan 2005, Yoichi Yuasa wrote:
> > > 
> > > > >  Neither of these uses any CONFIG_* macros.
> > > > 
> > > > I'm making patch for giu.c and icu.c.
> > > > These patches need it. 
> > > 
> > >  Then please just include what you need within these patches.  That's the 
> > > usual way of doing stuff.
> > 
> > Ok, I'll send a patch including get back and add new line.
> 
> Sorry for the delay.
> Next I'll send giu.c update.

This is giu.c update.

Yoichi

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>

diff -urN -X dontdiff a-orig/arch/mips/vr41xx/Kconfig a/arch/mips/vr41xx/Kconfig
--- a-orig/arch/mips/vr41xx/Kconfig	Tue Mar  8 08:10:16 2005
+++ a/arch/mips/vr41xx/Kconfig	Sun Mar 13 23:45:57 2005
@@ -98,7 +98,7 @@
 	depends on MACH_VR41XX && PCI
 
 config GPIO_VR41XX
-	bool "Add General-purpose I/O unit support of NEC VR4100 series"
+	tristate "Add General-purpose I/O unit support of NEC VR4100 series"
 	depends on MACH_VR41XX
 
 config VRC4171
diff -urN -X dontdiff a-orig/arch/mips/vr41xx/common/giu.c a/arch/mips/vr41xx/common/giu.c
--- a-orig/arch/mips/vr41xx/common/giu.c	Sun Jan 16 22:34:31 2005
+++ a/arch/mips/vr41xx/common/giu.c	Thu Mar 17 01:09:47 2005
@@ -3,8 +3,7 @@
  *
  *  Copyright (C) 2002 MontaVista Software Inc.
  *    Author: Yoichi Yuasa <yyuasa@mvista.com or source@mvista.com>
- *  Copyright (C) 2003-2004  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  Copyright (C) 2005 Ralf Baechle (ralf@linux-mips.org)
+ *  Copyright (C) 2003-2005  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
  *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -29,6 +28,7 @@
  *  - Added support for NEC VR4133.
  *  - Removed board_irq_init.
  */
+#include <linux/config.h>
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/irq.h>
@@ -63,12 +63,6 @@
 
 static uint32_t giu_base;
 
-static struct irqaction giu_cascade = {
-	.handler	= no_action,
-	.mask		= CPU_MASK_NONE,
-	.name		= "cascade",
-};
-
 #define read_giuint(offset)		readw(giu_base + (offset))
 #define write_giuint(val, offset)	writew((val), giu_base + (offset))
 
@@ -192,18 +186,20 @@
 	.end		= end_giuint_high_irq,
 };
 
-void __init init_vr41xx_giuint_irq(void)
+void vr41xx_enable_giuint(unsigned int pin)
 {
-	int i;
-
-	for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) {
-		if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET))
-			irq_desc[i].handler = &giuint_low_irq_type;
-		else
-			irq_desc[i].handler = &giuint_high_irq_type;
-	}
+	if (pin < GIUINT_HIGH_OFFSET)
+		enable_giuint_low_irq(GIU_IRQ(pin));
+	else
+		enable_giuint_high_irq(GIU_IRQ(pin));
+}
 
-	setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade);
+void vr41xx_disable_giuint(unsigned int pin)
+{
+	if (pin < GIUINT_HIGH_OFFSET)
+		disable_giuint_low_irq(GIU_IRQ(pin));
+	else
+		disable_giuint_high_irq(GIU_IRQ(pin));
 }
 
 void vr41xx_set_irq_trigger(int pin, int trigger, int hold)
@@ -296,6 +292,8 @@
 
 EXPORT_SYMBOL(vr41xx_set_irq_level);
 
+#ifndef MODULE
+
 #define GIUINT_NR_IRQS		32
 
 enum {
@@ -310,6 +308,12 @@
 
 static struct vr41xx_giuint_cascade giuint_cascade[GIUINT_NR_IRQS];
 
+static struct irqaction giu_cascade = {
+	.handler	= no_action,
+	.mask		= CPU_MASK_NONE,
+	.name		= "cascade",
+};
+
 static int no_irq_number(int irq)
 {
 	return -EINVAL;
@@ -421,7 +425,7 @@
 	enable_irq(GIUINT_CASCADE_IRQ);
 }
 
-static int __init vr41xx_giu_init(void)
+void __init init_vr41xx_giuint_irq(void)
 {
 	int i;
 
@@ -437,7 +441,7 @@
 		break;
 	default:
 		printk(KERN_ERR "GIU: Unexpected CPU of NEC VR4100 series\n");
-		return -EINVAL;
+		return;
 	}
 
 	for (i = 0; i < GIUINT_NR_IRQS; i++) {
@@ -449,7 +453,14 @@
 		giuint_cascade[i].get_irq_number = no_irq_number;
 	}
 
-	return 0;
+	for (i = GIU_IRQ_BASE; i <= GIU_IRQ_LAST; i++) {
+		if (i < (GIU_IRQ_BASE + GIUINT_HIGH_OFFSET))
+			irq_desc[i].handler = &giuint_low_irq_type;
+		else
+			irq_desc[i].handler = &giuint_high_irq_type;
+	}
+
+	setup_irq(GIUINT_CASCADE_IRQ, &giu_cascade);
 }
 
-early_initcall(vr41xx_giu_init);
+#endif

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Mar 18, 2005 at 12:47:50AM +0900, Yoichi Yuasa wrote:

> This is giu.c update.
> 
> Yoichi

Thanks Yoichi, applied.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Sun, 9 Jan 2005 ralf@linux-mips.org wrote:
> Log message:
> 	Merge with Linux 2.4.29-rc3.

-rc1, I guess?

Gr{oetje,eeting}s,

					    Geert (deperately looking to merge
						   m68k to -rc2 and -rc3 ;-)

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

[Ralf Baechle]

On Sun, Jan 09, 2005 at 09:55:40PM +0100, Geert Uytterhoeven wrote:

> On Sun, 9 Jan 2005 ralf@linux-mips.org wrote:
> > Log message:
> > 	Merge with Linux 2.4.29-rc3.
> 
> -rc1, I guess?

Sorry, I pressed the wrong button on my time machine ;-)

  Ralf

Re: CVS Update@linux-mips.org: linux

[Ilya A. Volynets-Evenbakh]

ralf@linux-mips.org wrote:

>CVSROOT:	/home/cvs
>Module name:	linux
>Changes by:	ralf@ftp.linux-mips.org	05/01/08 18:00:18
>
>Modified files:
>	include/asm-mips: bitops.h 
>
>Log message:
>	Fix int vs. long bugs breaking the non-ll/sc case on 64-bit.
>
>diff -urN linux/include/asm-mips/bitops.h linux/include/asm-mips/bitops.h
>--- linux/include/asm-mips/bitops.h	2004/10/12 01:45:51	1.55
>+++ linux/include/asm-mips/bitops.h	2005/01/08 18:00:18	1.56
>@@ -92,7 +92,7 @@
> 		__bi_flags;
> 
> 		a += nr >> SZLONG_LOG;
>-		mask = 1 << (nr & SZLONG_MASK);
>+		mask = 1UL << (nr & SZLONG_MASK);
> 		__bi_local_irq_save(flags);
> 		*a |= mask;
> 		__bi_local_irq_restore(flags);
>@@ -385,7 +385,7 @@
> 		__bi_flags;
> 
> 		a += nr >> SZLONG_LOG;
>-		mask = 1 << (nr & SZLONG_MASK);
>+		mask = 1UL << (nr & SZLONG_MASK);
> 		__bi_local_irq_save(flags);
> 		retval = (mask & *a) != 0;
> 		*a &= ~mask;
>
>  
>
Any reason why same change wasn't applied to rest of bitops functions?

Index: include/asm/bitops.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/bitops.h,v
retrieving revision 1.56
diff -U5 -r1.56 bitops.h
--- include/asm/bitops.h        8 Jan 2005 18:00:18 -0000       1.56
+++ include/asm/bitops.h        8 Jan 2005 20:21:59 -0000
@@ -150,11 +150,11 @@
                volatile unsigned long *a = addr;
                unsigned long mask;
                __bi_flags;

                a += nr >> SZLONG_LOG;
-               mask = 1 << (nr & SZLONG_MASK);
+               mask = 1UL << (nr & SZLONG_MASK);
                __bi_local_irq_save(flags);
                *a &= ~mask;
                __bi_local_irq_restore(flags);
        }
 }
@@ -212,11 +212,11 @@
                volatile unsigned long *a = addr;
                unsigned long mask;
                __bi_flags;

                a += nr >> SZLONG_LOG;
-               mask = 1 << (nr & SZLONG_MASK);
+               mask = 1UL << (nr & SZLONG_MASK);
                __bi_local_irq_save(flags);
                *a ^= mask;
                __bi_local_irq_restore(flags);
        }
 }
@@ -291,11 +291,11 @@
                unsigned long mask;
                int retval;
                __bi_flags;

                a += nr >> SZLONG_LOG;
-               mask = 1 << (nr & SZLONG_MASK);
+               mask = 1UL << (nr & SZLONG_MASK);
                __bi_local_irq_save(flags);
                retval = (mask & *a) != 0;
                *a |= mask;
                __bi_local_irq_restore(flags);

@@ -318,11 +318,11 @@
        volatile unsigned long *a = addr;
        unsigned long mask;
        int retval;

        a += nr >> SZLONG_LOG;
-       mask = 1 << (nr & SZLONG_MASK);
+       mask = 1UL << (nr & SZLONG_MASK);
        retval = (mask & *a) != 0;
        *a |= mask;

        return retval;
 }
@@ -472,11 +472,11 @@
                volatile unsigned long *a = addr;
                unsigned long mask, retval;
                __bi_flags;

                a += nr >> SZLONG_LOG;
-               mask = 1 << (nr & SZLONG_MASK);
+               mask = 1UL << (nr & SZLONG_MASK);
                __bi_local_irq_save(flags);
                retval = (mask & *a) != 0;
                *a ^= mask;
                __bi_local_irq_restore(flags);

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Sat, Jan 08, 2005 at 12:25:35PM -0800, Ilya A. Volynets-Evenbakh wrote:

> >Modified files:
> >	include/asm-mips: bitops.h 
> >
> >Log message:
> >	Fix int vs. long bugs breaking the non-ll/sc case on 64-bit.

Argh.  One of these days ;)

  Ralf

Re: CVS Update@linux-mips.org: linux

[Ilya A. Volynets-Evenbakh]

ths@linux-mips.org wrote:

>CVSROOT:	/home/cvs
>Module name:	linux
>Changes by:	ths@ftp.linux-mips.org	05/01/07 19:19:40
>
>Modified files:
>	arch/mips/kernel: signal.c signal_n32.c 
>Added files:
>	arch/mips/kernel: signal-common.h 
>
>Log message:
>	Save a bit of copy&paste by separating out common parts in the signal handling.
>
>  
>
Seems like following piece is missing from this patch:

Index: arch/mips/kernel/signal.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/signal.c,v
retrieving revision 1.84
diff -u -r1.84 signal.c
--- arch/mips/kernel/signal.c   7 Jan 2005 19:19:40 -0000       1.84
+++ arch/mips/kernel/signal.c   7 Jan 2005 20:40:02 -0000
@@ -155,51 +155,6 @@
        return do_sigaltstack(uss, uoss, usp);
 }

-int restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
-{
-       int err = 0;
-
-       /* Always make any pending restarted system calls return -EINTR */
-       current_thread_info()->restart_block.fn = do_no_restart_syscall;
-
-       err |= __get_user(regs->cp0_epc, &sc->sc_pc);
-       err |= __get_user(regs->hi, &sc->sc_mdhi);
-       err |= __get_user(regs->lo, &sc->sc_mdlo);
-
-#define restore_gp_reg(i) do {                                         \
-       err |= __get_user(regs->regs[i], &sc->sc_regs[i]);              \
-} while(0)
-       restore_gp_reg( 1); restore_gp_reg( 2); restore_gp_reg( 3);
-       restore_gp_reg( 4); restore_gp_reg( 5); restore_gp_reg( 6);
-       restore_gp_reg( 7); restore_gp_reg( 8); restore_gp_reg( 9);
-       restore_gp_reg(10); restore_gp_reg(11); restore_gp_reg(12);
-       restore_gp_reg(13); restore_gp_reg(14); restore_gp_reg(15);
-       restore_gp_reg(16); restore_gp_reg(17); restore_gp_reg(18);
-       restore_gp_reg(19); restore_gp_reg(20); restore_gp_reg(21);
-       restore_gp_reg(22); restore_gp_reg(23); restore_gp_reg(24);
-       restore_gp_reg(25); restore_gp_reg(26); restore_gp_reg(27);
-       restore_gp_reg(28); restore_gp_reg(29); restore_gp_reg(30);
-       restore_gp_reg(31);
-#undef restore_gp_reg
-
-       err |= __get_user(current->used_math, &sc->sc_used_math);
-
-       preempt_disable();
-
-       if (current->used_math) {
-               /* restore fpu context if we have used it before */
-               own_fpu();
-               err |= restore_fp_context(sc);
-       } else {
-               /* signal handler may have used FPU.  Give it up. */
-               lose_fpu();
-       }
-
-       preempt_enable();
-
-       return err;
-}
-
 #if PLAT_TRAMPOLINE_STUFF_LINE
 #define __tramp __attribute__((aligned(PLAT_TRAMPOLINE_STUFF_LINE)))
 #else

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ilya A. Volynets-Evenbakh wrote:
> ths@linux-mips.org wrote:
> 
> >CVSROOT:	/home/cvs
> >Module name:	linux
> >Changes by:	ths@ftp.linux-mips.org	05/01/07 19:19:40
> >
> >Modified files:
> >	arch/mips/kernel: signal.c signal_n32.c 
> >Added files:
> >	arch/mips/kernel: signal-common.h 
> >
> >Log message:
> >	Save a bit of copy&paste by separating out common parts in the 
> >	signal handling.
> >
> Seems like following piece is missing from this patch:
> 
> Index: arch/mips/kernel/signal.c

Plus some bits in signal_n32.c. Fix committed, sorry for the breakage.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Geert Uytterhoeven]

On Tue, 28 Dec 2004 ralf@linux-mips.org wrote:
> Added files:
> 	lib/reed_solomon: .cvsignore 
> 	drivers/input/joystick/iforce: .cvsignore 
> 	drivers/input/touchscreen: .cvsignore 
> 	drivers/scsi/aacraid: .cvsignore 
> 	drivers/isdn/hardware/eicon: .cvsignore 
> 	drivers/char/ipmi: .cvsignore 
> 	drivers/mmc    : .cvsignore 
> 	drivers/media/video/ovcamchip: .cvsignore 
> 	net/bluetooth/cmtp: .cvsignore 
> 	net/bluetooth/bnep: .cvsignore 
> 	net/bluetooth/hidp: .cvsignore 
> 	net/bluetooth/rfcomm: .cvsignore 
> 	sound/mips     : .cvsignore 
> 	security/selinux/ss: .cvsignore 
> 	security/selinux: .cvsignore 
> 	fs/hfsplus     : .cvsignore 
> 
> Log message:
> 	Ignore much much more generated crapola ...

Don't we all use `make O=' these days? ;-)

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