* Re: -mcpu vs. binutils 2.13.90.0.18
From: Thiemo Seufer @ 2003-03-18 19:08 UTC (permalink / raw)
To: linux-mips; +Cc: Guido Guenther
In-Reply-To: <20030318174241.GG2613@bogon.ms20.nix>
Guido Guenther wrote:
> On Tue, Mar 18, 2003 at 05:03:03PM +0100, Thiemo Seufer wrote:
> > Try
> > -mabi=o32 -march=r5000 -Wa,--trap
> > This may fail if the compiler is very old, though.
> >
> > > for IP22? -mips2 conflicts with -march=r5000 since this implies -mips4.
> >
> > This was fixed in very recent gcc. -mips2 should be an alias for -march=r6000
> > and -mips4 one for -march=r8000.
> Is it correct that -mipsX in contrast to -march=rXXXX has the difference
> of not only selecting a specific CPU instruction set but also an abi
> (o32 or n64)?
Only for old compilers, an only for some cases. :-/
-mipsX is the old method for selecting both CPU and ABI, resembling the way
SGI did it for their toolchain. Then there was the need to support different
CPUs, which led to -mcpu/-mXXXX. The result was an inconsistent mess,
especially -mips2 has multiple overloaded semantics.
> If so wouldn't it be cleaner to remove -mipsX altogether
> and use -march=rXXXX and -mabi=o32, etc?
This would be nice, but older compilers don't have -march/-mtune.
IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.
> The different meanings of these
> options in different toolchain versions confuse me a lot. What is the
> final intended usage of these options?
For usual userland the ABI defines everything needed. This means
No options at all:
Produce, hosted on a single ABI system, a userland binary with the lowest
possible ISA.
-mabi=FOO:
Produce, hosted on a multi ABI system, a userland binary with the lowest
possible ISA for the selected ABI.
Then there are optimizations for different CPUs.
-march=BAR:
Allow opcodes for CPU BAR in addition to the ISA ones.
-mtune=BAZ:
Optimize opcode scheduling for CPU BAZ.
Some embedded systems don't care much about ABI compatibility, they
use also
-mgp32/-mfp32:
Restrict register width to 32 bits on 64 bit CPUs.
Then, there are the backward compatibility options.
-mipsX:
Is an alias for -march=QUUX, where QUUX is the CPU closest to the respective
ISA. Note that this is only backward compatible for the assembler, not for
the compiler which implied some o32 features for -mips2.
-mcpu=XXX, -mYYYY:
Old CPU selection code, mostly gone now. Superseded by -march/-mtune.
For my private linux kernels, I use a new CONFIG_MIPS_NEW_TOOLCHAIN in the
Makefile. I don't see a better way around it.
Thiemo
^ permalink raw reply
* Running on R4k/R3k Indigo
From: Achim Hensel @ 2003-03-18 22:48 UTC (permalink / raw)
To: port-sgimips, Linux-MIPS
Hello, folks (of both lists)
I recently got both an R4k and an R3k SGI Indigo.
I know, none of them is supported at the moment.
So, I want to try to change that.
I hadn't started yet, but every help is appreciated.
CU,
Achim
P.S.: This was posted to both lists, as I don't know, which OS
has the better starting point for my computers.
^ permalink raw reply
* Re: -mcpu vs. binutils 2.13.90.0.18
From: Guido Guenther @ 2003-03-18 23:24 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: linux-mips
In-Reply-To: <20030318190841.GO13122@rembrandt.csv.ica.uni-stuttgart.de>
Hi Thiemo,
thanks a lot for the explanations!
On Tue, Mar 18, 2003 at 08:08:41PM +0100, Thiemo Seufer wrote:
> This would be nice, but older compilers don't have -march/-mtune.
> IIRC gcc 3.0.X is the first one to employ these. Similiar for -mabi.
I don't care about old compilers at the moment ;)
[..snip..]
> -mabi=FOO:
> Produce, hosted on a multi ABI system, a userland binary with the lowest
> possible ISA for the selected ABI.
>
> Then there are optimizations for different CPUs.
>
> -march=BAR:
> Allow opcodes for CPU BAR in addition to the ISA ones.
>
> -mtune=BAZ:
> Optimize opcode scheduling for CPU BAZ.
So to build kernels for say IP22 R5k I'd change the current
GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
to
GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
where as for R4X00 I use
GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
Correct?
-- Guido
^ permalink raw reply
* Re: -mcpu vs. binutils 2.13.90.0.18
From: Thiemo Seufer @ 2003-03-19 0:16 UTC (permalink / raw)
To: linux-mips; +Cc: Guido Guenther, Thiemo Seufer
In-Reply-To: <20030318232454.GA19990@bogon.ms20.nix>
Guido Guenther wrote:
[snip]
> > -march=BAR:
> > Allow opcodes for CPU BAR in addition to the ISA ones.
> >
> > -mtune=BAZ:
> > Optimize opcode scheduling for CPU BAZ.
> So to build kernels for say IP22 R5k I'd change the current
> GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap
> to
> GCCFLAGS += -mabi=o32 -march=R5000 -mtune=R5000 -Wa,--trap
> where as for R4X00 I use
> GCCFLAGS += -mabi=o32 -march=R4600 -mtune=R4600 -Wa,--trap
> Correct?
Yes, this should work. You can leave the -mtune out, since it defaults
to the value of -march anyway.
Thiemo
^ permalink raw reply
* Re: -mcpu vs. binutils 2.13.90.0.18
From: Guido Guenther @ 2003-03-19 1:25 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: linux-mips
In-Reply-To: <20030319001652.GB19189@rembrandt.csv.ica.uni-stuttgart.de>
On Wed, Mar 19, 2003 at 01:16:52AM +0100, Thiemo Seufer wrote:
> Yes, this should work. You can leave the -mtune out, since it defaults
> to the value of -march anyway.
Thanks.
-- Guido
^ permalink raw reply
* PCI status error 0x2a80..
From: Ashish anand @ 2003-03-19 7:11 UTC (permalink / raw)
To: linux-mips
Hello,
I am experiencing the PCI bus error for a network card(Realtek 8139)
operation.
whenever it tries to transmit packets it prints the error like
eth0: PCI Bus error 0x2a80.
PCI status 0x2a80 as per pci specs suggests pci master and target
abort.
other basic infrastructures like interupts , pci-dma and cards pci
resources are well in place.also i am able to receive all packets.
I have ensured other pci config registers like Latency timer and
command register are initialised to appropiate values.
pci command has been set to 0x7 ( io + mem + busmaster).
1.what can be other reasons for this to happen ..?
2.if pci master and target abort happens how the card is able to recive
the packets..?
3.does this situation demand pci debugging or driver level debugging?
Best Regards,
Ashish Anand
^ permalink raw reply
* Re: Running on R4k/R3k Indigo
From: Jan-Benedict Glaw @ 2003-03-19 7:19 UTC (permalink / raw)
To: Achim Hensel; +Cc: port-sgimips, Linux-MIPS
In-Reply-To: <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>
[-- Attachment #1: Type: text/plain, Size: 888 bytes --]
On Tue, 2003-03-18 23:48:44 +0100, Achim Hensel <achim.hensel@ruhr-uni-bochum.de>
wrote in message <20030318234844.2e465609.achim.hensel@ruhr-uni-bochum.de>:
> Hello, folks (of both lists)
>
> I recently got both an R4k and an R3k SGI Indigo.
There are some of them flyin' around.
> I know, none of them is supported at the moment.
> So, I want to try to change that.
Well... I've started to look at some assembler dumps of the Irix kernel.
This is a lenghty approach, though. That's more than 30MB of text:(
Even with that, there are some issues...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PCI status error 0x2a80..
From: Greg Lindahl @ 2003-03-19 8:01 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>
On Wed, Mar 19, 2003 at 12:41:50PM +0530, Ashish anand wrote:
> I am experiencing the PCI bus error for a network card(Realtek 8139)
> operation.
This is the card that locks up when you try to drive it with maximum
traffic under both Linux and Windows, right?
-- greg
^ permalink raw reply
* compressed image for mips:malta
From: debashis @ 2003-03-19 8:20 UTC (permalink / raw)
To: linux-mips
Hi,
I am working with a mips malta 4KC box. It supports vmlinux. The linux
kernel version that I am using is 2.4.18
However the size of the vmlinux image looks high (more than 1M). I am
trying to get a smaller image (with neworking). Need some help :
Is their any compressed image is supported for this particular board?
Does the loader need some change to support compressed image?
In case I need to provide support for the compressed image, is there any
similar board on which the compressed image support is present?
Any suggession is welcome.
Thanks in advance.
Regards,
debashis
^ permalink raw reply
* Mirrored pages of old 'reality.sgi.com' webserver...
From: Steven J. Hill @ 2003-03-19 19:42 UTC (permalink / raw)
To: port-sgimips, linux-mips
Greetings.
I had done a massive mirror of webpages from the old 'reality.sgi.com'
server about a year ago before it disappeared. I mirrored all of the
people's pages that had real content. I just finished uploading it to
my server a few days ago and thought I would share it with people so
that some good content did not die. Please note, if SGI or the owners
of the content contact me and ask me to remove some or all of the
content, I will immediately comply. Until then, enjoy. Cheers.
http://www.realitydiluted.com/mirrors/reality.sgi.com/
-Steve
^ permalink raw reply
* Re: PCI status error 0x2a80..
From: Ralf Baechle @ 2003-03-19 19:56 UTC (permalink / raw)
To: Ashish anand; +Cc: linux-mips
In-Reply-To: <200303190734.h2J7YeQm029902@smtp.inspirtek.com>
On Wed, Mar 19, 2003 at 12:41:50PM +0530, Ashish anand wrote:
> I am experiencing the PCI bus error for a network card(Realtek 8139)
> operation.
The 8139 has been driving driver writers crazy over the years. Too many
too bugy variants. I remember a guy who had a car number plate with
RTL 8139 printed on it on his wall because he managed to improve the
situation by a few percent ...
Ralf
^ permalink raw reply
* Re: 2.4.20 SCSI problems on NASRaQ
From: Neurophyre @ 2003-03-19 22:23 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20030318172414.MLZJ7686.mta6.adelphia.net@there>
A little update on the problems with none of the 3 drivers initializing
the 53c860 SCSI controller on the Seagate (Cobalt) NASRaQ:
I've built the 2.5.47 CVS snapshot kernel from linux-mips.org, but even
with just about everything modularized, the kernel is just over 100K
too big for the NASRaQ's boot loader. So, it would seem without
getting very creative that 2.4.x is the end of the road for this
hardware.. this means I can't test to see if any of the drivers now
work in the linux-mips source tree.
I also thought it might be good to include /proc/pci, since someone
off-list mentioned to me that perhaps some other device is reserving
the controller's address space (?).. again, here's what the message
from all three drivers looks like (using the newest one as an example):
sym.0.8.0: IO region 0x10102000[0..127] is in use
here is /proc/pci. The SCSI controller is device 8.
PCI devices found:
Bus 0, device 0, function 0:
Class 0580: PCI device 11ab:4146 (rev 17).
Master Capable. Latency=64.
Non-prefetchable 32 bit memory at 0x0 [0x3ffffff].
Non-prefetchable 32 bit memory at 0x4000000 [0x4000fff].
Non-prefetchable 32 bit memory at 0x1c000000 [0x1dffffff].
Non-prefetchable 32 bit memory at 0x1f000000 [0x1fffffff].
Non-prefetchable 32 bit memory at 0x14000000 [0x14000fff].
I/O at 0x14000000 [0x14000fff].
Bus 0, device 7, function 0:
Class 0200: PCI device 1011:0019 (rev 65).
IRQ 4.
Master Capable. Latency=64. Min Gnt=20.Max Lat=40.
I/O at 0x100000 [0x10007f].
Non-prefetchable 32 bit memory at 0x12000000 [0x120003ff].
Bus 0, device 8, function 0:
Class 0100: PCI device 1000:0006 (rev 2).
IRQ 4.
Master Capable. No bursts. Min Gnt=8.Max Lat=64.
I/O at 0x10102000 [0x101020ff].
Non-prefetchable 32 bit memory at 0x2000 [0x20ff].
Bus 0, device 9, function 0:
Class 0601: PCI device 1106:0586 (rev 39).
Bus 0, device 9, function 1:
Class 0101: PCI device 1106:0571 (rev 6).
Master Capable. Latency=64.
I/O at 0xcc00 [0xcc0f].
Bus 0, device 9, function 2:
Class 0c03: PCI device 1106:3038 (rev 2).
Master Capable. Latency=22.
I/O at 0x300 [0x31f].
If anybody has any suggestions of what I might be able to do to get the
SCSI controller working, I'd love to hear it. Also if there are any
other things you would like to see besides what I've shown. I'm not a
kernel hacker. :-(
As it stands now, anybody with a MIPS-based NASRaQ is out in the cold
when it comes to upgrading their system.
Finally, since the SCSI controller obviously worked with Cobalt's
(patched) 2.0 kernel, maybe an older kernel might work? Does anybody
have any snapshots of the 2.2.x source tree with MIPS patches applied?
Or access to Cobalt's old patches even?
^ permalink raw reply
* Cache code changes
From: Ralf Baechle @ 2003-03-20 10:16 UTC (permalink / raw)
To: linux-mips
Thought I should drop a note about the recent cache code changes in the
Linux 2.4 and 2.5 code in CVS to explain what's going on.
flush_page_to_ram() has long been a deprecated interface and been scheduled
to be removed for years. It's considered a inefficient, badly designed
interface. It's use it for dealing with virtual aliases in the primary
cache. That is whenever the memory managment code creates or modifies
a page that is mapped to userspace it has to writeback and invalidate the
kernel mapping of this page to avoid virtual aliases.
flush_page_to_ram() turned out to be a rather ad-hoc interface; the
obvious but inefficient interface approach. It's also not capable of
fully dealing with all types of cache aliases like aliases between the
page cache and user mappings. Which may lead to silent data corruption
and that's the reason why I'm doing such intrusive kernel surgery for a
supposedly stable kernel. So there now is an alternative interface
available in the kernel, flush_dcache_page(). flush_dcache_page() is
implements a two stage approach. It marks pages which are in the page
cache and therefore could possibly alias with userspace as possibly
residing in cache if it doesn't flush them immediately. This allows
delaying cache flushes - possibly infinitely. Which quite obviously is
a performance gain.
Side effect - some implementations of flush_icache_page() knew that it's
invocations are always preceeded by flush_page_to_ram() so the D-cache
flush can be omitted. This is no longer there case. Another bug fixed
along the way (but not yet for all processors) was flush_cache_page() not
flushing the instruction cache ...
Along with that I've also cleaned the cache code for R4000 and R4400 CPUs.
Continuing the mess seemed to be plain unmaintainable and at the same
time huge. The heavily changed code (for your amusement now using a few
new code constructs :-) is now over 40% smaller meassure in LOCs and about
2/3 smaller in code size and should make it fairly easy to add support for
strange beasts such as TX39, TX49 or R5432 style caches caches.
Why is it still not working? Well, below a kludge that will get the
latest 2.4 code to work again for all processors that are suffering from
cache aliases. It's an inefficient solution but good enough for now.
Ralf
Index: include/asm-mips/page.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/page.h,v
retrieving revision 1.14.2.11
diff -u -r1.14.2.11 page.h
--- include/asm-mips/page.h 20 Dec 2002 02:34:17 -0000 1.14.2.11
+++ include/asm-mips/page.h 19 Mar 2003 13:21:32 -0000
@@ -64,8 +64,10 @@
#define clear_page(page) _clear_page(page)
#define copy_page(to, from) _copy_page(to, from)
-#define clear_user_page(page, vaddr) clear_page(page)
-#define copy_user_page(to, from, vaddr) copy_page(to, from)
+#define clear_user_page(page, vaddr) \
+ do { clear_page(page); flush_cache_all(); } while (0)
+#define copy_user_page(to, from, vaddr) \
+ do { copy_page(to, from); flush_cache_all(); } while (0)
/*
* These are used to make use of C type-checking..
^ permalink raw reply
* Re: Cache code changes
From: Fuxin Zhang @ 2003-03-20 11:08 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20030320111625.A13219@linux-mips.org>
I am very glad to see this happens:)
Currently linux/mips is really far from efficient,I've some data for
this declaration:
For most SPEC CPU 2000 programs we run on a 4-way superscalar CPU
simulator
,we get <0.20 IPC in kernel mode,while the IPCs for the whole execution
are often much
higher(0.5-1.5). We believe this has something to do with the overly
used cache flushes.
BTW, for 2.4.17,it seems this path is still not safe for cache aliases:
copy_cow_page for newly forked process, we use kernel virtual address
to do the copy,but without flush first.
add a flush_page_to_ram before the copy fix the errors.
but i am not sure whether i am missing something
Ralf Baechle wrote:
>Thought I should drop a note about the recent cache code changes in the
>Linux 2.4 and 2.5 code in CVS to explain what's going on.
>
>flush_page_to_ram() has long been a deprecated interface and been scheduled
>to be removed for years. It's considered a inefficient, badly designed
>interface. It's use it for dealing with virtual aliases in the primary
>cache. That is whenever the memory managment code creates or modifies
>a page that is mapped to userspace it has to writeback and invalidate the
>kernel mapping of this page to avoid virtual aliases.
>
>flush_page_to_ram() turned out to be a rather ad-hoc interface; the
>obvious but inefficient interface approach. It's also not capable of
>fully dealing with all types of cache aliases like aliases between the
>page cache and user mappings. Which may lead to silent data corruption
>and that's the reason why I'm doing such intrusive kernel surgery for a
>supposedly stable kernel. So there now is an alternative interface
>available in the kernel, flush_dcache_page(). flush_dcache_page() is
>implements a two stage approach. It marks pages which are in the page
>cache and therefore could possibly alias with userspace as possibly
>residing in cache if it doesn't flush them immediately. This allows
>delaying cache flushes - possibly infinitely. Which quite obviously is
>a performance gain.
>
>Side effect - some implementations of flush_icache_page() knew that it's
>invocations are always preceeded by flush_page_to_ram() so the D-cache
>flush can be omitted. This is no longer there case. Another bug fixed
>along the way (but not yet for all processors) was flush_cache_page() not
>flushing the instruction cache ...
>
>Along with that I've also cleaned the cache code for R4000 and R4400 CPUs.
>Continuing the mess seemed to be plain unmaintainable and at the same
>time huge. The heavily changed code (for your amusement now using a few
>new code constructs :-) is now over 40% smaller meassure in LOCs and about
>2/3 smaller in code size and should make it fairly easy to add support for
>strange beasts such as TX39, TX49 or R5432 style caches caches.
>
>Why is it still not working? Well, below a kludge that will get the
>latest 2.4 code to work again for all processors that are suffering from
>cache aliases. It's an inefficient solution but good enough for now.
>
> Ralf
>
>Index: include/asm-mips/page.h
>===================================================================
>RCS file: /home/cvs/linux/include/asm-mips/page.h,v
>retrieving revision 1.14.2.11
>diff -u -r1.14.2.11 page.h
>--- include/asm-mips/page.h 20 Dec 2002 02:34:17 -0000 1.14.2.11
>+++ include/asm-mips/page.h 19 Mar 2003 13:21:32 -0000
>@@ -64,8 +64,10 @@
>
> #define clear_page(page) _clear_page(page)
> #define copy_page(to, from) _copy_page(to, from)
>-#define clear_user_page(page, vaddr) clear_page(page)
>-#define copy_user_page(to, from, vaddr) copy_page(to, from)
>+#define clear_user_page(page, vaddr) \
>+ do { clear_page(page); flush_cache_all(); } while (0)
>+#define copy_user_page(to, from, vaddr) \
>+ do { copy_page(to, from); flush_cache_all(); } while (0)
>
> /*
> * These are used to make use of C type-checking..
>
>
>
>
>
^ permalink raw reply
* Re: Cache code changes
From: Ralf Baechle @ 2003-03-20 12:05 UTC (permalink / raw)
To: Fuxin Zhang; +Cc: linux-mips
In-Reply-To: <3E79A121.6000409@ict.ac.cn>
On Thu, Mar 20, 2003 at 07:08:17PM +0800, Fuxin Zhang wrote:
> I am very glad to see this happens:)
> Currently linux/mips is really far from efficient,I've some data for
> this declaration:
> For most SPEC CPU 2000 programs we run on a 4-way superscalar CPU
> simulator
> ,we get <0.20 IPC in kernel mode,while the IPCs for the whole execution
> are often much
> higher(0.5-1.5). We believe this has something to do with the overly
> used cache flushes.
What type of cache are you using in this simulation? Virtual/physical
indexing/tagging, what associativity?
Linux/MIPS's handling of virtually indexed data caches isn't as good as
it should be but that's what I'm working on.
> BTW, for 2.4.17,it seems this path is still not safe for cache aliases:
> copy_cow_page for newly forked process, we use kernel virtual address
> to do the copy,but without flush first.
> add a flush_page_to_ram before the copy fix the errors.
>
> but i am not sure whether i am missing something
The functions clear_user_page and copy_user_page are supposed to take care
of aliases in this case. That's what the little patch did in my previous
mail did, just in a rather inefficient way.
Ralf
^ permalink raw reply
* Patches for all four au1000 setup.c files
From: Hartvig Ekner @ 2003-03-21 8:55 UTC (permalink / raw)
To: Linux MIPS mailing list
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hi,
the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
(handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
which support it.
/Hartvig
[-- Attachment #2: setup.patch --]
[-- Type: text/plain, Size: 4138 bytes --]
Index: db1x00/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 setup.c
--- db1x00/setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
+++ db1x00/setup.c 21 Mar 2003 08:44:49 -0000
@@ -61,7 +61,6 @@
extern struct ide_ops *ide_ops;
#endif
-void (*__wbflush) (void);
extern struct rtc_ops no_rtc_ops;
extern char * __init prom_getcmdline(void);
extern void au1000_restart(char *);
@@ -76,11 +75,6 @@
void __init bus_error_init(void) { /* nothing */ }
-void au1x00_wbflush(void)
-{
- __asm__ volatile ("sync");
-}
-
void __init au1x00_setup(void)
{
char *argptr;
@@ -109,14 +103,13 @@
}
#endif
-#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
+#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
// au1000 does not support vra, au1500 and au1100 do
- strcat(argptr, " au1000_audio=vra");
- argptr = prom_getcmdline();
+ strcat(argptr, " au1000_audio=vra");
+ argptr = prom_getcmdline();
#endif
rtc_ops = &no_rtc_ops;
- __wbflush = au1x00_wbflush;
_machine_restart = au1000_restart;
_machine_halt = au1000_halt;
_machine_power_off = au1000_power_off;
Index: pb1000/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
retrieving revision 1.8.2.8
diff -u -r1.8.2.8 setup.c
--- pb1000/setup.c 11 Dec 2002 06:12:29 -0000 1.8.2.8
+++ pb1000/setup.c 21 Mar 2003 08:44:50 -0000
@@ -67,7 +67,6 @@
extern struct ide_ops *ide_ops;
#endif
-void (*__wbflush) (void);
extern struct rtc_ops no_rtc_ops;
extern char * __init prom_getcmdline(void);
extern void au1000_restart(char *);
@@ -78,11 +77,6 @@
void __init bus_error_init(void) { /* nothing */ }
-void au1000_wbflush(void)
-{
- __asm__ volatile ("sync");
-}
-
void __init au1x00_setup(void)
{
char *argptr;
@@ -103,7 +97,6 @@
#endif
rtc_ops = &no_rtc_ops;
- __wbflush = au1000_wbflush;
_machine_restart = au1000_restart;
_machine_halt = au1000_halt;
_machine_power_off = au1000_power_off;
Index: pb1100/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
retrieving revision 1.1.2.6
diff -u -r1.1.2.6 setup.c
--- pb1100/setup.c 31 Dec 2002 05:00:22 -0000 1.1.2.6
+++ pb1100/setup.c 21 Mar 2003 08:44:50 -0000
@@ -71,7 +71,6 @@
extern struct rtc_ops pb1500_rtc_ops;
#endif
-void (*__wbflush) (void);
extern char * __init prom_getcmdline(void);
extern void au1000_restart(char *);
extern void au1000_halt(void);
@@ -82,11 +81,6 @@
void __init bus_error_init(void) { /* nothing */ }
-void au1100_wbflush(void)
-{
- __asm__ volatile ("sync");
-}
-
void __init au1x00_setup(void)
{
char *argptr;
@@ -112,7 +106,6 @@
argptr = prom_getcmdline();
#endif
- __wbflush = au1100_wbflush;
_machine_restart = au1000_restart;
_machine_halt = au1000_halt;
_machine_power_off = au1000_power_off;
Index: pb1500/setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
retrieving revision 1.1.2.10
diff -u -r1.1.2.10 setup.c
--- pb1500/setup.c 29 Dec 2002 10:30:35 -0000 1.1.2.10
+++ pb1500/setup.c 21 Mar 2003 08:44:50 -0000
@@ -43,7 +43,6 @@
#include <asm/mipsregs.h>
#include <asm/reboot.h>
#include <asm/pgtable.h>
-#include <asm/wbflush.h>
#include <asm/au1000.h>
#include <asm/pb1500.h>
@@ -72,7 +71,6 @@
extern struct rtc_ops pb1500_rtc_ops;
#endif
-void (*__wbflush) (void);
extern char * __init prom_getcmdline(void);
extern void au1000_restart(char *);
extern void au1000_halt(void);
@@ -87,11 +85,6 @@
void __init bus_error_init(void) { /* nothing */ }
-void au1500_wbflush(void)
-{
- __asm__ volatile ("sync");
-}
-
void __init au1x00_setup(void)
{
char *argptr;
@@ -117,7 +110,6 @@
argptr = prom_getcmdline();
#endif
- __wbflush = au1500_wbflush;
_machine_restart = au1000_restart;
_machine_halt = au1000_halt;
_machine_power_off = au1000_power_off;
^ permalink raw reply
* Re: Cache code changes
From: Dominic Sweetman @ 2003-03-21 11:53 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20030320111625.A13219@linux-mips.org>
Ralf,
> flush_page_to_ram()...
Can you remind me where I can find the specification of what these
functions are supposed to do?
--
Dominic
^ permalink raw reply
* Re: Cache code changes
From: Juan Quintela @ 2003-03-21 14:48 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <15994.64849.704568.803119@gladsmuir.algor.co.uk>
>>>>> "dominic" == Dominic Sweetman <dom@mips.com> writes:
dominic> Ralf,
>> flush_page_to_ram()...
dominic> Can you remind me where I can find the specification of what these
dominic> functions are supposed to do?
In the linux source:
linux/Documentation/cachetlb.txt
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Patches for all four au1000 setup.c files
From: Pete Popov @ 2003-03-21 15:58 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
In-Reply-To: <3E7AD36E.26E2EA94@ekner.info>
Thanks, I'll take care of them.
Pete
On Fri, 2003-03-21 at 00:55, Hartvig Ekner wrote:
> Hi,
>
> the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
>
> The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> which support it.
>
> /Hartvig
>
>
>
> ______________________________________________________________________
>
> Index: db1x00/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- db1x00/setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
> +++ db1x00/setup.c 21 Mar 2003 08:44:49 -0000
> @@ -61,7 +61,6 @@
> extern struct ide_ops *ide_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern struct rtc_ops no_rtc_ops;
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> @@ -76,11 +75,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1x00_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -109,14 +103,13 @@
> }
> #endif
>
> -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
> // au1000 does not support vra, au1500 and au1100 do
> - strcat(argptr, " au1000_audio=vra");
> - argptr = prom_getcmdline();
> + strcat(argptr, " au1000_audio=vra");
> + argptr = prom_getcmdline();
> #endif
>
> rtc_ops = &no_rtc_ops;
> - __wbflush = au1x00_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1000/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> retrieving revision 1.8.2.8
> diff -u -r1.8.2.8 setup.c
> --- pb1000/setup.c 11 Dec 2002 06:12:29 -0000 1.8.2.8
> +++ pb1000/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -67,7 +67,6 @@
> extern struct ide_ops *ide_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern struct rtc_ops no_rtc_ops;
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> @@ -78,11 +77,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1000_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -103,7 +97,6 @@
> #endif
>
> rtc_ops = &no_rtc_ops;
> - __wbflush = au1000_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1100/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> retrieving revision 1.1.2.6
> diff -u -r1.1.2.6 setup.c
> --- pb1100/setup.c 31 Dec 2002 05:00:22 -0000 1.1.2.6
> +++ pb1100/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -71,7 +71,6 @@
> extern struct rtc_ops pb1500_rtc_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> extern void au1000_halt(void);
> @@ -82,11 +81,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1100_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -112,7 +106,6 @@
> argptr = prom_getcmdline();
> #endif
>
> - __wbflush = au1100_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1500/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> retrieving revision 1.1.2.10
> diff -u -r1.1.2.10 setup.c
> --- pb1500/setup.c 29 Dec 2002 10:30:35 -0000 1.1.2.10
> +++ pb1500/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -43,7 +43,6 @@
> #include <asm/mipsregs.h>
> #include <asm/reboot.h>
> #include <asm/pgtable.h>
> -#include <asm/wbflush.h>
> #include <asm/au1000.h>
> #include <asm/pb1500.h>
>
> @@ -72,7 +71,6 @@
> extern struct rtc_ops pb1500_rtc_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> extern void au1000_halt(void);
> @@ -87,11 +85,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1500_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -117,7 +110,6 @@
> argptr = prom_getcmdline();
> #endif
>
> - __wbflush = au1500_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
^ permalink raw reply
* Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Pete Popov @ 2003-03-21 18:57 UTC (permalink / raw)
To: Linux MIPS mailing list
In-Reply-To: <20030314135721.G20129@luca.pas.lab>
Jeff,
I don't touch generic files, especially io.h :), so Ralf will have to
decide whether to apply the patch or not.
Pete
> Additionally, I had to apply the patch to include/asm-mips/io.h in order
> to get the hermes/orinoco drivers to compile. (I posted this patch earlier, and
> someone suggested that the SLOW_DOWN_IO; call was not necessary). Find it below.
>
> I have some other patches applied; they should not affect PCMCIA. I'll check
> out clean source and patch it with this bare minimum, and let you know
> if something else is required.
>
> Thanks, Pete -- a FAQ about your patches will really help people who are
> starting out on the Alchemy platform.
>
> Regards,
>
> Jeff
>
>
> Index: io.h
> ===================================================================
> RCS file: /home/cvs/linux/include/asm-mips/io.h,v
> retrieving revision 1.29.2.20
> diff -u -r1.29.2.20 io.h
> --- io.h 25 Feb 2003 22:03:12 -0000 1.29.2.20
> +++ io.h 14 Mar 2003 21:50:14 -0000
> @@ -332,12 +332,25 @@
> SLOW_DOWN_IO; \
> } while(0)
> °
> -#define outw_p(val,port) \
> -do { \
> - *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
> - __ioswab16(val); \
> - SLOW_DOWN_IO; \
> -} while(0)
> +/* baitisj */
> +static inline u16 outw_p(u16 val, unsigned long port)
> +{
> + register u16 retval;
> + do {
> + retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
> + __ioswab16(val);
> + SLOW_DOWN_IO;
> + } while(0);
> + return retval;
> +}
> +/*°°
> + * #define outw_p(val,port) \
> + * do { \
> + * *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
> + * __ioswab16(val); \
> + * SLOW_DOWN_IO; \
> + * } while(0)
> + */
> °
> #define outl_p(val,port) \
> do { \
>
^ permalink raw reply
* Re: Patches for all four au1000 setup.c files
From: Jeff Baitis @ 2003-03-21 19:39 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: Linux MIPS mailing list
In-Reply-To: <3E7AD36E.26E2EA94@ekner.info>
On the subject of __wbflush():
It seems to me that setup.c should be exporting __wbflush, since there are some
modules that require this symbol. Try compiling the 8139 ethernet module, or
HostAP wireless drivers :)
Are the following patches correct?
Thanks!
-Jeff
Index: Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/Makefile,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 Makefile
--- Makefile 5 Mar 2003 08:18:58 -0000 1.1.2.2
+++ Makefile 21 Mar 2003 19:34:11 -0000
@@ -19,4 +19,6 @@
obj-y := init.o setup.o
+export-objs := setup.o
+
include $(TOPDIR)/Rules.make
Index: setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 setup.c
--- setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
+++ setup.c 21 Mar 2003 19:34:19 -0000
@@ -242,3 +242,7 @@
return phys_addr;
}
#endif
+
+#include <linux/module.h>
+EXPORT_SYMBOL(__wbflush);
+
On Fri, Mar 21, 2003 at 09:55:10AM +0100, Hartvig Ekner wrote:
> Hi,
>
> the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
>
> The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> which support it.
>
> /Hartvig
>
>
> Index: db1x00/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- db1x00/setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
> +++ db1x00/setup.c 21 Mar 2003 08:44:49 -0000
> @@ -61,7 +61,6 @@
> extern struct ide_ops *ide_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern struct rtc_ops no_rtc_ops;
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> @@ -76,11 +75,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1x00_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -109,14 +103,13 @@
> }
> #endif
>
> -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
> // au1000 does not support vra, au1500 and au1100 do
> - strcat(argptr, " au1000_audio=vra");
> - argptr = prom_getcmdline();
> + strcat(argptr, " au1000_audio=vra");
> + argptr = prom_getcmdline();
> #endif
>
> rtc_ops = &no_rtc_ops;
> - __wbflush = au1x00_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1000/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> retrieving revision 1.8.2.8
> diff -u -r1.8.2.8 setup.c
> --- pb1000/setup.c 11 Dec 2002 06:12:29 -0000 1.8.2.8
> +++ pb1000/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -67,7 +67,6 @@
> extern struct ide_ops *ide_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern struct rtc_ops no_rtc_ops;
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> @@ -78,11 +77,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1000_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -103,7 +97,6 @@
> #endif
>
> rtc_ops = &no_rtc_ops;
> - __wbflush = au1000_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1100/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> retrieving revision 1.1.2.6
> diff -u -r1.1.2.6 setup.c
> --- pb1100/setup.c 31 Dec 2002 05:00:22 -0000 1.1.2.6
> +++ pb1100/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -71,7 +71,6 @@
> extern struct rtc_ops pb1500_rtc_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> extern void au1000_halt(void);
> @@ -82,11 +81,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1100_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -112,7 +106,6 @@
> argptr = prom_getcmdline();
> #endif
>
> - __wbflush = au1100_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
> Index: pb1500/setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> retrieving revision 1.1.2.10
> diff -u -r1.1.2.10 setup.c
> --- pb1500/setup.c 29 Dec 2002 10:30:35 -0000 1.1.2.10
> +++ pb1500/setup.c 21 Mar 2003 08:44:50 -0000
> @@ -43,7 +43,6 @@
> #include <asm/mipsregs.h>
> #include <asm/reboot.h>
> #include <asm/pgtable.h>
> -#include <asm/wbflush.h>
> #include <asm/au1000.h>
> #include <asm/pb1500.h>
>
> @@ -72,7 +71,6 @@
> extern struct rtc_ops pb1500_rtc_ops;
> #endif
>
> -void (*__wbflush) (void);
> extern char * __init prom_getcmdline(void);
> extern void au1000_restart(char *);
> extern void au1000_halt(void);
> @@ -87,11 +85,6 @@
>
> void __init bus_error_init(void) { /* nothing */ }
>
> -void au1500_wbflush(void)
> -{
> - __asm__ volatile ("sync");
> -}
> -
> void __init au1x00_setup(void)
> {
> char *argptr;
> @@ -117,7 +110,6 @@
> argptr = prom_getcmdline();
> #endif
>
> - __wbflush = au1500_wbflush;
> _machine_restart = au1000_restart;
> _machine_halt = au1000_halt;
> _machine_power_off = au1000_power_off;
--
Jeffrey Baitis - Associate Software Engineer
Evolution Robotics, Inc.
130 West Union Street
Pasadena CA 91103
tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply
* Re: Success! Full CardBus/EXCA on PCI->Cardbus Bridge + DbAU1500
From: Juan Quintela @ 2003-03-21 20:54 UTC (permalink / raw)
To: Pete Popov; +Cc: Linux MIPS mailing list
In-Reply-To: <1048273049.14211.56.camel@zeus.mvista.com>
>>>>> "pete" == Pete Popov <ppopov@mvista.com> writes:
Hi
>> Index: io.h
>> ===================================================================
>> RCS file: /home/cvs/linux/include/asm-mips/io.h,v
>> retrieving revision 1.29.2.20
>> diff -u -r1.29.2.20 io.h
>> --- io.h 25 Feb 2003 22:03:12 -0000 1.29.2.20
>> +++ io.h 14 Mar 2003 21:50:14 -0000
>> @@ -332,12 +332,25 @@
>> SLOW_DOWN_IO; \
>> } while(0)
>> °
>> -#define outw_p(val,port) \
>> -do { \
>> - *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) = \
>> - __ioswab16(val); \
>> - SLOW_DOWN_IO; \
>> -} while(0)
>> +/* baitisj */
>> +static inline u16 outw_p(u16 val, unsigned long port)
>> +{
>> + register u16 retval;
>> + do {
>> + retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
>> + __ioswab16(val);
>> + SLOW_DOWN_IO;
>> + } while(0);
>> + return retval;
>> +}
static inline u16 outw_p(u16 val, unsigned long port)
{
u16 retval;
retval = *(volatile u16 *)(mips_io_port_base + __swizzle_addr_w(port)) =
__ioswab16(val);
SLOW_DOWN_IO;
return retval;
}
while do construct inside a function shouldn't be needed when you have
a function. And register is obsolete :)
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Patches for all four au1000 setup.c files
From: Hartvig Ekner @ 2003-03-21 22:12 UTC (permalink / raw)
To: baitisj; +Cc: Linux MIPS mailing list
In-Reply-To: <20030321113940.O26687@luca.pas.lab>
Hi Jeff,
Are you talking about these two 8139 files from 2.4?
/home/hartvige/src/linux/linux-ralf/drivers/net> ls *8139*.c
8139cp.c 8139too.c
I can't see that they are using wbflush in any way. Grepping after wbflush through the
entire 2.4 tree, it seems wbflush is something only present on some dec platforms and then
the au1000 stuff - which would mean that any driver directly calling __wbflush would be
unable to compile/load on the majority of kernels. Or am I missing something? (I haven't
been using modules under MIPS at all).
In fact, I can't find a single file including wbflush.h except system.h, and it doesn't look
like anybody else should directly be including the wbflush.h file, but only use the macros
in system.h:
#define wmb() fast_wmb()
#define rmb() fast_rmb()
#define mb() wbflush();
#define iob() wbflush();
(which are differently defined if there is no WB configured).
/Hartvig
Jeff Baitis wrote:
> On the subject of __wbflush():
>
> It seems to me that setup.c should be exporting __wbflush, since there are some
> modules that require this symbol. Try compiling the 8139 ethernet module, or
> HostAP wireless drivers :)
>
> Are the following patches correct?
> Thanks!
>
> -Jeff
>
> Index: Makefile
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/Makefile,v
> retrieving revision 1.1.2.2
> diff -u -r1.1.2.2 Makefile
> --- Makefile 5 Mar 2003 08:18:58 -0000 1.1.2.2
> +++ Makefile 21 Mar 2003 19:34:11 -0000
> @@ -19,4 +19,6 @@
>
> obj-y := init.o setup.o
>
> +export-objs := setup.o
> +
> include $(TOPDIR)/Rules.make
>
> Index: setup.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> retrieving revision 1.1.2.3
> diff -u -r1.1.2.3 setup.c
> --- setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
> +++ setup.c 21 Mar 2003 19:34:19 -0000
> @@ -242,3 +242,7 @@
> return phys_addr;
> }
> #endif
> +
> +#include <linux/module.h>
> +EXPORT_SYMBOL(__wbflush);
> +
>
> On Fri, Mar 21, 2003 at 09:55:10AM +0100, Hartvig Ekner wrote:
> > Hi,
> >
> > the patches below for all four au1000 setup.c files removes the wbflush() routine, as this is no longer necessary
> > (handled by the generic code now, which does a sync). This also means that it is not necessary to say yes to
> > CONFIG_CPU_ADVANCED and override the CPU_HAS_WB setting, as the generic MIPS32 code will do just fine.
> >
> > The patch for the db1x00 setup.c file also fixes a bug which prevented VRA from being used with Audio Codecs
> > which support it.
> >
> > /Hartvig
> >
> >
>
> > Index: db1x00/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/db1x00/Attic/setup.c,v
> > retrieving revision 1.1.2.3
> > diff -u -r1.1.2.3 setup.c
> > --- db1x00/setup.c 7 Jan 2003 10:41:30 -0000 1.1.2.3
> > +++ db1x00/setup.c 21 Mar 2003 08:44:49 -0000
> > @@ -61,7 +61,6 @@
> > extern struct ide_ops *ide_ops;
> > #endif
> >
> > -void (*__wbflush) (void);
> > extern struct rtc_ops no_rtc_ops;
> > extern char * __init prom_getcmdline(void);
> > extern void au1000_restart(char *);
> > @@ -76,11 +75,6 @@
> >
> > void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1x00_wbflush(void)
> > -{
> > - __asm__ volatile ("sync");
> > -}
> > -
> > void __init au1x00_setup(void)
> > {
> > char *argptr;
> > @@ -109,14 +103,13 @@
> > }
> > #endif
> >
> > -#if defined(CONFIG_SOUND_AU1000) && !defined(CONFIG_CPU_AU1000)
> > +#if defined(CONFIG_SOUND_AU1X00) && !defined(CONFIG_CPU_AU1000)
> > // au1000 does not support vra, au1500 and au1100 do
> > - strcat(argptr, " au1000_audio=vra");
> > - argptr = prom_getcmdline();
> > + strcat(argptr, " au1000_audio=vra");
> > + argptr = prom_getcmdline();
> > #endif
> >
> > rtc_ops = &no_rtc_ops;
> > - __wbflush = au1x00_wbflush;
> > _machine_restart = au1000_restart;
> > _machine_halt = au1000_halt;
> > _machine_power_off = au1000_power_off;
> > Index: pb1000/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1000/setup.c,v
> > retrieving revision 1.8.2.8
> > diff -u -r1.8.2.8 setup.c
> > --- pb1000/setup.c 11 Dec 2002 06:12:29 -0000 1.8.2.8
> > +++ pb1000/setup.c 21 Mar 2003 08:44:50 -0000
> > @@ -67,7 +67,6 @@
> > extern struct ide_ops *ide_ops;
> > #endif
> >
> > -void (*__wbflush) (void);
> > extern struct rtc_ops no_rtc_ops;
> > extern char * __init prom_getcmdline(void);
> > extern void au1000_restart(char *);
> > @@ -78,11 +77,6 @@
> >
> > void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1000_wbflush(void)
> > -{
> > - __asm__ volatile ("sync");
> > -}
> > -
> > void __init au1x00_setup(void)
> > {
> > char *argptr;
> > @@ -103,7 +97,6 @@
> > #endif
> >
> > rtc_ops = &no_rtc_ops;
> > - __wbflush = au1000_wbflush;
> > _machine_restart = au1000_restart;
> > _machine_halt = au1000_halt;
> > _machine_power_off = au1000_power_off;
> > Index: pb1100/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1100/setup.c,v
> > retrieving revision 1.1.2.6
> > diff -u -r1.1.2.6 setup.c
> > --- pb1100/setup.c 31 Dec 2002 05:00:22 -0000 1.1.2.6
> > +++ pb1100/setup.c 21 Mar 2003 08:44:50 -0000
> > @@ -71,7 +71,6 @@
> > extern struct rtc_ops pb1500_rtc_ops;
> > #endif
> >
> > -void (*__wbflush) (void);
> > extern char * __init prom_getcmdline(void);
> > extern void au1000_restart(char *);
> > extern void au1000_halt(void);
> > @@ -82,11 +81,6 @@
> >
> > void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1100_wbflush(void)
> > -{
> > - __asm__ volatile ("sync");
> > -}
> > -
> > void __init au1x00_setup(void)
> > {
> > char *argptr;
> > @@ -112,7 +106,6 @@
> > argptr = prom_getcmdline();
> > #endif
> >
> > - __wbflush = au1100_wbflush;
> > _machine_restart = au1000_restart;
> > _machine_halt = au1000_halt;
> > _machine_power_off = au1000_power_off;
> > Index: pb1500/setup.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/au1000/pb1500/setup.c,v
> > retrieving revision 1.1.2.10
> > diff -u -r1.1.2.10 setup.c
> > --- pb1500/setup.c 29 Dec 2002 10:30:35 -0000 1.1.2.10
> > +++ pb1500/setup.c 21 Mar 2003 08:44:50 -0000
> > @@ -43,7 +43,6 @@
> > #include <asm/mipsregs.h>
> > #include <asm/reboot.h>
> > #include <asm/pgtable.h>
> > -#include <asm/wbflush.h>
> > #include <asm/au1000.h>
> > #include <asm/pb1500.h>
> >
> > @@ -72,7 +71,6 @@
> > extern struct rtc_ops pb1500_rtc_ops;
> > #endif
> >
> > -void (*__wbflush) (void);
> > extern char * __init prom_getcmdline(void);
> > extern void au1000_restart(char *);
> > extern void au1000_halt(void);
> > @@ -87,11 +85,6 @@
> >
> > void __init bus_error_init(void) { /* nothing */ }
> >
> > -void au1500_wbflush(void)
> > -{
> > - __asm__ volatile ("sync");
> > -}
> > -
> > void __init au1x00_setup(void)
> > {
> > char *argptr;
> > @@ -117,7 +110,6 @@
> > argptr = prom_getcmdline();
> > #endif
> >
> > - __wbflush = au1500_wbflush;
> > _machine_restart = au1000_restart;
> > _machine_halt = au1000_halt;
> > _machine_power_off = au1000_power_off;
>
> --
> Jeffrey Baitis - Associate Software Engineer
>
> Evolution Robotics, Inc.
> 130 West Union Street
> Pasadena CA 91103
>
> tel: 626.535.2776 | fax: 626.535.2777 | baitisj@evolution.com
^ permalink raw reply
* Re: Patches for all four au1000 setup.c files
From: Juan Quintela @ 2003-03-21 22:33 UTC (permalink / raw)
To: Hartvig Ekner; +Cc: baitisj, Linux MIPS mailing list
In-Reply-To: <3E7B8E39.CC463FEC@ekner.info>
>>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:
hartvig> I can't see that they are using wbflush in any way. Grepping
hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
hartvig> is something only present on some dec platforms and then the
hartvig> au1000 stuff - which would mean that any driver directly
hartvig> calling __wbflush would be unable to compile/load on the
hartvig> majority of kernels. Or am I missing something? (I haven't
hartvig> been using modules under MIPS at all).
Yes, you missed the definition of mb() :p
quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
drivers/net/8139too.c: mb();
quintela$
hartvig> In fact, I can't find a single file including wbflush.h
hartvig> except system.h, and it doesn't look like anybody else should
hartvig> directly be including the wbflush.h file, but only use the
hartvig> macros in system.h:
hartvig> #define wmb() fast_wmb()
hartvig> #define rmb() fast_rmb()
hartvig> #define mb() wbflush();
hartvig> #define iob() wbflush();
hartvig> (which are differently defined if there is no WB configured).
but WB is configured in :)
quintela$ grep WB arch/mips/defconfig-pb1*
arch/mips/defconfig-pb1000:CONFIG_CPU_HAS_WB=y
arch/mips/defconfig-pb1100:CONFIG_CPU_HAS_WB=y
arch/mips/defconfig-pb1500:CONFIG_CPU_HAS_WB=y
quintela$
Other thing is that this machine should be using wbflush at all, but
that is a different story. I agree with (/me looks in archive),
*your* patch removing wbflush for that boards. They are only doing
"sync" ond wbflush, and that is the thing that __sync() already does.
I.e. If I have to chooses wich patch to integrate, the one exporting
__wbflush(), or the one removing it altogether from pb1*, I will
choose removing it. It looks superflous.
Later, Juan "who don't have that processor, and handwaving is easy".
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Patches for all four au1000 setup.c files
From: Hartvig Ekner @ 2003-03-21 22:45 UTC (permalink / raw)
To: Juan Quintela; +Cc: baitisj, Linux MIPS mailing list
In-Reply-To: <86fzpgpcy6.fsf@trasno.mitica>
Hi Juan,
Juan Quintela wrote:
> >>>>> "hartvig" == Hartvig Ekner <hartvig@ekner.info> writes:
>
> hartvig> I can't see that they are using wbflush in any way. Grepping
> hartvig> after wbflush through the entire 2.4 tree, it seems wbflush
> hartvig> is something only present on some dec platforms and then the
> hartvig> au1000 stuff - which would mean that any driver directly
> hartvig> calling __wbflush would be unable to compile/load on the
> hartvig> majority of kernels. Or am I missing something? (I haven't
> hartvig> been using modules under MIPS at all).
>
> Yes, you missed the definition of mb() :p
>
> quintela$ grep "mb(" drivers/net/8139* | grep -v rmb | grep -v wmb
> drivers/net/8139too.c: mb();
> quintela$
>
> hartvig> In fact, I can't find a single file including wbflush.h
> hartvig> except system.h, and it doesn't look like anybody else should
> hartvig> directly be including the wbflush.h file, but only use the
> hartvig> macros in system.h:
>
> hartvig> #define wmb() fast_wmb()
> hartvig> #define rmb() fast_rmb()
> hartvig> #define mb() wbflush();
> hartvig> #define iob() wbflush();
>
> hartvig> (which are differently defined if there is no WB configured).
>
> but WB is configured in :)
>
That's the problem! Wb does not need to be configured in, it is a mistake. My patch was missing
the required fixes to the defconfig files, it was only described in the mail. So I think the only
thing missing is a patch to fix all the pb/db defconfig files to look like this:
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
# CONFIG_CPU_HAS_LLDSCD is not set
# CONFIG_CPU_HAS_WB is not set
CONFIG_CPU_HAS_SYNC=y
... which is the setting also used by all other MIPS32 CPUs. Then everything should be ok.
/Hartvig
>
> quintela$ grep WB arch/mips/defconfig-pb1*
> arch/mips/defconfig-pb1000:CONFIG_CPU_HAS_WB=y
> arch/mips/defconfig-pb1100:CONFIG_CPU_HAS_WB=y
> arch/mips/defconfig-pb1500:CONFIG_CPU_HAS_WB=y
> quintela$
>
> Other thing is that this machine should be using wbflush at all, but
> that is a different story. I agree with (/me looks in archive),
> *your* patch removing wbflush for that boards. They are only doing
> "sync" ond wbflush, and that is the thing that __sync() already does.
>
> I.e. If I have to chooses wich patch to integrate, the one exporting
> __wbflush(), or the one removing it altogether from pb1*, I will
> choose removing it. It looks superflous.
>
> Later, Juan "who don't have that processor, and handwaving is easy".
>
> --
> In theory, practice and theory are the same, but in practice they
> are different -- Larry McVoy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox