[Dri-devel] DRM reset code
This drop fixes a few issues in the reset code. Please ignore the previous version, it has a bug on some cards that can disable them on startup. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html patch3.bz2 Description: patch3.bz2
Re: [Dri-devel] code for supporting reset from DRM
Jon Smirl wrote: --- Michel Dänzer [EMAIL PROTECTED] wrote: As Alan pointed out on IRC, it won't. But providing the means to do it I'm using code extracted from the reset function in Xfree. It seems to work for Xfree, why shouldn't it work for me? cleanly is certainly good basically. The question is exactly where it belongs. I suggested to do this work on a branch for the time being, and got zero feedback. I don't know what that's supposed to mean; some people take silence as approval, but I don't. I have six months worth of code that I can't check in because it all relies on a sequence of patches. I have so many patches I am getting confused and losing code. I'm doing this work for fun, I'm not getting paid, and lately it hasn't been too much fun. If changes to DRM are going to be blocked please tell me now and I will go work on another project. My problem with your changes is that I really don't know how to evaluate them. Secondly, there seem to be people who know what they're talking about who have real objections to some of them. Perhaps you need to go back to your sequence of patches and identify those that can be merged individually as incremental improvements to the existing drm module, or perhaps even to new modules, and that are relatively uncontroversial. In general, I don't think that saying 'this is what MS is doing, hence we need to somehow compete' is going to swing people who care about the kernel its structure. You need to express your desired changes in terms of what technical problems are being solved and also accept that there might be other ways to address those problems. I'm sure you're capable of doing this, but you need to understand that you may have looked very closely at some particular problem others are maybe a step or two behind you - and may not even recognize something as a problem at this point. There have been a lot of changes proposed some real objections to some of them - I'd like to see those resolved somehow. I'd also like to avoid what looks like a small issue of approach or style end up driving an active developer to some different project. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Volunteer for GATOS/DRI/Kernel 2.6 Merge
Hello everyone, I am offically throwing in my hat to volunteer for testing and code merging for the gatos/dri/linux kernel 2.6 effort that I have seen as I lurk through the DRI and GATOS mailing lists. My current config: Debian Testing (sarge) Xfree 4.3.0 configuration Using: Kernel 2.6.5 at the moment with 2.4.25 as an option to boot Hardware: Dual Athlon 2400+ CPU's on a Tyan S2466-4M board with ATI Radeon All in Wonder card. This is the 7200 series AGP R100 theatre chipset. I have been successfully using the 2.4.25 with drm 1.100. Now that I have upgraded to 2.6.5, obviously, the DRI portion doesn't work. I have patched the gatos CVS version with debian updates and am running with KM without the DRM support. I have seen multiple emails from Hod McWuff stating he's working on a merge and I would like to help and test. Please email me directly at: [EMAIL PROTECTED] (Take out the _NOSPAM_) __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
On Thu, 2004-04-15 at 04:50, Jon Smirl wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: As Alan pointed out on IRC, it won't. But providing the means to do it I'm using code extracted from the reset function in Xfree. It seems to work for Xfree, why shouldn't it work for me? Where did I say it didn't work? XFree86 supports many more OSs than the DRM. cleanly is certainly good basically. The question is exactly where it belongs. I suggested to do this work on a branch for the time being, and got zero feedback. I don't know what that's supposed to mean; some people take silence as approval, but I don't. I have six months worth of code that I can't check in because it all relies on a sequence of patches. I have so many patches I am getting confused and losing code. I'm doing this work for fun, I'm not getting paid, and lately it hasn't been too much fun. If changes to DRM are going to be blocked please tell me now and I will go work on another project. Just do it on a branch? It is obvious to me that the Longhorn desktop will be a generation ahead of anything that Linux has to offer. A key MS decision was to build on top of DirectX. The parallel on Linux is to bring up a standalone OpenGL/Mesa and then implement xserver on top. If Linux is going to have a competitve offering then we need to get standalone mesa working immediately in order to give the xserver and higher layer people time to code. Surely this could be prototyped with something like Mesa solo, or with your work on a branch? In the long run FB and DRM need to be merged into a single driver. Cooperative multitasking of multiple device drivers on the same piece of hardware is a bad design and it has happened for historical reasons. DRM was designed from the beginning to handle multiple clients, DMA security, framebuffer memory management, etc. It is much easier to pull FB functions into DRM than the other way around. Easier maybe, but I don't think that the easiest solution is necessarily the best one. Linus has proposed a way for the two to cooperate using a common low-level driver. As Dave, I feel that this stuff would rather belong in that low-level driver than the DRM. FB was built for a single user using a dumb 2D framebuffer. Leave it that way. DRM is designed for a much more complex environment. I thought the DRM was designed to provide means to achieve direct _rendering_, not mode setting, card resetting, ..., but maybe that's just me. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
I had a good fix for this in one of my patches. Only BSD needs the names but both need the IDs and linux even had a hotplug struct. This was geard and enginered with both OSes being treated as eaquils and other OSes made easy to acommidate. What I did was had some macroes that took paramiters and filled ought the struct depending on what OS the macro came from. I put this all in radeon.h inside a ifdeine PCIID_STRUCT that only got deffined in the radeon.c right b4 the include. Thought this info dose not have to live in the headers I thouht it just looked nicer that way. what I'd like is a way to just put the strings into the BSD driver, but also so that the strings wouldn't have to be merged up to the kernel at all, maybe a patch with the strings in it might be accepted if they aren't built into the binary but I'd rather they never went near the kernel, I'm trying to think of someway to do it with macros... I don't really want to have to add the pci ids to two places, perhaps we could use an external script to take a list of pci ids from a file and create a suitable .h for Linux and BSD in the build system, then we can merge the Linux ones up to the kernel Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
My problem with your changes is that I really don't know how to evaluate them. Secondly, there seem to be people who know what they're talking about who have real objections to some of them. I think Keith has put it the best, most of my concerns about this work are that it is maybe before its time :-) Why I'm against it on the trunk: 1. Probably not acceptable as is into the Linux kernel or BSD, which raises the question as to why it would go into the main drm trunk at this time. 2. once Linus merges (I'm aiming for 2.6.7) there'll be some patches pushing back the other direction and I'd like to at that stage tag the 2.6 DRM, and I don't want to have stuff in the way ... (I'm self-appointed DRM maintainer at the moment and I'm blocking all patches that don't help towards the Linux merge from going into the DRM trunk, branches are not my domain..) Your work is trailblazing work, and at the moment it belongs in a branch, and also maybe upload all your patches to a public_html on fd.o so we can all take a look, the major issue with trailblazing is no-one else is with you to nitpick and input ideas and when you do release, everyone nitpicks and inputs ideas :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] solo vs X/DRI glitches in rendering..
On Wed, 2004-04-14 at 06:45, Dave Airlie wrote: Hi, I've a Radeon M7 running at 800x600-32bit, and have built solo and X/DRI drivers out of the same tree, when I run the manytex (one from miniglx and other from tests) under X/DRI the screen is rock solid and manytex runs, however under solo, I get some odd flicker across the top 60 lines of my screen (perhaps the first 64 lines, half a box in manytex)... I get the same running my own application, it happens at 1x and 4x AGP, Has disabling page flipping fixed it? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
I've been down the branch path before. I have many thousands of lines of changes. If I do all of them on a branch sometime in the future people might decide to merge them. When that happens everyone will say there is too much code and it is too complex to understand, break it up into small patches again. Then I'll have to spend three months breaking things back into chunks. These will then get nit picked to death and each one will take a month to get into the trunk. A year from now I might have the functions merged. To avoid merge issues I will have to continuously monitor the trunk and track each check in there and apply it by hand to the branch. Next is the whole can of worms over FB vs DRM vs a third base driver. Of course this will take a year or more to sort out if ever gets changed. There will be months of arguments over where mode setting and memory management should go. Sooner or latter I would hope that people will see the insanity of having multiple device drivers trying to control the same piece of hardware. My objective is not to build the perfect FB/DRM device driver. So I'm going to take simpler route and zip up my DRM changes and save them somewhere. I can extract the code from Xfree for doing everything I need from user space and I can add this code into the mesa linux-solo project without a lot of hassle. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Thu, 2004-04-15 at 17:13, Alex Deucher wrote: Speaking of merging, what are everyone's thoughts on merging the DDX trees (drivers at least, I don't know about the rest, especially with the licensing)? I was thinking mostly DRI-xfree86 but I suppose we could look at gatos too. Specifically the radeon driver has some new fixes in the xfree86 tree and there is MergedFB and IGP 3D support in the DRI tree. Does the XFree86 tree have anything important the X.Org tree doesn't? If not, I'd prefer going with the latter. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
On Thu, 2004-04-15 at 17:44, Jon Smirl wrote: I've been down the branch path before. I have many thousands of lines of changes. If I do all of them on a branch sometime in the future people might decide to merge them. When that happens everyone will say there is too much code and it is too complex to understand, break it up into small patches again. Then I'll have to spend three months breaking things back into chunks. These will then get nit picked to death and each one will take a month to get into the trunk. A year from now I might have the functions merged. To avoid merge issues I will have to continuously monitor the trunk and track each check in there and apply it by hand to the branch. That's not how branches have been handled in the DRI project. You may want to read the DRI CVS policies. Sounds to me like a strawman argument for piecemeal setting-in-stone of controversial changes. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2004-04-15 at 17:13, Alex Deucher wrote: Speaking of merging, what are everyone's thoughts on merging the DDX trees (drivers at least, I don't know about the rest, especially with the licensing)? I was thinking mostly DRI-xfree86 but I suppose we could look at gatos too. Specifically the radeon driver has some new fixes in the xfree86 tree and there is MergedFB and IGP 3D support in the DRI tree. Does the XFree86 tree have anything important the X.Org tree doesn't? If not, I'd prefer going with the latter. I'd prefer XORG as well. I haven't checked to see the current state of the XORG radeon driver. I think the only thing that may be missing is Hui's last patch to turn off the DACs on DPMS events. Alex -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Splitting binary snapshots
Hi,
Here are my plans to split the binary snapshot into a device-specific
and a common (device-independent) part. This was discussed briefly on
the last IRC meeting. I attached a patch to the snapshot scripts. ATM
it's only to illustrate the idea, it is completely untested.
After Ian's driinterface changes it turned out that libGLcore.a and
libglx.a need to be included in the snapshots. libGL and the core
modules don't need to be updated as frequently as the DDX, DRI and DRM
drivers since they are not directly related to direct hardware access,
rendering performance or the visual quality. Therefore they are going to
be in a separate snapshot. This keeps the size of the device-specific
snapshots reasonably small while more stuff can be included in the
device-independent part for people who want to test newer infrastructure
and eventually indirect accelerated rendering. First-time users should
install both snapshots.
How it works:
I added a new Meta-driver to the dripkg.sh script called COMMON. If
the driver name is COMMON then dripkg.sh would package only libGL and
the XFree86 core modules. Otherwise it packs only the DDX and DRI
modules and the DRM sources. The install script detects which
subdirectories are present in the snapshot and uses that to determine
what is supposed to be installed/restored. This way it would be easy to
change the way the snapshots are split without having to update two
install scripts.
The only thing I'm not quite sure about is where the drm sources should
go. I suppose there are good arguments for it to be included in either
snapshot. It should however be in only one of them so that a user who
installs both snapshots doesn't install the DRM twice.
Comments?
Regards,
Felix
? install.sh.diff
? newdrm.diff
? snapshot-split.diff
? test
Index: dripkg.sh
===
RCS file: /cvs/dri/snapshots/dripkg.sh,v
retrieving revision 1.7
diff -u -r1.7 dripkg.sh
--- a/dripkg.sh 9 Apr 2004 16:34:39 - 1.7
+++ b/dripkg.sh 15 Apr 2004 16:14:50 -
@@ -43,7 +43,8 @@
# Package Variables
PKG_DIR=dripkg
-PKG_FULL=${FULL:-0}
+#PKG_FULL=${FULL:-0}
+PKG_FULL=1
# Variables for selected driver
@@ -174,6 +175,16 @@
SAVAGE_DRM=savage
SAVAGE_COMMAND=
+# COMMON Meta-Driver Variables
+COMMON_NAME=common
+COMMON_DESC=Libraries and modules common to all DRI drivers
+COMMON_DDX_SUBDIR=
+COMMON_DDX=
+COMMON_DRI_SUBDIR=
+COMMON_DRI=
+COMMON_DRM=
+COMMON_COMMAND=
+
# Utility functions
VERBOSE=1
@@ -220,66 +231,68 @@
vecho Creating $DRV_NAME package...
-# Copy driver sources
-vecho Copying 2D/3D driver modules...
-mkdir -p $PKG_DRV_DIR
-for DDX in $DRV_DDX
-do
- cp $DRV_DDX_DIR/$DDX_drv.o $PKG_DRV_DIR
- strip -g $PKG_DRV_DIR/$DDX_drv.o
-done
-cp $DRV_DRI_DIR/$DRV_DRI_dri.so $PKG_DRV_DIR
-#strip -g $PKG_DRV_DIR/$DRV_DRI_dri.so
-
-# Copy DRM sources
-vecho Copying DRM kernel module sources...
-mkdir -p $PKG_DRM_DIR
-case `uname -s` in
- Linux)
- cp -r $DRM_CVS_DIR/linux/* $PKG_DRM_DIR
- ;;
- *BSD)
- cp -r $DRM_CVS_DIR/bsd/* $PKG_DRM_DIR
- ;;
- *)
- echo Unknown system `uname -s`
- exit 127
- ;;
-esac
-# HACK: invert order to cope with redundant files in the linux drm dir...
-if [ -e $DRM_CVS_DIR/shared ]
-then
- cp -r $DRM_CVS_DIR/shared/* $PKG_DRM_DIR
-fi
-rm -rf $PKG_DRM_DIR/CVS
-
-# Copy GL library
-vecho Copying GL library...
-mkdir -p $PKG_GL_DIR
-#if [ $PKG_FULL -ne 0 ]
-#then
- cp $DRV_LIB_DIR/GL/GL/libGL.so.1.2 $PKG_GL_DIR strip -g
$PKG_GL_DIR/libGL.so.1.2
- if [ -r $DRV_LIB_DIR/GLU/libGLU.so.1.3 ]; then
- # libGLU.so* was built by DRI CVS a long time ago. s3virge still
- # includes it. Don't know if it's really needed.
- cp $DRV_LIB_DIR/GLU/libGLU.so.1.3 $PKG_GL_DIR strip -g
$PKG_GL_DIR/libGLU.so.1.3
+if [ $DRV_NAME != common ]; then
+ # Copy driver sources
+ vecho Copying 2D/3D driver modules...
+ mkdir -p $PKG_DRV_DIR
+ for DDX in $DRV_DDX
+ do
+ cp $DRV_DDX_DIR/$DDX_drv.o $PKG_DRV_DIR
+ strip -g $PKG_DRV_DIR/$DDX_drv.o
+ done
+ cp $DRV_DRI_DIR/$DRV_DRI_dri.so $PKG_DRV_DIR
+ #strip -g $PKG_DRV_DIR/$DRV_DRI_dri.so
+
+ # Copy DRM sources
+ vecho Copying DRM kernel module sources...
+ mkdir -p $PKG_DRM_DIR
+ case `uname -s` in
+ Linux)
+ cp -r $DRM_CVS_DIR/linux/* $PKG_DRM_DIR
+ ;;
+ *BSD)
+ cp -r $DRM_CVS_DIR/bsd/* $PKG_DRM_DIR
+ ;;
+ *)
+ echo Unknown system `uname -s`
+ exit 127
+ ;;
+ esac
+ # HACK: invert order to cope with redundant files in the linux drm dir...
+ if [ -e $DRM_CVS_DIR/shared ]
+ then
+
Re: [Dri-devel] Splitting binary snapshots
Felix Kühling wrote: I added a new Meta-driver to the dripkg.sh script called COMMON. If the driver name is COMMON then dripkg.sh would package only libGL and the XFree86 core modules. Otherwise it packs only the DDX and DRI modules and the DRM sources. The install script detects which subdirectories are present in the snapshot and uses that to determine what is supposed to be installed/restored. This way it would be easy to change the way the snapshots are split without having to update two install scripts. That sounds like a good strategy. The only thing I'm not quite sure about is where the drm sources should go. I suppose there are good arguments for it to be included in either snapshot. It should however be in only one of them so that a user who installs both snapshots doesn't install the DRM twice. I think they should go in the device-specific part. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
Do you mean something like... sed 's/0x111, 0x/0x111, 0x, The dev name/' You could do this in place or on a radeon-ids.h. I'm sure it would be better ro use an awk script to prune the info from radeon.h and just have it distributed by default. My vote is to have it bloat the kernel source, just not used. --- Dave Airlie [EMAIL PROTECTED] wrote: I had a good fix for this in one of my patches. Only BSD needs the names but both need the IDs and linux even had a hotplug struct. This was geard and enginered with both OSes being treated as eaquils and other OSes made easy to acommidate. What I did was had some macroes that took paramiters and filled ought the struct depending on what OS the macro came from. I put this all in radeon.h inside a ifdeine PCIID_STRUCT that only got deffined in the radeon.c right b4 the include. Thought this info dose not have to live in the headers I thouht it just looked nicer that way. what I'd like is a way to just put the strings into the BSD driver, but also so that the strings wouldn't have to be merged up to the kernel at all, maybe a patch with the strings in it might be accepted if they aren't built into the binary but I'd rather they never went near the kernel, I'm trying to think of someway to do it with macros... I don't really want to have to add the pci ids to two places, perhaps we could use an external script to take a list of pci ids from a file and create a suitable .h for Linux and BSD in the build system, then we can merge the Linux ones up to the kernel Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
And don't forget that pci.ids and the code that uses it could be portet to BSD as part of the DRM. --- Mike Mestnik [EMAIL PROTECTED] wrote: Do you mean something like... sed 's/0x111, 0x/0x111, 0x, The dev name/' You could do this in place or on a radeon-ids.h. I'm sure it would be better ro use an awk script to prune the info from radeon.h and just have it distributed by default. My vote is to have it bloat the kernel source, just not used. --- Dave Airlie [EMAIL PROTECTED] wrote: I had a good fix for this in one of my patches. Only BSD needs the names but both need the IDs and linux even had a hotplug struct. This was geard and enginered with both OSes being treated as eaquils and other OSes made easy to acommidate. What I did was had some macroes that took paramiters and filled ought the struct depending on what OS the macro came from. I put this all in radeon.h inside a ifdeine PCIID_STRUCT that only got deffined in the radeon.c right b4 the include. Thought this info dose not have to live in the headers I thouht it just looked nicer that way. what I'd like is a way to just put the strings into the BSD driver, but also so that the strings wouldn't have to be merged up to the kernel at all, maybe a patch with the strings in it might be accepted if they aren't built into the binary but I'd rather they never went near the kernel, I'm trying to think of someway to do it with macros... I don't really want to have to add the pci ids to two places, perhaps we could use an external script to take a list of pci ids from a file and create a suitable .h for Linux and BSD in the build system, then we can merge the Linux ones up to the kernel Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Finally looking at the DRI SMP issues
I finally have access to an x86 SMP box, and I have a few cycles to look at the SMP related problems. I'm using an AGP G400 and quake3-smp. Like Dieter, I get a black screen and a hung program. When I break in with GDB, here is the stack trace. Dieter, does this match what you see? 0x00162c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0x00162c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0040d7bb in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x6a49 in ?? () #3 0x003baa24 in ?? () from /usr/X11R6/lib/libX11.so.6 #4 0x0892d078 in ?? () #5 0x0040a976 in _L_mutex_lock_26 () from /lib/tls/libpthread.so.0 #6 0x0892c8b8 in ?? () #7 0xb6c8 in ?? () #8 0x0032e8aa in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6 Previous frame identical to this frame (corrupt stack?) This is on a Fedora Core 1 system with today's DRI / Mesa CVS. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
This is a diff for drivers/char/drm to make r128 use userland-loadable
firmware. It's completely untested (since I don't *have* an r128, I don't
see any way to test it), but I bet it'll work; the firmware loading interface
seems remarkably easy to use.
Following that (in the form of a diff) is the short program I used to create
a microcode file which could be shipped as the file
/usr/lib/hotplug/r128_cce_microcode
(I left it in this form to avoid problems with attaching binaries.)
Similar (nearly identical) changes could be made to the radeon driver in
the same directory, and I'll be happy to make them if needed.
This could probably be improved by someone with a better sense of
the right way to deal with the stupid endianness issues; I went with the
simplistic pick an endianness choice.
Please do tell me if there's a major problem with this that I can fix. The one
which worries me the most is the possibility that the firmware loading is
not done in user context, or that it's done when holding a lock which means
that it mustn't sleep. (Request_firmware obviously sleeps, since it calls
into userland.) After spending something like 6 hours trawling
through the code backwards and forwards, I decided it *probably* wasn't,
but I wasn't sure.
There's also a faint possibility of deadlock if the userland process which
is supposed to load the firmware waits for the DRM module in order to use
the screen; this shouldn't happen because it's a background daemon (hotplug),
and the standard script only calls cat [file] sysfs/[phony file].
If either of these is a problem, the firmware may have to be loaded
and cached in memory at module load time in the module load routine, and only
disposed of at module unload. I couldn't actually find those routines, which
is one reason I didn't do that. ;-) The other is that it seems like it's a
waste of memory to do anything other than retrieving it when it's needed and
disposing of it afterwards.
Of course, given my lack of DRM experience, there could be any number of
other gotchas. :-P
My changes are GPL licensed (of course).
(Incidentally, what *is* this microcode? It looks like it's actually
two separate sets of code interleaved.)
Please email me with comments/requests, as I'm not subscribed.
--- r128_cce.c 2003-09-28 00:44:12.0 -0400
+++ r128_cce.c.new 2004-04-12 19:32:39.0 -0400
@@ -3,6 +3,7 @@
*
* Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
* Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Portions copyright 2003 Nathanael Nerode.
* All Rights Reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
@@ -28,6 +29,7 @@
*Gareth Hughes [EMAIL PROTECTED]
*/
+#include linux/firmware.h
#include r128.h
#include drmP.h
#include drm.h
@@ -36,51 +38,6 @@
#define R128_FIFO_DEBUG0
-/* CCE microcode (from ATI) */
-static u32 r128_cce_microcode[] = {
- 0, 276838400, 0, 268449792, 2, 142, 2, 145, 0, 1076765731, 0,
- 1617039951, 0, 774592877, 0, 1987540286, 0, 2307490946U, 0,
- 599558925, 0, 589505315, 0, 596487092, 0, 589505315, 1,
- 11544576, 1, 206848, 1, 311296, 1, 198656, 2, 912273422, 11,
- 262144, 0, 0, 1, 33559837, 1, 7438, 1, 14809, 1, 6615, 12, 28,
- 1, 6614, 12, 28, 2, 23, 11, 18874368, 0, 16790922, 1, 409600, 9,
- 30, 1, 147854772, 16, 420483072, 3, 8192, 0, 10240, 1, 198656,
- 1, 15630, 1, 51200, 10, 34858, 9, 42, 1, 33559823, 2, 10276, 1,
- 15717, 1, 15718, 2, 43, 1, 15936948, 1, 570480831, 1, 14715071,
- 12, 322123831, 1, 33953125, 12, 55, 1, 33559908, 1, 15718, 2,
- 46, 4, 2099258, 1, 526336, 1, 442623, 4, 4194365, 1, 509952, 1,
- 459007, 3, 0, 12, 92, 2, 46, 12, 176, 1, 15734, 1, 206848, 1,
- 18432, 1, 133120, 1, 100670734, 1, 149504, 1, 165888, 1,
- 15975928, 1, 1048576, 6, 3145806, 1, 15715, 16, 2150645232U, 2,
- 268449859, 2, 10307, 12, 176, 1, 15734, 1, 15735, 1, 15630, 1,
- 15631, 1, 5253120, 6, 3145810, 16, 2150645232U, 1, 15864, 2, 82,
- 1, 343310, 1, 1064207, 2, 3145813, 1, 15728, 1, 7817, 1, 15729,
- 3, 15730, 12, 92, 2, 98, 1, 16168, 1, 16167, 1, 16002, 1, 16008,
- 1, 15974, 1, 15975, 1, 15990, 1, 15976, 1, 15977, 1, 15980, 0,
- 15981, 1, 10240, 1, 5253120, 1, 15720, 1, 198656, 6, 110, 1,
- 180224, 1, 103824738, 2, 112, 2, 3145839, 0, 536885440, 1,
- 114880, 14, 125, 12, 206975, 1, 33559995, 12, 198784, 0,
- 33570236, 1, 15803, 0, 15804, 3, 294912, 1, 294912, 3, 442370,
- 1, 11544576, 0, 811612160, 1, 12593152, 1, 11536384, 1,
- 14024704, 7, 310382726, 0, 10240, 1, 14796, 1, 14797, 1, 14793,
- 1, 14794, 0, 14795, 1, 268679168, 1, 9437184, 1, 268449792, 1,
- 198656, 1, 9452827, 1, 1075854602, 1, 1075854603, 1, 557056, 1,
- 114880, 14, 159, 12, 198784, 1, 1109409213, 12, 198783, 1,
- 1107312059, 12, 198784, 1, 1109409212, 2, 162, 1, 1075854781, 1,
-
[Dri-devel] Re: Finally looking at the DRI SMP issues
Ian Romanick wrote:
I finally have access to an x86 SMP box, and I have a few cycles to look
at the SMP related problems. I'm using an AGP G400 and quake3-smp. Like
Dieter, I get a black screen and a hung program. When I break in with
GDB, here is the stack trace. Dieter, does this match what you see?
That problem appears to have been a simple deadlock. The LockDisplay /
UnlockDisplay calls were not balanced in various paths through
MakeContextCurrent. The attached patch fixes that problem. I still hit
other problems on MGA, but they *appear* to be MGA specific.
Dieter: Could you try this patch on R200 and let me know if it helps.
I'll keep working on the other issues.
? lib/GL/glx/Doxyfile
? lib/GL/glx/foo
Index: lib/GL/glx/glxext.c
===
RCS file: /cvs/dri/xc/xc/lib/GL/glx/glxext.c,v
retrieving revision 1.41
diff -u -d -r1.41 glxext.c
--- a/lib/GL/glx/glxext.c 14 Apr 2004 01:28:45 - 1.41
+++ b/lib/GL/glx/glxext.c 15 Apr 2004 21:43:31 -
@@ -1406,17 +1406,25 @@
GLXContextID gc, GLXContextTag old_gc, GLXDrawable draw, GLXDrawable read,
xGLXMakeCurrentReply * reply );
+/**
+ * Sends a GLX protocol message to the specified display to make the context
+ * and the drawables current.
+ *
+ * \param dpy Display to send the message to.
+ * \param opcode Major opcode value for the display.
+ * \param gc_id Context tag for the context to be made current.
+ * \param drawDrawable ID for the draw drawable.
+ * \param readDrawable ID for the read drawable.
+ * \param reply Space to store the X-server's reply.
+ *
+ * \warning
+ * This function assumes that \c dpy is locked with \c LockDisplay on entry.
+ */
static Bool SendMakeCurrentRequest( Display *dpy, CARD8 opcode,
GLXContextID gc_id, GLXContextTag gc_tag,
GLXDrawable draw, GLXDrawable read,
xGLXMakeCurrentReply * reply )
{
-opcode = __glXSetupForCommand(dpy);
-if (!opcode) {
- return GL_FALSE;
-}
-
-LockDisplay(dpy);
if ( draw == read ) {
xGLXMakeCurrentReq *req;
@@ -1541,11 +1549,12 @@
** unbind the previous context.
*/
sentRequestToOldDpy = True;
+LockDisplay(oldGC-currentDpy);
if ( ! SendMakeCurrentRequest( oldGC-currentDpy, oldOpcode, None,
oldGC-currentContextTag, None, None,
reply ) ) {
/* The make current failed. Just return GL_FALSE. */
- UnlockDisplay(dpy);
+ UnlockDisplay(oldGC-currentDpy);
SyncHandle();
return GL_FALSE;
}
@@ -1580,6 +1589,7 @@
gc ? gc-xid : None,
oldGC-currentContextTag,
draw, read, reply );
+ UnlockDisplay(dpy);
#ifdef GLX_DIRECT_RENDERING
}
#endif
@@ -1622,7 +1632,7 @@
oldGC-xid, 0,
oldGC-currentDrawable,
oldGC-currentReadable, reply ) ) {
- UnlockDisplay(dpy);
+ UnlockDisplay(oldGC-currentDpy);
SyncHandle();
/*
** The request failed; this cannot happen with the
@@ -1634,7 +1644,7 @@
*/
}
else {
- UnlockDisplay(dpy);
+ UnlockDisplay(oldGC-currentDpy);
}
oldGC-currentContextTag = reply.contextTag;
}
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. It's completely untested (since I don't *have* an r128, I don't see any way to test it), but I bet it'll work; the firmware loading interface seems remarkably easy to use. Following that (in the form of a diff) is the short program I used to create a microcode file which could be shipped as the file /usr/lib/hotplug/r128_cce_microcode (I left it in this form to avoid problems with attaching binaries.) Similar (nearly identical) changes could be made to the radeon driver in the same directory, and I'll be happy to make them if needed. This could probably be improved by someone with a better sense of the right way to deal with the stupid endianness issues; I went with the simplistic pick an endianness choice. Please do tell me if there's a major problem with this that I can fix. The one which worries me the most is the possibility that the firmware loading is not done in user context, or that it's done when holding a lock which means that it mustn't sleep. (Request_firmware obviously sleeps, since it calls into userland.) After spending something like 6 hours trawling through the code backwards and forwards, I decided it *probably* wasn't, but I wasn't sure. There's also a faint possibility of deadlock if the userland process which is supposed to load the firmware waits for the DRM module in order to use the screen; this shouldn't happen because it's a background daemon (hotplug), and the standard script only calls cat [file] sysfs/[phony file]. If either of these is a problem, the firmware may have to be loaded and cached in memory at module load time in the module load routine, and only disposed of at module unload. I couldn't actually find those routines, which is one reason I didn't do that. ;-) The other is that it seems like it's a waste of memory to do anything other than retrieving it when it's needed and disposing of it afterwards. Of course, given my lack of DRM experience, there could be any number of other gotchas. :-P My changes are GPL licensed (of course). The r128 module is BSD licensed (though I thought it was supposed to be dual BSD/GPL) - are you willing to reconsider? If not it will be hard to integrate your changes, regardless of their technical merit. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Thu, 15 Apr 2004, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. It's completely untested (since I don't *have* an r128, I don't see any way to test it), but I bet it'll work; the firmware loading interface seems remarkably easy to use. how does this work when the r128 driver is built into the kernel? if no root exists will it fail? these microcode updates are provided by ATI to fix issues with 3D operations in the original microcodes (or at least thats how I understand them :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ Anyway, I'll offer some technical comments. It's completely untested (since I don't *have* an r128, I don't see any way to test it), but I bet it'll work; the firmware loading interface seems remarkably easy to use. Its return code should probably be checked and propagated though? The DRM doesn't work without the microcode. Does this work with 2.4 kernels? This patch puts Linux specific code in a file that is shared with the BSDs. This could probably be improved by someone with a better sense of the right way to deal with the stupid endianness issues; I went with the simplistic pick an endianness choice. That's the only sane way. Linux provides convenience macros like be32_to_cpu(); not sure about the BSDs; their DRM code seems to define le32_to_cpu() for Linux compatibility, so little endian might be the easier choice. Please do tell me if there's a major problem with this that I can fix. The one which worries me the most is the possibility that the firmware loading is not done in user context, or that it's done when holding a lock which means that it mustn't sleep. (Request_firmware obviously sleeps, since it calls into userland.) The hardware lock is probably held when the ioctl is called, but I don't think that's a problem. It's only called by the X server (or its equivalent) during initialisation. (Incidentally, what *is* this microcode? It looks like it's actually two separate sets of code interleaved.) My understanding is that it contains instructions for the so-called Concurrent Command Engine (CCE) how to translate command packets into register values. This forms the basis of how the DRM emits commands to the hardware. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] code for supporting reset from DRM
--- Dave Airlie [EMAIL PROTECTED] wrote: I can extract the code from Xfree for doing everything I need from user space and I can add this code into the mesa linux-solo project without a lot of hassle. Are you going to get solo so it doesn't require an fb device? if so that is defintely something I for one would like to see.. solo has made my life a hell of a lot easier :-) That's my plan, a solo that runs without fb. I originally started out using the fb driver, but it became more pain than it was worth. When X runs it just ignores the fb driver and makes sure to not stomp it's memory. That's a lot different than calling into the driver and leaving it active. A root problem is memory management. So for the next attempt I tried pulling various pieces of code out of fb and integrating them into DRM. This failed too because the fb code is not implementing a lot of features that X exposes. I started fixing things but I decided it was too much trouble. My current code takes the X free version of things and moves it into the DRM driver. I have this more or less working but I still need to do some more debug on it. The main features I need to add to the driver are reset, multi-head mode support, merged fb support. The heads need to support moving the display buffer around in memory. None of these features exist in fb. Mode setting implies that I have to be able to read the DDC data from both heads to build the mode database. Again I tried lifting the mode code out of FB. I discovered that it takes about 100K of code to handle DDC. The FB code is also missing things X needs so I'm in the middle of pulling out the FB code and switching to the Xfree version. I'm also kicking all of this code into user space since it has no real need to be in kernel space. With those capabilities in DRM I can work on other mesa solo problems like fixing pbuffer support. For example I know the Radeon DRM driver is broken for running pbuffers. Once I get the things outlined above working 100% I'm going to stop making changes to DRM. When the above work is complete it is a simple matter to pull the remaining pieces of fb implementing console support into the DRM driver and have a complete replacement. But doing this gives everyone a heart attack so I'm not going to do it. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
