Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-09 Thread Ivan Kokshaysky
On Mon, Apr 09, 2001 at 12:02:54PM +0200, Maciej W. Rozycki wrote: > I think you need an mb here. To force sychronization with other CPUs. > Unless you know you are UP or there is no possibility another CPU may > access the relevant device. Yes - in most cases you need synchronization at a high

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-09 Thread Maciej W. Rozycki
On Sun, 8 Apr 2001, Ivan Kokshaysky wrote: > Of course. I meant that if you are reading, for example, some status register > in a loop waiting for "ready bit" set, the memory barrier won't help you > to notice this event any faster. Actually you'll notice that *later*, as > "mb" is expensive. I

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-08 Thread Ivan Kokshaysky
On Fri, Apr 06, 2001 at 07:13:21PM +0200, Maciej W. Rozycki wrote: > You do. PCI-space registers are volatile and they may change depending > on what was written (or read) previously. A memory barrier before a PCI > read will ensure you get a value that is relevant to previous code > actions.

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Maciej W. Rozycki
On Fri, 6 Apr 2001, Andrea Arcangeli wrote: > ev6 works the way you described AFIK (to flush the write buffer you can use Thanks for the clarification -- you made me calm down. > wmb(), note that wmb() semantics doesn't require the cpu to really "flush" but > just to keep writes oredered acros

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Andrea Arcangeli
On Fri, Apr 06, 2001 at 07:27:24PM +0200, Maciej W. Rozycki wrote: > [..] You normally have > non-cached locations buffered (since you don't always need peripheral > device accesses to be posted immediately) and can force a writeback with a > memory barrier. [..] ev6 works the way you described A

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Maciej W. Rozycki
On 6 Apr 2001, Eric W. Biederman wrote: > I recall on the ev6 all memory accesses to locations with bit 40 set > are always to IO space are never cached and are never write buffered. If that is the case then EV6 is seriously flawed. You normally have non-cached locations buffered (since you d

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Maciej W. Rozycki
On Fri, 6 Apr 2001, Ivan Kokshaysky wrote: > > Memory barriers are a separate issue. On the alpha the > > natural way to implement it would be in the page table fill code. > > Memory barriers are o.k. but the really don't help the case when what > > you want to do is read the latest value out o

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Maciej W. Rozycki
On 5 Apr 2001, Eric W. Biederman wrote: > The point is on the Alpha all ram is always cached, and i/o space is > completely uncached. You cannot do write-combing for video card You don't want to cache fb memory, do you? All you want is write combining and you achieve it with memory barriers.

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Eric W. Biederman
Ivan Kokshaysky <[EMAIL PROTECTED]> writes: > On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote: > > The point is on the Alpha all ram is always cached, and i/o space is > > completely uncached. You cannot do write-combing for video card > > memory. > > Incorrect. Alphas have wr

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-06 Thread Ivan Kokshaysky
On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote: > The point is on the Alpha all ram is always cached, and i/o space is > completely uncached. You cannot do write-combing for video card > memory. Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and 4x64 on ev6, IIRC. So

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-05 Thread Eric W. Biederman
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > On Thu, 5 Apr 2001, Geert Uytterhoeven wrote: > > > > 32bit writes on a bus with a word size of 64 or more bits. By the way > > > does anyone know who didn't implement MTRR's or the equivalent on > > > alpha so we can shoot them? > > > > People

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-05 Thread Maciej W. Rozycki
On Thu, 5 Apr 2001, Geert Uytterhoeven wrote: > > 32bit writes on a bus with a word size of 64 or more bits. By the way > > does anyone know who didn't implement MTRR's or the equivalent on > > alpha so we can shoot them? > > People never get shot in Open Source projects. Not when they write bu

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-05 Thread Geert Uytterhoeven
On 5 Apr 2001, Eric W. Biederman wrote: > 32bit writes on a bus with a word size of 64 or more bits. By the way > does anyone know who didn't implement MTRR's or the equivalent on > alpha so we can shoot them? People never get shot in Open Source projects. Not when they write buggy code, not whe

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-05 Thread Eric W. Biederman
James Simmons <[EMAIL PROTECTED]> writes: > >>> As long as you are copying in real memory. So the PCI bus or the host > bridge > >>> implementation may be the actual limit. > >> > >> The CyrixIII sits on the same host bridges as the intel processors > > > >I don't know if it applies to this case

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-04 Thread James Simmons
>>> As long as you are copying in real memory. So the PCI bus or the host bridge >>> implementation may be the actual limit. >> >> The CyrixIII sits on the same host bridges as the intel processors > >I don't know if it applies to this case but one thing I have seen make >a noticeable difference

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-04 Thread Jamie Lokier
Eric W. Biederman wrote: > I don't know if it applies to this case but one thing I have seen make > a noticeable difference is whether or not write-combining is enabled. > If we have only be enabling MTRR's for intel this could do account > for it. And on some laptops, even on Intel MTRRs are not

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-04 Thread Eric W. Biederman
Alan Cox <[EMAIL PROTECTED]> writes: > > > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the > > > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs > > > and for MMX are the same speed > > > > As long as you are copying in real memory. So the PCI

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-03 Thread Alan Cox
> > The MMX memcpy for CyrixIII and Athlon boxes is something like twice the > > speed of rep movs. On most pentium II/III boxes the fast paths for rep movs > > and for MMX are the same speed > > As long as you are copying in real memory. So the PCI bus or the host bridge > implementation may be

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-02 Thread Geert Uytterhoeven
On Mon, 2 Apr 2001, Alan Cox wrote: > > Yes this is problem. See my response to Paul about this. The only reason > > I'm using MMX for the vesa framebuffer because it has no acceleration. MMX > > gives a big boost for genuine intel chips. Other types of MMX are fast but > > they don't seemed to be

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-02 Thread James Simmons
>Is it possible that "jump scroll" would provide more performance benefit >than an accelerated driver anyway? I wouldn't rule it out. If someone wants to wipe up some code I would have no problem testing it to see if it is worth it. >Seeing as you bring up this topic of writing a 9525 driver.

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-02 Thread Alan Cox
> Yes this is problem. See my response to Paul about this. The only reason > I'm using MMX for the vesa framebuffer because it has no acceleration. MMX > gives a big boost for genuine intel chips. Other types of MMX are fast but > they don't seemed to be optimized for memory transfers like MMX on

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-01 Thread Jamie Lokier
James Simmons wrote: > >No, it's the Trident Cyber9525 > > Sorry. I only have a early driver for trident 9750 and 9850. Their is a > gropup working on trident framebuffers. Is it possible that "jump scroll" would provide more performance benefit than an accelerated driver anyway? Seeing as you

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-04-01 Thread James Simmons
>No, it's the Trident Cyber9525 Sorry. I only have a early driver for trident 9750 and 9850. Their is a gropup working on trident framebuffers. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. Jam

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-03-31 Thread Jamie Lokier
James Simmons wrote: > > > You have same toshiba satellite as me, right? > > > > Yes > > Is this the NeoMagic chipset? No, it's the Trident Cyber9525 -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo i

[Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-03-30 Thread James Simmons
>I took to using X, with a single screen size xterm to present the >illusion of console mode. Cute trick. I have seen some slow text mode cards. As time goes on it will get worst since text mode support is not the prime goal anymore. Especially now that you see graphical BIOS interfaces. Some gr

[Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-03-30 Thread James Simmons
>The console driver does not actually use 2.5MB. Does it make sense to >use an MTRR for the smaller power-of-two region? If we implement a font cache in the future it could. Also that extra memory is used to allow scrollback. We could break up the size of the region. Have it a*2^n+b*2^(n-1)+c*2

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

2001-03-30 Thread James Simmons
> > You have same toshiba satellite as me, right? > > Yes Is this the NeoMagic chipset? MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbd