Brian Paul wrote:
Michel Dänzer wrote:

On Mon, 2002-11-25 at 23:21, Brian Paul wrote:

There are two places in radeon_ioctl.c where the INREG() macro is used to
read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).

It looks like these have been superceeded by drmCommandWriteRead() calls
(since the 11 July check-in of Tim Smith's changes). INREG is probably
only used if the kernel module is too old to support the RADEON_LAST_-
CLEAR/FRAME queries.

It would be nice if those two instances of INREG() could be removed.

I suppose we need to keep them for the sake of users of older radeon.o
kernel modules. Is there more to it than that?


I don't see any other reason, the registers are only read directly if
there's a problem with the ioctl. I know Eric used to frown at the idea
of using an ioctl to get a register value though. :)

This is (apparently) the only place in the whole driver where we directly
access a hardware register.  It's the only reason we need to drag in
the (new) radeon_macros.h file, which in turn pulls in a number of other
server-side XFree86 headers.  It would be nice to eliminate that.
The only way you can eliminate it is if you opt to forgo client-side throttling on old kernel modules.

At the moment the radeon driver is broken with old kernel modules anyway, but that should be fixed presently.

In the r200 driver we print an error and exit if the drmCommandWriteRead()
fails.  I think that should never happen if the kernel module is new enough
to support the query.  I don't know the radeon.o version number which
corresponded to the introduction of the RADEON_LAST_CLEAR/FRAME query.
The query was added *before* r200 support was added to the kernel, so there's never a case where an r200 can be running with a kernel module that doesn't support the query.

Keith



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to