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
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
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.
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
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
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
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
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.
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
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
"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
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
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
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
>>> 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
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
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
> > 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
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
>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.
> 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
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
>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
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
>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
>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
> > 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
27 matches
Mail list logo