On Tue, 2004-02-03 at 17:37, Marc Aurele La France wrote:
PCI-Xpress is programmatically identical to PCI, so I don't forsee any
problems in that regard.
Yes, its identical to PCI in terms of the interface presented to the OS
so configuration probably won't be an issue, but there is code in
anticipated to support PCIE only systems? And if so what's the
timeframe?
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
? If so
do they manage AGP themselves, or do they use the systems agpgart
driver? Do they replace the systems agpgart driver?
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ]
I'm trying to debug a hung X server problem with DRI using the radeon
driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at
the moment I don't see anything architecture specific about the problem.
The symptom
On Wed, 2003-09-10 at 20:11, David Dawes wrote:
John wrapper. So as long as we've already lost module
John independence by virtue of linking the system function why
John not go all the way and use the system definition of the
John system function's argument? It seems like
On Thu, 2003-09-11 at 14:35, David Dawes wrote:
What's the difference between this in the core executable:
xf86A(pointer data)
{
return A(data);
}
SYMFUNC(xf86A)
and this:
SYMFUNCALIAS(xf86A, A)
The difference is that xf86A may massage data in some system specific
I have found the problem with XFree86's implementation of setjmp on
ia64. It occurs because we are ignoring the type definition of
setjmp's argument.
int setjmp(jmp_buf env);
In xf86_lib.h we redefine jmp_buf thusly:
/* setjmp/longjmp */
typedef int xf86jmp_buf[1024];
#undef jmp_buf
be wrapped. What ever came of that?
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
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, 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.
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
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
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.
to swap out physical pages.. */
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
=anoncvs.xfree86.org
base=/home/boston/jdennis/.cvsup
*default prefix=/home/boston/jdennis/src/xfree86 delete use-rel-suffix
*default compress
*default tag=.
xc-all
doctools-all
contrib-all
xtest-all
utils-all
--
John Dennis [EMAIL PROTECTED]
___
Devel
? If not can you help explain where
I'm missing the mark and what the actual issues are?
John
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
At at previous job I was responsible for XFree86 Cyberpro drivers. Tvia
(www.tvia.com) had supplied us with source code for their XFree86 4.x
Cyberpro driver that worked reasonably well. I did have to make a few
fixes and we did add some enhancements.
The point of this is that Tvia does develop
20 matches
Mail list logo
