Re: ATI Radeon XPRESS 200M
On 10/22/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
> Thanks for answering my questions. Sorry I'm a little slow to respond.
> I can usually only work on this when everyone in the house is asleep. (That
> doesn't come that often..)
>
>
> > You'd probably want to configure the MC in the DDX (xf86-video-ati)
> > although you may have to coordinate with the drm if things like the
> > memory maps change. You shouldn't need to mess with the 3D driver
> > (mesa). The DDX sets up the card, sets modes and handles 2D accel and
> > overlays. The drm provides secure access to the card in the kernel
> > for things like DMA and command submission. The 3D mesa driver
> > translates OpenGL to card specific commands and then feeds the
> > commands to the drm.
>
> I greped through a copy of xf86-video-ati that I checked out of git. It
> seems that R300_MC_IND_INDEX is only manipulated in RADEONInitDispBandwidth.
> Are there some other places I am missing?
The radeon driver doesn't really mess with the memory controller
registers. It relies on the bios/chip defaults. I'm not even sure
messing with the MC stuff on the XPRESS chips will help. We're just
guessing here.
>
> (Or is there something else I should be looking for?)
> >
> > I shouldn't be too hard to add support for the indirect MC regs to
> > radeontool or another dumper. The indirect MC regs are accessed via
> > the MC index reg at MMIO offset 0x01F8 and the MC data reg at MMIO
> > offset 0x01FC. You specify the MC reg you want in the MC index reg
> > and then you can read/write to that reg via the MC data reg. bits 5:0
> > of the MC index reg specify the MC reg. bit 8 is the write enable
> > bit. You should be able to use the INPLL/OUTPLL code in the radeon
> > DDX as a model. the only difference is the PLL write enable bit is 7
> > rather than 8. The PCIE regs are indexed as well IIRC, but once
> > again, I'm not too familiar with them.
>
> Alright, so I took the radeontool and tried to make this happen.
>
> First the interesting things:
>
> fglrx (8.24.8)
> --
> RADEON_MC_AGP_LOCATION=5bff5800
> RADEON_MC_FB_LOCATION=57ff4800
> RADEON_MC_STATUS=00080001
> R300_MC_INIT_MISC_LAT_TIMER=f0001100
>
> xorg-x11-drv-ati-6.5.8.0-1
> ---
> RADEON_MC_AGP_LOCATION=ffc0
> RADEON_MC_FB_LOCATION=57ff4800
> RADEON_MC_STATUS=00090005
> R300_MC_INIT_MISC_LAT_TIMER=f000
>
> Where are the defines that I can use to interpret these results?
> ..
No one with databooks has added them to the driver yet. It looks like
fglrx always bumps up the display priority in
R300_MC_INIT_MISC_LAT_TIMER. We do the same thing, but only if you
specify displaypriority "high". see RADEONInitDispBandwidth().
Perhaps we should alway bump teh priority in teh open driver as well.
Also the AGP stuff is not set up the same since by default the DRI is
not enabled on XPRESS chips. Plus I think they are PCIE based anyway.
If you want to test the opensource 3D driver, you'll have to enable it
in the DDX (xf86-video-ati) and remove the checks from the 3D driver
(r300 in mesa) that keep it from loading on XPRESS hardware.
>
> When I tried to read the MC regs as you specified above, I run into
> some problems.
>
> Two Problems:
> 1) If write the index, and then read it back, it is as if
>somebody zeroed bits 3:1 of the value that I wrote.
>
> 2) All of the reads to R300_MC_IND_DATA return "0".
>
> Questions:
> 1) Am I doing anything obviously wrong? (Code below)
> 2) Is a value of "0" reasonable for these registers?
>
> NOTE: I have another laptop w/ATI that IS supported by the DRIdrivers. I'm
> gonna try to run the dumper on that an see if the
> results are different. (This should help me figure out if my radentool code
> is bad, or the XPRESS really does set everything to zero..)
>
> Here's my code (Based on PLLIN /OUT as you suggested):
>
I'm not sure what the default settings of the registers are off hand.
It probably varies from card to card. Also from the documentation I
have the MC registers start at index 0x18 and go to 0x2F (each one is
32 bits). That may explain the zeros you were seeing. As for the MC
INDEX reg, I don't know that it retains the index on read back. I
wouldn't worry about that.
> "
> #define R300_MC_IND_INDEX 0x01f8
> # define R300_MC_IND_ADDR_MASK0x3f
> #define R300_MC_IND_DATA0x01fc
>
>
> #define OUTREG8(offset, val) *(volatile unsigned char *)(((unsigned
> char*)(radeon_cntl_mem)) + (offset)) = (val)
> #define INREG(offset) *(volatile unsigned long *)(void *)(((unsigned
> char*)(radeon_cntl_mem)) + (offset))
>
> unsigned int RADEONINMC(int addr)
> {
> unsigned int data;
>
> OUTREG8(R300_MC_IND_INDEX, (addr & R300_MC_IND_ADDR_MASK));
> data = INREG(R300_MC_IND_DATA);
>
> printf("Index(Read from R300_MC_IND_INDEX): %lx ",
> INREG(R300_MC_IND_INDEX));
>
> return data;
> }
>
> void radeon_memory_control
[Bug 8722] do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8722 --- Additional Comments From [EMAIL PROTECTED] 2006-10-22 20:11 --- Created an attachment (id=7486) --> (https://bugs.freedesktop.org/attachment.cgi?id=7486&action=view) X server log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8722] do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8722 --- Additional Comments From [EMAIL PROTECTED] 2006-10-22 20:10 --- Created an attachment (id=7485) --> (https://bugs.freedesktop.org/attachment.cgi?id=7485&action=view) xorg conf file -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8722] New: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=8722 Summary: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/i810 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] --Architecture(ia32,ia32e,compatiblity): ia32 --2D driver: git(5ac927d6f05ba6f9608d7e758cbac66e8b3a9db1) --Xorg: 7.1 --Mesa: CVS tip --OS: FC5 --Kernel: 2.6.17 We got the following report when running glxinfo, glxgears or glean: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. this issue also happens on 855gm 865g 915gm 945gm platforms -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Where to start?
Anna Lissa Cruz wrote: > Hi all, > > I just signed onto the list. I'm working with Rudi Cilibrasi and > wondering where's the best place to start contributing. We're both C > programmers, with some OpenGL experience, and have NV35 and NV36 cards > to play with. We have checked out the feature matrix, and see there > are a couple of TODOs and a few WIPs. Should we just pick a TODO? Or > perhaps there's a WIP we can cut our teeth on? Hello First of all, I would advise going through existing development, to get a feel of what's done and what's left. There's quite a bit of reading about past development on the wiki. Next, we have a TODO list here : http://nouveau.freedesktop.org/wiki/ToDo Feel free to pick an item you want. If you have issues figuring how to get there, or wonder how hard implementing a speficic feature is, just drop by on irc.freenode.net channel #nouveau and ask "what's the way to implementing feature X ?" Stephane - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: question on nv35 versus nv30 protocol
Rudi Cilibrasi wrote: > Hi everybody, > > I have just started trying to contribute to this project and got as > far as identifying chip family for the two cards I have access to > here: NV35 and NV36. I added a column for NV35 assuming that the > protocol would be different than NV30 in the TODO matrix, but now am > wondering if this is correct. Does anybody know yet or will I just > have to find out myself through experimentation? > > > Hello, Yes, NV35 is mostly the same as NV30 (at least we have still to find any difference between the NV3X models with respect to 3D operation). Stephane - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI Radeon XPRESS 200M
Alex, Thanks for answering my questions. Sorry I'm a little slow to respond. I can usually only work on this when everyone in the house is asleep. (That doesn't come that often..)
You'd probably want to configure the MC in the DDX (xf86-video-ati)although you may have to coordinate with the drm if things like the
memory maps change. You shouldn't need to mess with the 3D driver(mesa). The DDX sets up the card, sets modes and handles 2D accel andoverlays. The drm provides secure access to the card in the kernelfor things like DMA and command submission. The 3D mesa driver
translates OpenGL to card specific commands and then feeds thecommands to the drm.I greped through a copy of xf86-video-ati that I checked out of git. It seems that R300_MC_IND_INDEX is only manipulated in RADEONInitDispBandwidth. Are there some other places I am missing?
(Or is there something else I should be looking for?) I shouldn't be too hard to add support for the indirect MC regs to
radeontool or another dumper. The indirect MC regs are accessed viathe MC index reg at MMIO offset 0x01F8 and the MC data reg at MMIOoffset 0x01FC. You specify the MC reg you want in the MC index regand then you can read/write to that reg via the MC data reg. bits 5:0
of the MC index reg specify the MC reg. bit 8 is the write enablebit. You should be able to use the INPLL/OUTPLL code in the radeonDDX as a model. the only difference is the PLL write enable bit is 7rather than 8. The PCIE regs are indexed as well IIRC, but once
again, I'm not too familiar with them.Alright, so I took the radeontool and tried to make this happen. First the interesting things: fglrx (8.24.8)--
RADEON_MC_AGP_LOCATION=5bff5800RADEON_MC_FB_LOCATION=57ff4800RADEON_MC_STATUS=00080001R300_MC_INIT_MISC_LAT_TIMER=f0001100xorg-x11-drv-ati-6.5.8.0-1---RADEON_MC_AGP_LOCATION=ffc0
RADEON_MC_FB_LOCATION=57ff4800RADEON_MC_STATUS=00090005R300_MC_INIT_MISC_LAT_TIMER=f000Where are the defines that I can use to interpret these results? .. When I tried to read the MC regs as you specified above, I run into
some problems. Two Problems: 1) If write the index, and then read it back, it is as if somebody zeroed bits 3:1 of the value that I wrote. 2) All of the reads to R300_MC_IND_DATA return "0".
Questions: 1) Am I doing anything obviously wrong? (Code below) 2) Is a value of "0" reasonable for these registers? NOTE: I have another laptop w/ATI that IS supported by the DRIdrivers. I'm gonna try to run the dumper on that an see if the
results are different. (This should help me figure out if my radentool code is bad, or the XPRESS really does set everything to zero..)Here's my code (Based on PLLIN /OUT as you suggested): "#define R300_MC_IND_INDEX 0x01f8
# define R300_MC_IND_ADDR_MASK 0x3f#define R300_MC_IND_DATA 0x01fc#define OUTREG8(offset, val) *(volatile unsigned char *)(((unsigned char*)(radeon_cntl_mem)) + (offset)) = (val)
#define INREG(offset) *(volatile unsigned long *)(void *)(((unsigned char*)(radeon_cntl_mem)) + (offset))unsigned int RADEONINMC(int addr){ unsigned int data; OUTREG8(R300_MC_IND_INDEX, (addr & R300_MC_IND_ADDR_MASK));
data = ""> printf("Index(Read from R300_MC_IND_INDEX): %lx ", INREG(R300_MC_IND_INDEX)); return data;}void radeon_memory_controller(void){ unsigned int i;
for (i=0;i<=0x3f;i++) { printf("Index(written to R300_MC_IND_INDEX): %x ", i); printf("R300_MC_IND_DATA: %x\n", RADEONINMC(i)); }}Output:
"Index(written to R300_MC_IND_INDEX): 0 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 1 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 2 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 3 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 4 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 5 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 6 Index(Read from R300_MC_IND_INDEX): 0 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 7 Index(Read from R300_MC_IND_INDEX): 1 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): 8 Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): 9 Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): a Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): b Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0
Index(written to R300_MC_IND_INDEX): c Index(Read from R300_MC_IND_INDEX): 8 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): d Index(Read from R300_MC_IND_INDEX): 9 R300_MC_IND_DATA: 0Index(written to R300_MC_IND_INDEX): e Index(Read from R300_
