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
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.
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 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 higher
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, 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
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
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
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
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
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.
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
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 write
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.
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 of a pci
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
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 across
"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?
> >
> >
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
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
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
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 but one thing I have
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 when
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 buggy
"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 never get shot
>>> 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
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
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 bus or the
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
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 is whether
> > 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
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
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 the
>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
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
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. It
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.
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.
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
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
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 info at
>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
>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
> > 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]] /|
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]] /|
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
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
53 matches
Mail list logo
