Fwd: 69030 driver
-- Forwarded Message -- Subject: 69030 driver Date: Thursday 11 Sep 2003 4:21 pm From: Rishabh Kumar Goel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] i m trying to write a MDA driver for C&T's 69030 chip. The PCI card is memory mapped. starting from 0x080 with the memory size requirement of 16MB. How to access the Character Buffer of MDA which lies in the lower address map of 0xB000-0xB7FF ? I m able to read and write to the registers. I tried writing the a word of data(0xaa55) at 0x0800a but on reading it back i got 0x. What is this problem? am i reading the memory properly. Please help. -- Regards, Rishabh Kumar Goel Associate Software Engineer SoCrates Software India Pvt. Ltd. Bangalore --- -- Regards, Rishabh Kumar Goel Associate Software Engineer SoCrates Software India Pvt. Ltd. Bangalore Scanned by SecureSynergy VirusScreen Service. For more information log on to : http://www.securesynergyonline.com or http://www.securesynergy.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Wed, 10 Sep 2003, John Dennis wrote:
>JD> alignment requirement right how do we specify the alignment requirement
>JD> to the compiler in a portable way such that it will build on a variety
>JD> of systems and compilers?
>
>Juliusz> typedef union {int i[1024]; long long l;} jmp_buf;
>
>Yes, I thought of that too, but "long long" isn't portable, right?
>Plus it still leaves us guessing we've covered the requirements.
long long is ISO C99
--
Mike A. Harris
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Fwd: 69030 driver
You have to map 0xB - 0xC for that. Egbert. Rishabh Kumar Goel writes: > -- Forwarded Message -- > > Subject: 69030 driver > Date: Thursday 11 Sep 2003 4:21 pm > From: Rishabh Kumar Goel <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > i m trying to write a MDA driver for C&T's 69030 chip. The PCI card is memory > mapped. starting from 0x080 with the memory size requirement of 16MB. > > How to access the Character Buffer of MDA which lies in the lower address > map of 0xB000-0xB7FF ? > I m able to read and write to the registers. > > I tried writing the a word of data(0xaa55) at 0x0800a but on reading it > back i got 0x. > > What is this problem? am i reading the memory properly. > Please help. > > > -- > Regards, > Rishabh Kumar Goel > Associate Software Engineer > SoCrates Software India Pvt. Ltd. > Bangalore > > --- > > -- > Regards, > Rishabh Kumar Goel > Associate Software Engineer > SoCrates Software India Pvt. Ltd. > Bangalore > > Scanned by SecureSynergy VirusScreen Service. > For more information log on to : http://www.securesynergyonline.com or > http://www.securesynergy.com > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: Re: Fwd: Vblank support in kernel and X server]
On Mer, 2003-09-10 at 23:21, Michel Dänzer wrote: > On Wed, 2003-09-10 at 19:00, Jim Gettys wrote: > > Here's Alan Cox's mail about it. In 2.4.20-ac1. > > Won't this conflict with the DRM vblank interrupt handling? (I've also > seen framebuffer device patches for this...) Thats a matter for the X server driver modules. If DRM provides it then don't ask for it from the vblank code. In the case of framebuffer the same can be said. It needs some further work yet but Soeren has mostly fixed the mess I made ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
An audio server need not be designed to add latency (beyond that of the network itself, of course). With current networks, this is very small, down to a few samples. Existence proof is the AF audio server we did 10 years ago, in which the server design itself did not enforce any latency: if data arrived at the AF server before the sample had been played (and the hardware permitted), it performed cut-through and updated the samples immediately. - Jim On Wed, 2003-09-10 at 17:54, Ross Vandegrift wrote: > On Wed, Sep 10, 2003 at 11:09:54AM -0400, Jim Gettys wrote: > > The other promising work besides MAS is an audio server project > > called "Jack". > > > > It is not clear it currently provides network transparency, but it > > does boast low latency (required for telephony, teleconferencing and > > gaming applications). > > No, jack is intended for apps with much stricter performance > requirements - low latency, sample synchronization, and realtime > transport. These are pretty critical for pro audio work - recording, > production, soundtracking, overdubs, etc. > > It's very doubtful it will ever work over conventional networks - timing > is just too critical to jack. > > Now, a specially designed network with ADAT synchronization could work, > but I doubt anyone would want to port X11 to such a transport... ::-) -- Jim Gettys <[EMAIL PROTECTED]> HP Labs, Cambridge Research Laboratory ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
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
David> We haven't lost module independence by doing that.
Perhaps I'm misunderstanding module independence, can you confirm or
deny some of the assumptions I've been working with:
1) System specific functions are wrapped in an xf86* wrapper so that:
a) system differences are isolated at a single point which provides
a common interface to the rest of the server
b) all system specific functions are wrapped and live in the
executable XFree86. The XFree86 executable is linked against
the system libraries and hence the XFree86 executable is not
system independent.
2) module independence derives from the following:
a) modules only link against (e.g. import) from the XFree86
executable that loaded it. In other words all system
specific elements are contained in the executable, not a
loaded module.
b) The executable and modules share the same linking,
relocation, exception, and call conventions. This makes
a module mostly system independent, but not 100%, e.g.
its possible, but not common, for different OS's on the same
architecture to have a different ABI, but less common today
as the industry is converging on standardized ABI's.
Is the above basically correct?
If so then by directly linking a reference to the system's setjmp call
in a module haven't we violated the notion that only the main
executable has dependencies on the system libraries? The module is now
making a call whose parameters and behavior is specific to the
system. Actually, more correctly, its specific to the how the main
executable was linked (which is system specific), see below for why
this is true.
David> All that matters is that the jmp_buf type be defined on
David> each architecture in such a way that it meets the
David> requirements of all the supported OSs on that architecture.
David> Newer architectures are more likely to have a
David> platform-independent ABI anyway than was necessarily true
David> in the past. If the platform's can define the
David> type with the correct alignment, then so can we. It
David> doesn't matter if the methods for doing this are
David> compiler-specific. If the 128-bit alignment is an IA64 ABI
David> requirement, then I'd expect that all complilers for IA64
David> will have a method for defining jmp_buf with the correct
David> alignment.
If I following your reasoning then you would be happy with this
definition in xf86_libc.h
/* setjmp/longjmp */
#if defined(__ia64__)
typedef int xf86jmp_buf[1024]; __attribute__ ((aligned (16))); /* guarantees 128-bit
alignment! */
#else
typedef int xf86jmp_buf[1024];
#endif
But if one is going to special case the definition of jmp_buf based on
architecture why not use the system definition and typedef xf86jmp_buf
to be jmp_buf? I suspect the answer will be that the system libraries
could change requiring a different size buffer. I'd buy that if it
weren't for the fact we are directly linking the library specfic
version of setjmp into the module.
Why a module referencing setjmp is tied to a specific system library:
-
As far as I can tell we've tied the module to a specific system
library. Here is why I believe this. I'm going to simplify the
discussion by assming there is only one xf86set_jmp symbol and ignore
the type 0 and type 1 variants that select setjmp or sigsetjmp.
1) a module makes a reference to xf86set_jmp.
2) the xfree86 loader when it loads that module searches for that
symbol in its hash table of symbols, that table was populated in
part by the table in xf86sym.c which in a loadable build contains
this definition in the main executable:
#include
SYMFUNCALIAS("xf86setjmp",setjmp)
3) the above definition means when the symbol name "xf86setjmp" is
looked up by the loader it will get the address of setjmp that was
linked into the main executable. This is the function address that
the xfree86 loader will insert into module during its relocation
phase.
4) How does the address of setjmp get into the main executable? It
depends on whether the main executable was statically or
dynamically linked, but in either case the system will assure it
comes from a specific version of the library defined at the time
the main executable was linked.
5) Therefore when a module that referenced setjmp is called its
calling the system version of setjmp in the exact library when the
main executable was linked.
I don't see how the above satisfies the conception of module
independence and by extension the avoidence of using th
Re: Fwd: 69030 driver
Hi! Thanks for your suggestion. I tried that but nothing worked out. i am working on NetBSD. So i mapped the memory from 0xA to 0xB. From this memory mapped I tried to read a single byte from the device and also the word but of no use. I get only 0xFF. My first aim is to get the Green Light(LED) on the monitor to glow. How to get that thing. Regards, Rishabh On Thursday 11 Sep 2003 1:59 pm, Egbert Eich wrote: > You have to map 0xB - 0xC for that. > > Egbert. > > Rishabh Kumar Goel writes: > > -- Forwarded Message -- > > > > Subject: 69030 driver > > Date: Thursday 11 Sep 2003 4:21 pm > > From: Rishabh Kumar Goel <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > > > i m trying to write a MDA driver for C&T's 69030 chip. The PCI card is > > memory mapped. starting from 0x080 with the memory size requirement > > of 16MB. > > > > How to access the Character Buffer of MDA which lies in the lower > > address map of 0xB000-0xB7FF ? > > I m able to read and write to the registers. > > > > I tried writing the a word of data(0xaa55) at 0x0800a but on reading > > it back i got 0x. > > > > What is this problem? am i reading the memory properly. > > Please help. > > > > > > -- > > Regards, > > Rishabh Kumar Goel > > Associate Software Engineer > > SoCrates Software India Pvt. Ltd. > > Bangalore > > > > --- > > > > -- > > Regards, > > Rishabh Kumar Goel > > Associate Software Engineer > > SoCrates Software India Pvt. Ltd. > > Bangalore > > > > Scanned by SecureSynergy VirusScreen Service. > > For more information log on to : http://www.securesynergyonline.com or > > http://www.securesynergy.com > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel -- Regards, Rishabh Kumar Goel Associate Software Engineer SoCrates Software India Pvt. Ltd. Bangalore Scanned by SecureSynergy VirusScreen Service. For more information log on to : http://www.securesynergyonline.com or http://www.securesynergy.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Thu, Sep 11, 2003 at 11:18:44AM -0400, John Dennis wrote:
>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
>
>David> We haven't lost module independence by doing that.
>
>Perhaps I'm misunderstanding module independence, can you confirm or
>deny some of the assumptions I've been working with:
>
>1) System specific functions are wrapped in an xf86* wrapper so that:
>
> a) system differences are isolated at a single point which provides
> a common interface to the rest of the server
>
> b) all system specific functions are wrapped and live in the
> executable XFree86. The XFree86 executable is linked against
> the system libraries and hence the XFree86 executable is not
> system independent.
b) is only necessary when required by a).
What's the difference between this in the core executable:
xf86A(pointer data)
{
return A(data);
}
SYMFUNC(xf86A)
and this:
SYMFUNCALIAS(xf86A, A)
when data is opaque to both the module and the core executable, and
interpreted only by A() in the system-provided library that the core
executable is linked against?
That the data is opaque to the module isn't true in most cases, hence the
wrapping. It's possible we wrap more functions than is strictly necessary.
>2) module independence derives from the following:
>
> a) modules only link against (e.g. import) from the XFree86
> executable that loaded it. In other words all system
> specific elements are contained in the executable, not a
> loaded module.
>
> b) The executable and modules share the same linking,
> relocation, exception, and call conventions. This makes
> a module mostly system independent, but not 100%, e.g.
> its possible, but not common, for different OS's on the same
> architecture to have a different ABI, but less common today
> as the industry is converging on standardized ABI's.
Module independence comes from providing a more uniform ABI to the
modules than you might get by linking directly with the functions provided
by the system libraries. It also comes from having a loader that can
handle different object formats.
>If I following your reasoning then you would be happy with this
>definition in xf86_libc.h
>
>/* setjmp/longjmp */
>#if defined(__ia64__)
>typedef int xf86jmp_buf[1024]; __attribute__ ((aligned (16))); /* guarantees 128-bit
>alignment! */
>#else
>typedef int xf86jmp_buf[1024];
>#endif
Yes.
>But if one is going to special case the definition of jmp_buf based on
>architecture why not use the system definition and typedef xf86jmp_buf
>to be jmp_buf? I suspect the answer will be that the system libraries
>could change requiring a different size buffer. I'd buy that if it
>weren't for the fact we are directly linking the library specfic
>version of setjmp into the module.
That it's directly linked makes no difference. The size of jmp_buf is
determined when the module is compiled. It needs to be large enough for
all the host systems it might run on, since that's where it gets used.
Taking the size of jmp_buf from the module system's headers doesn't
guarantee that.
I'll grant that what we're going with setjmp is a little hairy, but I
haven't seen anything so far that says the basic approach doesn't work
or impacts the portability of modules.
>Why a module referencing setjmp is tied to a specific system library:
>-
>
>As far as I can tell we've tied the module to a specific system
>library. Here is why I believe this. I'm going to simplify the
>discussion by assming there is only one xf86set_jmp symbol and ignore
>the type 0 and type 1 variants that select setjmp or sigsetjmp.
>
>1) a module makes a reference to xf86set_jmp.
>
>2) the xfree86 loader when it loads that module searches for that
> symbol in its hash table of symbols, that table was populated in
> part by the table in xf86sym.c which in a loadable build contains
> this definition in the main executable:
>
> #include
> SYMFUNCALIAS("xf86setjmp",setjmp)
>
>3) the above definition means when the symbol name "xf86setjmp" is
> looked up by the loader it will get the address of setjmp that was
> linked into the main executable. This is the function address that
> the xfree86 loader will insert into module during its relocation
> phase.
>
>4) How does the address of setjmp get into the main executable? It
> depends on whether the main executable was statically or
> dynamically linked, but in either case the system will assure it
> comes from a specific version of the library defined at the time
> the main executable was linked.
>
>5) Therefore when a module that referenced setjmp is called its
>
Re: setjmp needs fixing again, here's the issues
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
manner specific to the libraries the main executable is linked against.
Examples might include parameters to mmap where the base address and
size have to be adjusted for page boundaries and the mapping flags
passed. Or anything passed into an ioctl. I don't think the current set
of wrapped functions includes anything of this nature, but I thought it
was the principle behind it.
> Module independence comes from providing a more uniform ABI to the
> modules than you might get by linking directly with the functions provided
> by the system libraries.
Isn't that what I'm saying above? Xfree86 imposes its own interface
leaving the wrappers to translate when the underlying system differs.
Perhaps just as importantly since the wrappers are in the main
executable, which is the ONLY place loadable object dependencies are
enforced, its the only place you can be guaranteed that you'll be linked
to the version of shared object you're expecting!
> >If I following your reasoning then you would be happy with this
> >definition in xf86_libc.h
> Yes.
O.K. I'll make this patch and put it in the bugzilla. I'm not completely
happy with it because its not really addressing the root problem. Setjmp
may "blow up" on some other system in the future because we're ignoring
the system defined requirements. For example in the non-ia64 case
xf86jmp_buf will only be aligned on int boundaries, what if a system
needs long alignment, or some other requirement?
> I'll grant that what we're going with setjmp is a little hairy, but I
> haven't seen anything so far that says the basic approach doesn't work
> or impacts the portability of modules.
Yes, you are right setjmp is a true exception because it can't be
wrapped and thus isolate system specifics outside the module. And you're
also right its a bit hairy, it took me a while to fully understand
exactly what was going on.
As for impacting portability of modules, why isn't the following true?
libc version 1.0 requires 8 byte alignment, server XFree86 A is linked
against this library.
libc version 1.1 requires 16 byte alignment, server XFree86 B is linked
against this library.
The module in "theory" can be loaded into either XFree86 server A or B.
If the module was built against the libc 1.0 requirement it will fail
when loaded into XFree86 B. This is because unlike the system loader
which enforces the right version of the library to be loaded when
XFree86 is loaded by the system, the module loader does not deal with
version dependencies. In part because the version dependencies in theory
have been isolated in the main executable image via wrappers and
enforced by the system loader. The current setjmp implementation
violates all these assumptions which is why I conclude this negatively
impacts module portability. It is also true that if setjmp were in a
wrapper the module could be loaded into XFree86 server A or B without
issue, but thats not the case, it will crash the server if loaded in
XFree86 server B.
Granted, if we are lucky this may never bite us, there is a reasonable
chance it won't, but on the other hand to assert we haven't lost module
independence and portability is not being honest about the new situation
with modules that import xf86set_jmp.
I'm not saying I have an answer to the problem we've created for
ourselves, but I am saying we need to be honest about the impact, that
any module that imports xf86set_jmp is no longer portable, is tied the
libraries the main XFree86 is linked against, and as such we might as
well use the system definitions of jmp_buf because its the robust
solution and is no more, no less portable than inventing a jmp_buf
abstraction that inherently is not robust. So if you're not getting
portability and independence with the abstraction why sacrifice
robustness?
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
On Thu, Sep 11, 2003 at 05:24:40PM -0400, John Dennis wrote:
>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
>manner specific to the libraries the main executable is linked against.
You left out that I said "when data is opaque to both the module and
the core executable". Why?
>O.K. I'll make this patch and put it in the bugzilla. I'm not completely
>happy with it because its not really addressing the root problem. Setjmp
>may "blow up" on some other system in the future because we're ignoring
>the system defined requirements. For example in the non-ia64 case
>xf86jmp_buf will only be aligned on int boundaries, what if a system
>needs long alignment, or some other requirement?
When that happens we'll fix it. If we want to be more defensive against
such possibilities, we can try using stronger alignment on all platforms
where the compiler supports it.
>libc version 1.0 requires 8 byte alignment, server XFree86 A is linked
>against this library.
>
>libc version 1.1 requires 16 byte alignment, server XFree86 B is linked
>against this library.
>
>The module in "theory" can be loaded into either XFree86 server A or B.
>If the module was built against the libc 1.0 requirement it will fail
>when loaded into XFree86 B. This is because unlike the system loader
Yes, if the size of jmp_buf or its alignment aren't sufficient, it will
be a problem. We've been fixing the bugs in this as they are found.
We knew of the size issue, but the extra alignment issue didn't occur
to us. If it had been tested on IA64 before 4.3 we'd probably have
found the problem and fixed it then. I did specifically test the setjmp
behaviour for correctness on the platforms I have access too, but
unfortunately IA64 isn't one of them.
>which enforces the right version of the library to be loaded when
>XFree86 is loaded by the system, the module loader does not deal with
>version dependencies. In part because the version dependencies in theory
>have been isolated in the main executable image via wrappers and
>enforced by the system loader. The current setjmp implementation
>violates all these assumptions which is why I conclude this negatively
>impacts module portability. It is also true that if setjmp were in a
Bugs or limitations in our implementation impact module portability,
yes. setjmp() isn't the first place we've had a portability problem
because of a bug or limitation in an implementation. So far nobody has
given a reason why this approach must be inherently not portable, but
only correctable limitations in the implmentation that have led to
problems. That what testing is for.
>Granted, if we are lucky this may never bite us, there is a reasonable
>chance it won't, but on the other hand to assert we haven't lost module
>independence and portability is not being honest about the new situation
>with modules that import xf86set_jmp.
>
>I'm not saying I have an answer to the problem we've created for
>ourselves, but I am saying we need to be honest about the impact, that
>any module that imports xf86set_jmp is no longer portable, is tied the
>libraries the main XFree86 is linked against, and as such we might as
>well use the system definitions of jmp_buf because its the robust
>solution and is no more, no less portable than inventing a jmp_buf
>abstraction that inherently is not robust. So if you're not getting
>portability and independence with the abstraction why sacrifice
>robustness?
I obviously disagree with your take on the situation. You've found a
bug, lets fix it, test it as widely as possible, and move on. The
"portability" issues you're raising here are hypothetical rather than
real reported cases. The problem you found was on IA64. That wasn't
specifically a module portability issue. It was the fact that our
setjmp is currently plain broken on IA64.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Thu, Sep 11, 2003 at 11:11:47AM -0400, Jim Gettys wrote: > An audio server need not be designed to add latency (beyond > that of the network itself, of course). With current networks, > this is very small, down to a few samples. Well, no of course it doesn't need to be designed to add latency - that just happens! It does, however, need to be designed to minimize latency and provide synchronous execution. I would think that normal networks just have too much variance in their round-trip times to satisfy jackd's strict timing requirements. If a jack client ever looses synchronization, jackd kills it's connection immediately. This can occasionally happen on my box if I'm recording and hit a few millisecond load spike. I can imagine a hack for jackd that relaxes the synchronization and timing requirements, but if it hurts the realtime users at all, it'll never even be considered. I think something like esd should be fine for standard user audio apps over a network. Ross ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
