On 26 Aug 2003, John Dennis wrote:
The PCI configuration does provide various pieces of information which
help determine how the device can be accessed, e.g. pre-fetch, latency,
cache line size etc. All of this is available to firmware. Wouldn't all
this be sufficient for firmware to make the
On Thu, 28 Aug 2003, Marc Aurele La France wrote:
It occurs to me that we should probably change XAA to flush CPU caches
just after calling the driver's Sync() function, and change mibank to do
the same after telling the driver to switch banks.
That is a hardware issue and something the
On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote:
Secondly, EFI is already doing the wrong thing by marking PCI ROMs as
non-cacheable. This doesn't inspire confidence...
I believe there is a difference between ROM's being logically cacheable
and the way the ZX1 actually wires that
On Thu, 28 Aug 2003, Mark Vojkovich wrote:
It occurs to me that we should probably change XAA to flush CPU caches
just after calling the driver's Sync() function, and change mibank to do
the same after telling the driver to switch banks.
That is a hardware issue and something the
On Thu, 28 Aug 2003, Marc Aurele La France wrote:
On 28 Aug 2003, John Dennis wrote:
On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote:
Secondly, EFI is already doing the wrong thing by marking PCI ROMs as
non-cacheable. This doesn't inspire confidence...
I believe there is a
On Thu, 28 Aug 2003, Marc Aurele La France wrote:
On Thu, 28 Aug 2003, Mark Vojkovich wrote:
It occurs to me that we should probably change XAA to flush CPU caches
just after calling the driver's Sync() function, and change mibank to do
the same after telling the driver to switch
On Thu, 2003-08-28 at 16:40, Marc Aurele La France wrote:
... which basically means that framebuffers cannot benifit from CPU
caching. I don't beleive this to be the case.
Further to this, it appears you don't realise that the frambuffers we're
talking about here, _are_ in PCI space.
Hi John,
thanks on following up on this.
John Dennis writes:
Anytime in the XServer when MMIO was specified as a mapping flag the
ia64 code would have requested non-cached, this is done for all register
mappings and the VGA framebuffer (because write combining was avoided on
banked
John Dennis writes:
I will confess my understanding is weak when it comes to low level bus
interactions, but I'm learning more eveytime I have to tackle these
issues ;-)
Correct me if I'm wrong, but I thought things like caching and
write-combining are not properties of the PCI
On Wed, 2003-08-27 at 06:15, Egbert Eich wrote:
Appearantly there are still issues with VGA framebuffer and emulated
PIO register writes when saving and restoring fonts. These problems
only affect certain cards (so far I've only heared of Nvidia cards).
Mark Vojkovich is sure that these are
On 27 Aug 2003, John Dennis wrote:
Mark, is there a hardware engineer at nvidia that would be familar with
the VGA timing? Is it possible your VGA is running near or beyond the
limits of the PCI timing requirements? My understanding is the ZX1 is a
very aggressive chipset tuned for high
On Tue, 26 Aug 2003, Egbert Eich wrote:
John Dennis writes:
I just received information from HP (thank you Bjorn Helgaas) that the
memory attribute does not direct access between RAM and IO, I was in
error. But what is critical is that the EFI MDT (Memory Descriptor
Table?) which is
I just wanted to follow up with this for those who are maintaining the
memory mapping code in the CVS tree, this is linux ia64 specific and
possibly HP ZX1 specific. As of today this is best information I have
and wanted to share it.
Originally the MAP_NONCACHED passed to mmap caused non-cached
On Tue, 2003-08-26 at 10:22, Marc Aurele La France wrote:
Frankly, I don't see how this EFI MDT can be accurate given that, in
general, whether or not a particular PCI memory assignment will tolerate
caching and/or write-combining is highly device-specific. That would be a
horrific PCI device
Marc Aurele La France writes:
On Tue, 26 Aug 2003, Egbert Eich wrote:
Frankly, I don't see how this EFI MDT can be accurate given that, in
general, whether or not a particular PCI memory assignment will tolerate
caching and/or write-combining is highly device-specific. That would be
On Tue, 2003-08-26 at 13:40, Egbert Eich wrote:
Marc Aurele La France writes:
On Tue, 26 Aug 2003, Egbert Eich wrote:
Frankly, I don't see how this EFI MDT can be accurate given that, in
general, whether or not a particular PCI memory assignment will tolerate
caching and/or
I have spent quite a bit of time investigating this issue and I think
we now understand the underlying issue.
The various places in XFree86 that mmap memory seem to very careful to
specify the proper mapping attributes, e.g. when mapping registers
with ordering requirements and side-effects (e.g.
On Mon, 2003-08-25 at 14:51, David Dawes wrote:
However on IA64 the concept of caching is overloaded, not only does it
refer to memory coherence but more importantly selects between two
vastly different memory spaces, RAM and IO. A cached access is
directed to RAM and a non-cached access is
We are working through an issue on IA64 (Itanium2) and would
like to consult the developer community on our approach.
On a 4.3.0-based XFree86, we are having difficulties properly
initializing multiple graphics cards with Int10. Most
specifically, mapping and reading the video
On Thu, 21 Aug 2003, John M. Fujii wrote:
We are working through an issue on IA64 (Itanium2) and would
like to consult the developer community on our approach.
On a 4.3.0-based XFree86, we are having difficulties properly
initializing multiple graphics cards with Int10. Most
specifically,
20 matches
Mail list logo
