Re: Testing DRI on ATI Radeon Xpress 200M IGP (5975)

[Markus Amsler]

Ludovic Brenta wrote:
> Hello,
>
> Tonight I finally took the time to enable DRI on my laptop.  I
> understand that support for my particular chipset is experimental and
> currently "needs more testing on differing models", and I hereby offer
> help for testing.
>
> DRI appears to work and glxgears says:
> Warning, xpress200 detected.
> 2066 frames in 5.0 seconds = 413.009 FPS
> 2078 frames in 5.0 seconds = 415.508 FPS
> 2066 frames in 5.0 seconds = 413.098 FPS
> 2070 frames in 5.0 seconds = 413.984 FPS
> 2099 frames in 5.0 seconds = 419.766 FPS
>
> I would like to know if there is a particular area of the driver, or a
> particular feature of the chipset, that needs testing.  What can I do
> to help?
>
>   
I can't comment on particular feature/dirver area, just how to test in 
general.
Test results are most valuable against current git. Have a look at 
http://wiki.x.org/wiki/Development/git how to compile/install/run 
xorg/drm/mesa/xf86-video-ati from git sources.
Then take your favorite OpenGL apps and watch out for errors. If you 
found some errors in git, compare it with dri from debian and  perhaps 
with fglrx. If something works with debian/unstable but not git, you can 
bisect to find which patch caused a regression.
And of course report any found bugs.

Markus

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Testing DRI on ATI Radeon Xpress 200M IGP (5975)

[Ludovic Brenta]

Hello,

Tonight I finally took the time to enable DRI on my laptop.  I
understand that support for my particular chipset is experimental and
currently "needs more testing on differing models", and I hereby offer
help for testing.

DRI appears to work and glxgears says:
Warning, xpress200 detected.
2066 frames in 5.0 seconds = 413.009 FPS
2078 frames in 5.0 seconds = 415.508 FPS
2066 frames in 5.0 seconds = 413.098 FPS
2070 frames in 5.0 seconds = 413.984 FPS
2099 frames in 5.0 seconds = 419.766 FPS

I would like to know if there is a particular area of the driver, or a
particular feature of the chipset, that needs testing.  What can I do
to help?

lspci -nn says:

00:00.0 Host bridge [0600]: ATI Technologies Inc RS480 Host Bridge [1002:5950] 
(rev 10)
00:01.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a3f]
00:06.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a38]
00:12.0 IDE interface [0101]: ATI Technologies Inc IXP SB400 Serial ATA 
Controller [1002:4379] (rev 80)
00:13.0 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host 
Controller [1002:4374] (rev 80)
00:13.1 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB Host 
Controller [1002:4375] (rev 80)
00:13.2 USB Controller [0c03]: ATI Technologies Inc IXP SB400 USB2 Host 
Controller [1002:4373] (rev 80)
00:14.0 SMBus [0c05]: ATI Technologies Inc IXP SB400 SMBus Controller 
[1002:4372] (rev 81)
00:14.1 IDE interface [0101]: ATI Technologies Inc IXP SB400 IDE Controller 
[1002:4376] (rev 80)
00:14.2 Audio device [0403]: ATI Technologies Inc IXP SB4x0 High Definition 
Audio Controller [1002:437b] (rev 01)
00:14.3 ISA bridge [0601]: ATI Technologies Inc IXP SB400 PCI-ISA Bridge 
[1002:4377] (rev 80)
00:14.4 PCI bridge [0604]: ATI Technologies Inc IXP SB400 PCI-PCI Bridge 
[1002:4371] (rev 80)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control [1022:1103]
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS485 [Radeon 
Xpress 1100 IGP] [1002:5975]
02:01.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5788 
Gigabit Ethernet [14e4:169c] (rev 03)
02:04.0 CardBus bridge [0607]: Texas Instruments PCIxx12 Cardbus Controller 
[104c:8039]
30:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11a/b/g 
[14e4:4312] (rev 01)

My laptop is a HP Compaq nx6325 with AMD Turion TL-60 (dual-core, 2
GHz) with 2 GiB RAM, running Debian GNU/Linux testing/unstable with
the following relevant packages:

ii  linux-image-2.6.24-1-amd642.6.24-5  Linux 2.6.24 image on 
AMD64
ii  xserver-xorg  1:7.3+10  the X.Org X server
ii  xserver-xorg-core 2:1.4.1~git20080131-3 Xorg X server - core 
server
ii  xserver-xorg-input-kbd1:1.2.2-3 X.Org X server -- 
keyboard input driver
ii  xserver-xorg-input-mouse  1:1.2.3-2 X.Org X server -- mouse 
input driver
ii  xserver-xorg-input-synaptics  0.14.7~git20070706-2  Synaptics TouchPad 
driver for X.Org/XFree86 
ii  xserver-xorg-video-ati1:6.8.0-1 X.Org X server -- ATI 
display driver
ii  freeglut3 2.4.0-6   OpenGL Utility Toolkit
ii  libgl1-mesa-dev   7.0.3~rc2-2   A free implementation 
of the OpenGL API -- G
ii  libgl1-mesa-dri   7.0.3~rc2-2   A free implementation 
of the OpenGL API -- D
ii  libgl1-mesa-glx   7.0.3~rc2-2   A free implementation 
of the OpenGL API -- G
ii  libglu1-mesa  7.0.3~rc2-2   The OpenGL utility 
library (GLU)
ii  libglu1-mesa-dev  7.0.3~rc2-2   The OpenGL utility 
library -- development fi
ii  mesa-common-dev   7.0.3~rc2-2   Developer documentation 
for Mesa
ii  mesa-utils7.0.3~rc2-2   Miscellaneous Mesa GL 
utilities

-- 
Ludovic Brenta.


-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ATI Radeon XPRESS 200M

[ivniyi502]

On 11/22/06, Phillip Ezolt phillipezolt-at-. |rivatv-devel| <
...> wrote:


Alright.  I don't have an "interleaved" options in my BIOS.
I only have:

Sideport_Only (128M)
Sideport(128M)+UMA(0M)
Sideport(128M)+UMA(32M)
Sideport(128M)+UMA(64M)
Sideport(128M)+UMA(128M)



According to what little I understand of the system, interleaving is handled
automagically by the chipset whenever the size of the Sideport and UMA RAM
areas are the same.  So in this case, the Sideport(128M)+UMA(128M) case
would be automatically interleaved.



I don't know if it is interleaved.  There is no option for me to change
the interleaving settings.



I don't think there is one, I think this is somehow detected by the
hardware.



--Phil

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ATI Radeon XPRESS 200M

[Alex Deucher]

On 11/21/06, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Phillip Ezolt wrote:
> > Roland,
> >
> > On 11/21/06, *Roland Scheidegger* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Phillip Ezolt wrote:
> >> It does get recognized as PCI.  However, I had to force it PCIE.
> >> (using  Option"BusType" "PCIE").  These cards are
> >> definately PCIE, so the original detection was wrong.
> >>
> >> I wonder if the MC_AGP_LOCATION register means something different
> >>  on the 200M.  These cards have an extra PCIE component which is
> >> supposed to shuffle graphics stuff to and from the memory.  (This
> >> is in addition to the normal channels to and from the graphics
> >> card..)
> > I'd be surprised if it's really different. I'd suspect that addresses
> >  within the AGP space just go untranslated to the bus without address
> >  translation as they did with other chips (with the chipset being
> > responsible for translation). In any case, setting this up without
> > RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx
> > configures a 128MB window there. Maybe the chipset actually does some
> >  kind of agp gart remapping when set up correctly.
> >
> >
> > Hmm. Maybe I just stumbled upon something good by accident.  Like I
> > said in the original email, there are still problems (garbage on the
> >  top half of the screen, and the hang).
> It's a bit weird. Maybe this is how the uma+sideport setting works.
>
> > Should I read the value of "RADEON_AGP_BASE" when I have the working
> >  8.24.8 driver and try to set that as well in the DRM module?
> You can't just change that in the drm I think.
>
> > "This PCI Express auxiliary memory channel is effectively a 64-bit
> > memory channel with access to system memory. This means that a VPU
> > equipped with a 64-bit local graphics memory bus and a PCI Express
> > auxiliary memory channel has an effective 128-bit memory bus."
> >
> > So, it looks as if there is at least two channels out of the card
> > when it has hypermemory.
> I think this is really only true for the xpress200 igps with local ram
> in interleaved mode. I've never seen anything indicating that the
> "normal" chips are actually able to split data like that - though
> careful placing of some buffers in system ram and some other buffers in
> local ram might indeed increase available bandwidth a bit slightly. But
> there isn't really any additional "memory channel" involved in this
> case, it's just the ability of the gpu's memory controller to read from
> system ram directly, which it has had since ages...
>
> > (Gee, ATI, specs would be nice..)
> >
> > You don't have a xpress200 with local ram (sideport), right? I think
> >  something strange is going on with that agp location stuff.
> >
> >
> > My laptop has 128M of sideport memory, and I have the BIOS configured
> >  so there is 128M of sideport + 128M of UMA memory. (for a total of
> > 256M).
> Ah! Is that interleaved or not? This setup is likely more complicated to
> configure correctly than just using sideport (or uma) alone. I could be
> wrong though, with some luck the chip / bios handles this fully
> transparent on its own.
>
> > Interestingly, the fgrlx v8.24.8 driver (the one that works...), only
> >  detects 128M of memory.
> >
> > The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly
> > after start up), detects 256M of memory, and has a different value
> > for the MC_AGP_LOCATION.
> >
> > So, I'm guessing, that the v8.24.8 driver is probably exclusively
> > using either the UMA or Sideport memory (and working correctly..).  I
> >  don't know which (and I don't know how to figure it out... ;-) )
> This sounds like a very reasonable assumption. I think you should play
> around with the bios settings and see what happens.
>

FWIW, I've heard reports of some XPRESS users having success with
fglrx only after messing with the bios.

Alex

> Roland
>
>

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

Roland,

On 11/21/06, Roland Scheidegger <[EMAIL PROTECTED]> wrote:


Phillip Ezolt wrote:
> It does get recognized as PCI.  However, I had to force it PCIE.
> (using  Option"BusType" "PCIE").  These cards are definately
>  PCIE, so the original detection was wrong.
>
> I wonder if the MC_AGP_LOCATION register means something different on
>  the 200M.  These cards have an extra PCIE component which is
> supposed to shuffle graphics stuff to and from the memory.  (This is
>  in addition to the normal channels to and from the graphics card..)
I'd be surprised if it's really different. I'd suspect that addresses
within the AGP space just go untranslated to the bus without address
translation as they did with other chips (with the chipset being
responsible for translation). In any case, setting this up without
RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx
configures a 128MB window there. Maybe the chipset actually does some
kind of agp gart remapping when set up correctly.



Hmm. Maybe I just stumbled upon something good by accident.  Like I said in
the original email, there are still problems (garbage on the top half of the
screen, and the hang).

Should I read the value of "RADEON_AGP_BASE" when I have the working
8.24.8driver and try to set that as well in the DRM module?


The hypermemory whitepaper gives more details:
> http://ati.amd.com/technology/HyperMemory_Whitepaper.pdf. Several
> people have said that "Hypermemory" is just a fancy algorithm to move
>  from graphics card memory to main memory.  From my reading of that
> white paper, there is actually more to it.. they have an auxiliary
> memory channel.  It's hard to tell exactly what it is or how to
> control it. The paper has a fair amount of marketing speak, but look
>  at the diagram on page 7.. And especially when they talk about the
> auxiliary memory channel.
I'm not quite convinced this "auxiliary memory channel" really exists.
Might be just the ability to access memory directly due to the pcie
address remapper it has.



Ok. That's what these slides seem to say:
http://www.hothardware.com/viewarticle.aspx?page=2&articleid=647

However, the whitepaper says:

"This PCI Express auxiliary memory channel is effectively a 64-bit memory
channel with access to
system memory. This means that a VPU equipped with a 64-bit local graphics
memory bus and a PCI
Express auxiliary memory channel has an effective 128-bit memory bus."

So, it looks as if there is at least two channels out of the card when it
has hypermemory.

(Gee, ATI, specs would be nice..)

You don't have a xpress200 with local ram (sideport), right?

I think something strange is going on with that agp location stuff.



My laptop has 128M of sideport memory, and I have the BIOS configured so
there is 128M of sideport + 128M of UMA memory. (for a total of 256M).

Interestingly, the fgrlx v8.24.8 driver (the one that works...), only
detects 128M of memory.

The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly after start
up), detects 256M of memory, and has a different value for the
MC_AGP_LOCATION.

So, I'm guessing, that the v8.24.8 driver is probably exclusively using
either the UMA or Sideport memory (and working correctly..).  I don't know
which (and I don't know how to figure it out... ;-) )

(I don't have access to the log files for these right now, but if you're
interested, I can send them later tonight. )


Anyway.
>
> My Xorg.0.log is attached.  It is a little chatty because I have
> RADEON_DEBUG enabled.
>
> (NOTE: There's one problem I know about.. I don't have r300_dri.so in
>  the right place.  However, having this missing shouldn't hang the
> box.)
It's probably a good idea to NOT have it there for now - it's completely
optional, xorg itself won't touch it (except aiglx).




Ok.  Cool.  I won't worry about it then.



Roland



--Phil
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ATI Radeon XPRESS 200M

[Roland Scheidegger]

Phillip Ezolt wrote:
> Roland,
> 
> On 11/21/06, *Roland Scheidegger* <[EMAIL PROTECTED] 
> > wrote:
> 
> Phillip Ezolt wrote:
>> It does get recognized as PCI.  However, I had to force it PCIE. 
>> (using  Option"BusType" "PCIE").  These cards are 
>> definately PCIE, so the original detection was wrong.
>> 
>> I wonder if the MC_AGP_LOCATION register means something different
>>  on the 200M.  These cards have an extra PCIE component which is 
>> supposed to shuffle graphics stuff to and from the memory.  (This 
>> is in addition to the normal channels to and from the graphics 
>> card..)
> I'd be surprised if it's really different. I'd suspect that addresses
>  within the AGP space just go untranslated to the bus without address
>  translation as they did with other chips (with the chipset being 
> responsible for translation). In any case, setting this up without 
> RADEON_AGP_BASE likely makes little sense. I'm not sure why fglrx 
> configures a 128MB window there. Maybe the chipset actually does some
>  kind of agp gart remapping when set up correctly.
> 
> 
> Hmm. Maybe I just stumbled upon something good by accident.  Like I 
> said in the original email, there are still problems (garbage on the
>  top half of the screen, and the hang).
It's a bit weird. Maybe this is how the uma+sideport setting works.

> Should I read the value of "RADEON_AGP_BASE" when I have the working
>  8.24.8 driver and try to set that as well in the DRM module?
You can't just change that in the drm I think.

> "This PCI Express auxiliary memory channel is effectively a 64-bit 
> memory channel with access to system memory. This means that a VPU 
> equipped with a 64-bit local graphics memory bus and a PCI Express 
> auxiliary memory channel has an effective 128-bit memory bus."
> 
> So, it looks as if there is at least two channels out of the card 
> when it has hypermemory.
I think this is really only true for the xpress200 igps with local ram
in interleaved mode. I've never seen anything indicating that the
"normal" chips are actually able to split data like that - though
careful placing of some buffers in system ram and some other buffers in
local ram might indeed increase available bandwidth a bit slightly. But
there isn't really any additional "memory channel" involved in this
case, it's just the ability of the gpu's memory controller to read from
system ram directly, which it has had since ages...

> (Gee, ATI, specs would be nice..)
> 
> You don't have a xpress200 with local ram (sideport), right? I think
>  something strange is going on with that agp location stuff.
> 
> 
> My laptop has 128M of sideport memory, and I have the BIOS configured
>  so there is 128M of sideport + 128M of UMA memory. (for a total of 
> 256M).
Ah! Is that interleaved or not? This setup is likely more complicated to
configure correctly than just using sideport (or uma) alone. I could be
wrong though, with some luck the chip / bios handles this fully
transparent on its own.

> Interestingly, the fgrlx v8.24.8 driver (the one that works...), only
>  detects 128M of memory.
> 
> The fglrx v8.28.8 driver (which DOESN'T work... It hangs shortly 
> after start up), detects 256M of memory, and has a different value 
> for the MC_AGP_LOCATION.
> 
> So, I'm guessing, that the v8.24.8 driver is probably exclusively 
> using either the UMA or Sideport memory (and working correctly..).  I
>  don't know which (and I don't know how to figure it out... ;-) )
This sounds like a very reasonable assumption. I think you should play
around with the bios settings and see what happens.

Roland


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: ATI Radeon XPRESS 200M

[Alex Deucher]

On 11/5/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
>
> On 11/1/06, Alex Deucher <[EMAIL PROTECTED]> wrote:
> > Sorry for the delay in response.
>
> No problem. I appreciate the responses.
>
> > These are what the bits in the RBBM_STATUS register mean for r300
> > (XPRESS may differ slightly)
> >
> > 6:0  Available slots in the FIFO
> > 8Host Interface active
> > 9CP request active
> > 10   FIFO request active
> > 11   Host Interface retry active
> > 12   CP retry active
> > 13   FIFO retry active
> > 14   FIFO pipeline busy
> > 15   Event engine busy
> > 16   CP command stream busy
> > 17   2D engine busy
> > 18   2D portion of render backend busy
> > 20   3D setup engine busy
> > 26   GA engine busy
> > 27   CBA 2D engine busy
> > 31   2D engine busy or 3D engine busy or FIFO not empty or CP busy or
> > command stream queue not empty or Ring Buffer not empty
> >
> >
> > Based on this information (which could be different for XPRESS),
> > "0x8001c100" means:
> > host interface is active
> > FIFO pipeline busy
> > Event engine busy
> > CP command stream busy
> > bit 31 - something is busy
> >
> > Good luck!
> >
> > Alex
>
> Alex,
> First, thanks for the clarification and help.
>
> Ok.  I've made a small amount of progress. I figured out that the X
> server was treating the card as a PCI card rather than a PCIExpress card.  I
> fixed that by forcing the bus type. (Option "BusType" "PCIE").

Good.  make sure the PCIE ring buffer is set up properly in vram.

>
> I've also tracked the CP hang down a little more. It hangs on the first use
> after radeon_do_init_cp has completed.  So, rather than a particular bogus
> command, I suspect that this some sort of setup issue.
>
>  I've turned on tracing like crazy (and added some of my own debugging), so
> maybe this can help:
>
> Initialization:
> 
> [drm:radeon_do_init_cp]
> [drm:radeon_do_init_cp] dev_priv->cp_ring->handle f8bd1000
> [drm:radeon_do_init_cp] dev_priv->ring_rptr->handle f8cd2000
> [drm:radeon_do_init_cp] dev->agp_buffer_map->handle f8cd3000
> [drm] Setting GART location based on new memory map
> [drm:radeon_do_init_cp] dev_priv->gart_size 8388608
> [drm:radeon_do_init_cp] dev_priv->gart_vm_start 0x5800
> [drm:radeon_do_init_cp] dev_priv->gart_buffers_offset 0x58102000
> [drm:radeon_do_init_cp] Setting phys_pci_gart to f8bb 0FFF8000
> [drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 57FF8000 mapped at F8BB
> [drm:radeon_set_pciegart] programming pcie 5800 57FF8000 0080
> [drm:radeon_cp_load_microcode]
> [drm] radeon_do_wait_for_fifo 6: Succeeded!
> [drm] radeon_do_wait_for_idle 6: Succeeded!
> [drm] Loading R300 Microcode
> [drm:radeon_cp_init_ring_buffer] ring rptr:
> offset=0x33adf000 handle=0xf8cd2000
> [drm] radeon_do_wait_for_fifo 6: Succeeded!
> [drm] radeon_do_wait_for_idle 6: Succeeded!
> [drm:radeon_do_engine_reset]
> [drm:radeon_do_cp_reset]
> 
>
> In radeon_do_cp_start:
>
> [drm] radeon_do_cp_start: About to COMMIT ring:
> radeon_status:
> RBBM_STATUS = 0x0140
> CP_RB_RTPR = 0x
> CP_RB_WTPR = 0x
> AIC_CNTL = 0x07e0
>  AIC_STAT = 0x
> AIC_PT_BASE = 0x
> TLB_ADDR = 0x
> TLB_DATA = 0x
>
> [drm] radeon_do_cp_start: Finished COMMIT ring:
> radeon_status:
> RBBM_STATUS = 0x80010140
> CP_RB_RTPR = 0x0006
> CP_RB_WTPR = 0x0006
> AIC_CNTL = 0x07e0
> AIC_STAT = 0x
> AIC_PT_BASE = 0x
> TLB_ADDR = 0x
> TLB_DATA = 0x
>
> For "RBBM_STATUS = 0xXXX1", this means:
>  bit 16:   CP command stream busy
>
> After this, the "CP command stream" never reports a "non-busy" status. Ie,
> bit 16 (AND bit 31) is always set.
>
> Do you have any idea how the CP could go haywire?

Lots of things.  It could be a hardware bug on the XPRESS chips that
the busy bit never clears, although I would hope a bit that important
would work properly.  You might try waiting on slots rather than on
the busy bit as a work around.  Savage chips have a bug like this,
fortunately they have an alternate method for checking status.

>
> 0) What has to be setup properly for the CP work? (Or conversely, what, if
> setup improperly, could cause the CP to hang...)

Lots of stuff can cause it to hang unfortunately.

>
> 1) Could the ring buffer be mapped into a different location than we told
> the CP?  (And the CP is executing some bogus/random commands..)  (In
> particular, would this mean that the code in 'radeon_cp_init_ring_buffer' is
> wrong for this card? )


XPRESS chips may need some additional set up.

>
> 2) Could the R300 FW that has been uploaded be the incorrect one for this
> card? (I noticed that radeon_do_cp_start is the first time the cp is fed
> commands after the FW is loaded. )  Is there a simple test to see if the CP
> is working?
>

Very possible.  you might try grabbing the microcode from fglrx or the
windows driver and see if that helps.

> There are more problems later, but I think that this is the start of 

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

Alex, On 11/1/06, Alex Deucher <[EMAIL PROTECTED]> wrote:
Sorry for the delay in response.No problem. I appreciate the responses. 
These are what the bits in the RBBM_STATUS register mean for r300(XPRESS may differ slightly)6:0  Available slots in the FIFO 8Host Interface active 9CP request active10   FIFO request active
11   Host Interface retry active12   CP retry active13   FIFO retry active14   FIFO pipeline busy15   Event engine busy16   CP command stream busy17   2D engine busy18   2D portion of render backend busy
20   3D setup engine busy26   GA engine busy27   CBA 2D engine busy31   2D engine busy or 3D engine busy or FIFO not empty or CP busy orcommand stream queue not empty or Ring Buffer not empty
Based on this information (which could be different for XPRESS),"0x8001c100" means:host interface is activeFIFO pipeline busyEvent engine busyCP command stream busybit 31 - something is busy
Good luck!AlexAlex,    First, thanks for the clarification and help.     Ok.  I've made a small amount of progress. I figured out that the X server was treating the card as a PCI card rather than a PCIExpress card.  I fixed that by forcing the bus type. (Option "BusType" "PCIE").
I've also tracked the CP hang down a little more. It hangs on the first use after radeon_do_init_cp has completed.  So, rather than a particular bogus command, I suspect that this some sort of setup issue.
I've turned on tracing like crazy (and added some of my own debugging), so maybe this can help:Initialization: [drm:radeon_do_init_cp] [drm:radeon_do_init_cp] dev_priv->cp_ring->handle f8bd1000
[drm:radeon_do_init_cp] dev_priv->ring_rptr->handle f8cd2000[drm:radeon_do_init_cp] dev->agp_buffer_map->handle f8cd3000[drm] Setting GART location based on new memory map[drm:radeon_do_init_cp] dev_priv->gart_size 8388608
[drm:radeon_do_init_cp] dev_priv->gart_vm_start 0x5800[drm:radeon_do_init_cp] dev_priv->gart_buffers_offset 0x58102000[drm:radeon_do_init_cp] Setting phys_pci_gart to f8bb 0FFF8000[drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 57FF8000 mapped at F8BB
[drm:radeon_set_pciegart] programming pcie 5800 57FF8000 0080[drm:radeon_cp_load_microcode] [drm] radeon_do_wait_for_fifo 6: Succeeded![drm] radeon_do_wait_for_idle 6: Succeeded![drm] Loading R300 Microcode
[drm:radeon_cp_init_ring_buffer] ring rptr: offset=0x33adf000 handle=0xf8cd2000[drm] radeon_do_wait_for_fifo 6: Succeeded![drm] radeon_do_wait_for_idle 6: Succeeded![drm:radeon_do_engine_reset] [drm:radeon_do_cp_reset] 
In radeon_do_cp_start:[drm] radeon_do_cp_start: About to COMMIT ring: radeon_status:RBBM_STATUS = 0x0140CP_RB_RTPR = 0xCP_RB_WTPR = 0xAIC_CNTL = 0x07e0
AIC_STAT = 0xAIC_PT_BASE = 0xTLB_ADDR = 0xTLB_DATA = 0x[drm] radeon_do_cp_start: Finished COMMIT ring: radeon_status:RBBM_STATUS = 0x80010140CP_RB_RTPR = 0x0006
CP_RB_WTPR = 0x0006AIC_CNTL = 0x07e0AIC_STAT = 0xAIC_PT_BASE = 0xTLB_ADDR = 0xTLB_DATA = 0xFor "RBBM_STATUS = 0xXXX1", this means: 
bit 16:   CP command stream busyAfter this, the "CP command stream" never reports a "non-busy" status. Ie, bit 16 (AND bit 31) is always set.Do you have any idea how the CP could go haywire? 
0) What has to be setup properly for the CP work? (Or conversely, what, if setup improperly, could cause the CP to hang...)1) Could the ring buffer be mapped into a different location than we told the CP?  (And the CP is executing some bogus/random commands..)  (In particular, would this mean that the code in 'radeon_cp_init_ring_buffer' is wrong for this card? )
2) Could the R300 FW that has been uploaded be the incorrect one for this card? (I noticed that radeon_do_cp_start is the first time the cp is fed commands after the FW is loaded. )  Is there a simple test to see if the CP is working? 
There are more problems later, but I think that this is the start of the badness.Thanks,--Phil 
-
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 Deucher]

Sorry for the delay in response.


On 10/30/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
>
>
> > >
> > > (II) resource ranges after probing:
> > > DRI broken:
> > >[33] 0  0   0x03b0 - 0x03bb (0xc) IS[B]
> > >[34] 0  0   0x03c0 - 0x03df (0x20) IS[B]
> > > ...
> > > fglrx:
> > >[34] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
> > >[35] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]
> > >
> > > 1) What are these mappings used for?
> >
> > Not sure.  Possibly something for PCIE GART?  What apertures does the
> > XPRESS chip expose?
>
> How do I check that?  Here's what lspci exposes:
>
>  01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS
> 200M 5955 (PCIE) (prog-if 00 [VGA])
> Subsystem: Hewlett-Packard Company Unknown device 30a4
> Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 201
> Memory at c000 (32-bit, prefetchable) [size=256M]
> I/O ports at 9000 [size=256]
> Memory at b010 (32-bit, non-prefetchable) [size=64K]
> [virtual] Expansion ROM at b012 [disabled] [size=128K]
> Capabilities: [50] Power Management version 2

that looks pretty standard.

> >
> > > 3) What part of radeon probe would be responsible for adding these?
> > >
> >
> > RADEONMapMMIO() and RADEONMapFB() set up the register and FB maps and
> > RADEONInitMemoryMap() and friends handle chip side stuff for the
> > memory controller, etc.
>
> Ok.  I'll check those out.  I'm having a little difficultly figuring out
> what exactly these mappings mean.   (So, this is just basic stuff..)
>
> Does it indicate where the various components of the graphics card are
> mapped into the Xorg server address space?
>
> (I've read
> http://ftp.x.org/pub/X11R6.9.0/doc/html/DESIGN9.html. It
> has details, but the not a high-level overview.)
>

mapMMIO maps the register access aperture, mapFB maps the framebuffer
access aperture.

>
> > Sorry I can't be more helpful.
> >
> > Alex
>
> As an aside, I figured out why the CPU time jumps to 100%.
>
> RADEONLoadCursorImage calls RADEONWaitForIdleCP and we loop infinitely in
> it.  Since this calls into the kernel DRM module, I turned on debugging.
>
> The X server calls: drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE);
>
> Which then calls -> [drm:radeon_cp_idle] -> [drm:radeon_do_cp_idle] ->
> [drm:radeon_do_wait_for_idle]
>
> This fails, returns back up the stack, and then the call happens again.
> ...
>
> So, the CPU is spinning waiting for the card to be idle.  I turned on
> debugging so that I can see the status register.
>
> messages:Oct 26 23:53:57 localhost kernel: RBBM_STATUS = 0x80010140
> [Repeated 10 more times.]
> messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x88030140
> messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x8803613f
> messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036139
> messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036133
> messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x8803612d
> messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036127
> messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036121
> messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x8803611b
> messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036115
> messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8803610f
> messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036109
> messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036103
> messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8001c100
> [Repeated forever..]
>  I can see from the include that the 1<<31 bit being set means that the card
> is active.
>
> I found a reference on the net which said that the other bits of the
> register actually tell WHAT part of the card is busy.  However, I can't find
> any place that actually defines what they mean.  What does a status of
> "0x8001c100" mean? (ie, what parts are busy?  That might help me figure out
> what is misconfigured... )
>
> (On the plus side, it actually looks like DRM is reading the proper memory
> for the status register. I can see the number of free FIFO entries
> decreasing...)
>

These are what the bits in the RBBM_STATUS register mean for r300
(XPRESS may differ slightly)

6:0  Available slots in the FIFO
 8Host Interface active
 9CP request active
10   FIFO request active
11   Host Interface retry active
12   CP retry active
13   FIFO r

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

Alex, >> (II) resource ranges after probing:
> DRI broken:>[33] 0  0   0x03b0 - 0x03bb (0xc) IS[B]>[34] 0  0   0x03c0 - 0x03df (0x20) IS[B]> ...> fglrx:>[34] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
>[35] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]>> 1) What are these mappings used for?Not sure.  Possibly something for PCIE GART?  What apertures does theXPRESS chip expose?
How do I check that?  Here's what lspci exposes:  01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA])    Subsystem: Hewlett-Packard Company Unknown device 30a4
    Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 201    Memory at c000 (32-bit, prefetchable) [size=256M]    I/O ports at 9000 [size=256]    Memory at b010 (32-bit, non-prefetchable) [size=64K]
    [virtual] Expansion ROM at b012 [disabled] [size=128K]    Capabilities: [50] Power Management version 2


> 3) What part of radeon probe would be responsible for adding these?>RADEONMapMMIO() and RADEONMapFB() set up the register and FB maps andRADEONInitMemoryMap() and friends handle chip side stuff for the
memory controller, etc.Ok.  I'll check those out.  I'm having a little difficultly figuring out what exactly these mappings mean.   (So, this is just basic stuff..) Does it indicate where the various components of the graphics card are mapped into the Xorg server address space? 
 (I've read http://ftp.x.org/pub/X11R6.9.0/doc/html/DESIGN9.html. It has details, but the not a high-level overview.)

Sorry I can't be more helpful.AlexAs an aside, I figured out why the CPU time jumps to 100%.  RADEONLoadCursorImage calls RADEONWaitForIdleCP and we loop infinitely in it.  Since this calls into the kernel DRM module, I turned on debugging. 
The X server calls: drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE); Which then calls -> [drm:radeon_cp_idle] -> [drm:radeon_do_cp_idle] -> [drm:radeon_do_wait_for_idle]This fails, returns back up the stack, and then the call happens again. 
...So, the CPU is spinning waiting for the card to be idle.  I turned on debugging so that I can see the status register. messages:Oct 26 23:53:57 localhost kernel: RBBM_STATUS = 0x80010140[Repeated 10 more times.]
messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x88030140messages:Oct 26 23:54:03 localhost kernel: RBBM_STATUS = 0x8803613fmessages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036139messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036133
messages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x8803612dmessages:Oct 26 23:54:04 localhost kernel: RBBM_STATUS = 0x88036127messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036121messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x8803611b
messages:Oct 26 23:54:05 localhost kernel: RBBM_STATUS = 0x88036115messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8803610fmessages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036109messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x88036103
messages:Oct 26 23:54:06 localhost kernel: RBBM_STATUS = 0x8001c100[Repeated forever..] I can see from the include that the 1<<31 bit being set means that the card is active. I found a reference on the net which said that the other bits of the register actually tell WHAT part of the card is busy.  However, I can't find any place that actually defines what they mean.  What does a status of "0x8001c100" mean? (ie, what parts are busy?  That might help me figure out what is misconfigured... ) 
(On the plus side, it actually looks like DRM is reading the proper memory for the status register. I can see the number of free FIFO entries decreasing...) Thanks,--PhilFWIW: Here's a full debug state when it gets stuck (These repeat, but the CP_RB_WTPR  increases by 6. ): 
[drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1[drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100


CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0xa895AIC_CNTL = 0x07e1AIC_STAT = 0xAIC_PT_BASE = 0x35428000TLB_ADDR = 0xTLB_DATA = 0x[drm:drm_ioctl] ret = fff0

[drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1
[drm:radeon_cp_idle] [drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0xa89bAIC_CNTL = 0x07e1
AIC_STAT = 0xAIC_PT_BASE = 0x35428000TLB_ADDR = 0xTLB_DATA = 0x[drm:drm_ioctl] ret = fff0[drm:drm_ioctl] pid=2392, cmd=0x6444, nr=0x44, dev 0xe200, auth=1[drm:radeon_cp_idle] 
[drm:radeon_do_cp_idle] [drm:radeon_do_wait_for_fifo] *ERROR* failed!radeon_status:RBBM_STATUS = 0x8001c100CP_RB_RTPR = 0x00f7CP_RB_WTPR = 0x00

Re: ATI Radeon XPRESS 200M

[Alex Deucher]

On 10/26/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
>
> I was able to get the latest and greatest of everything compiled and
> "limping".  X starts up, and then proceeds to consume 100% of the CPU. I
> have a good debugging environment, so I'll be able to walk through it with
> gdb to figure out exactly what's causing the problem. Once it gets in this
> state, I can't kill the X server, and gdb can't attach to it.
>
> According to oprofile, all of the CPU time is being spent in the kernel on
> the "delay_pmtmr" function.
>
> So it is appears as if we are in the kernel & waiting for something.
>
> (As an ASIDE, I spent a bunch of time tracing down a stupid kernel panic. If
> DRM_MEMORY_DEBUG is defined for the DRM module, drm_ioremap is completely
> broken... It will call itself, and eventually cause a panic. )
>
> >
> > Let us know how it goes!
> >
> > Alex
> >
> > >  Cheers,
> > > --Phil
> > >
> > >
> > >
> >
>
> After looking over the Xorg log files, I discovered differences in the
> mappings between the firegl & and the radeon drivers.
>
> I noticed the maps from both the FireGL driver and radeon driver were very
> similar.
>
> However, there were two differences.
>
> First, the fglrx driver has an extra entry:
> [2] -1  0   0xffe0 - 0x (0x20) MX[B](B)
>
> Second, the radeon drivers looks like they have broken mappings.
>
> The MMIO range begins at: 0xb010. The last two mappings in the fglrx
> driver are within that range.  However, in the radeon driver, the are offset
> from 0, yet claim to be in I/O space.
>
> (II) resource ranges after probing:
> DRI broken:
>[33] 0  0   0x03b0 - 0x03bb (0xc) IS[B]
>[34] 0  0   0x03c0 - 0x03df (0x20) IS[B]
> ...
> fglrx:
>[34] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
>[35] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]
>
> 1) What are these mappings used for?

Not sure.  Possibly something for PCIE GART?  What apertures does the
XPRESS chip expose?

> 2) Could this incorrect mapping explain the problems that I'm seeing?

Possibly.

> 3) What part of radeon probe would be responsible for adding these?
>

RADEONMapMMIO() and RADEONMapFB() set up the register and FB maps and
RADEONInitMemoryMap() and friends handle chip side stuff for the
memory controller, etc.

Sorry I can't be more helpful.

Alex

> Thanks,
> --Phil
>
> Complete map (Working FGRLX):
> (II) resource ranges after preInit:
> [0] 0   0   0xb010 - 0xb010 (0x1) MX[B]
> [1] 0   0   0xc000 - 0xcfff (0x1000) MX[B]
> [2] -1  0   0xffe0 - 0x (0x20) MX[B](B)
> [3] -1  0   0x0010 - 0x3fff (0x3ff0) MX[B]E(B)
> [4] -1  0   0x000f - 0x000f (0x1) MX[B]
> [5] -1  0   0x000c - 0x000e (0x3) MX[B]
> [6] -1  0   0x - 0x0009 (0xa) MX[B]
> [7] -1  0   0xb020a400 - 0xb020a4ff (0x100) MX[B]
> [8] -1  0   0xb0209800 - 0xb02098ff (0x100) MX[B]
> [9] -1  0   0xb0209c00 - 0xb0209cff (0x100) MX[B]
> [10] -1 0   0xb020a000 - 0xb020a0ff (0x100) MX[B]
> [11] -1 0   0xb0206000 - 0xb0207fff (0x2000) MX[B]
> [12] -1 0   0xb020 - 0xb0203fff (0x4000) MX[B]
> [13] -1 0   0xb0209000 - 0xb02097ff (0x800) MX[B]
> [14] -1 0   0xb0204000 - 0xb0205fff (0x2000) MX[B]
> [15] -1 0   0xb0003800 - 0xb00038ff (0x100) MX[B]
> [16] -1 0   0xb0003400 - 0xb00034ff (0x100) MX[B]
> [17] -1 0   0xb0003000 - 0xb00033ff (0x400) MX[B]
> [18] -1 0   0xb0002000 - 0xb0002fff (0x1000) MX[B]
> [19] -1 0   0xb0001000 - 0xb0001fff (0x1000) MX[B]
> [20] -1 0   0xb000 - 0xbfff (0x1000) MX[B]
> [21] -1 0   0xb010 - 0xb010 (0x1) MX[B](B)
> [22] -1 0   0xc000 - 0xcfff (0x1000) MX[B](B)
> [23] 0  0   0x000a - 0x000a (0x1) MS[B]
> [24] 0  0   0x000b - 0x000b7fff (0x8000) MS[B]
> [25] 0  0   0x000b8000 - 0x000b (0x8000) MS[B]
> [26] 0  0   0x9000 - 0x90ff (0x100) IX[B]
> [27] -1 0   0x - 0x (0x1) IX[B]
> [28] -1 0   0x - 0x00ff (0x100) IX[B]
> [29] -1 0   0xa000 - 0xa0ff (0x100) IX[B]
> [30] -1 0   0x8410 - 0x841f (0x10) IX[B]
> [31] -1 0   0x8420 - 0x8420 (0x1) IX[B]
> [32] -1 0   0x8428 - 0x8428 (0x1) IX[B]
> [33] -1 0   0x8424 - 0x8424 (0x1) IX[B]
> [34] -1 0   0x8430 - 0x8430 (0x1) IX[B]
> [35] -1 0   0x8400 - 0x840f (0x10) IX[B]
> [36] -1 0   0x9000 - 0x90ff (0x100) IX[B](B)
> [37] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
> [38] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

Alex, I was able to get the latest and greatest of everything compiled and "limping".  X starts up, and then proceeds to consume 100% of the CPU. I have a good debugging environment, so I'll be able to walk through it with gdb to figure out exactly what's causing the problem. Once it gets in this state, I can't kill the X server, and gdb can't attach to it. 
According to oprofile, all of the CPU time is being spent in the kernel on the "delay_pmtmr" function. So it is appears as if we are in the kernel & waiting for something. (As an ASIDE, I spent a bunch of time tracing down a stupid kernel panic. If DRM_MEMORY_DEBUG is defined for the DRM module, drm_ioremap is completely broken... It will call itself, and eventually cause a panic.  )
Let us know how it goes!Alex
>  Cheers,> --Phil>>>After looking over the Xorg log files, I discovered differences in the mappings between the firegl & and the radeon drivers. I noticed the maps from both the FireGL driver and radeon driver were very similar. 
However, there were two differences.  First, the fglrx driver has an extra entry: [2] -1  0   0xffe0 - 0x (0x20) MX[B](B)Second, the radeon drivers looks like they have broken mappings. 
The MMIO range begins at: 0xb010. The last two mappings in the fglrx driver are within that range.  However, in the radeon driver, the are offset from 0, yet claim to be in I/O space. 
(II) resource ranges after probing:DRI broken:   [33] 0  0   0x03b0 - 0x03bb (0xc) IS[B]   [34] 0  0   0x03c0 - 0x03df (0x20) IS[B]...fglrx:   [34] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
   [35] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]1) What are these mappings used for? 2) Could this incorrect mapping explain the problems that I'm seeing? 3) What part of radeon probe would be responsible for adding these? 
Thanks,--PhilComplete map (Working FGRLX):(II) resource ranges after preInit:    [0] 0   0   0xb010 - 0xb010 (0x1) MX[B]    [1] 0   0   0xc000 - 0xcfff (0x1000) MX[B]
    [2] -1  0   0xffe0 - 0x (0x20) MX[B](B)    [3] -1  0   0x0010 - 0x3fff (0x3ff0) MX[B]E(B)    [4] -1  0   0x000f - 0x000f (0x1) MX[B]    [5] -1  0   0x000c - 0x000e (0x3) MX[B]
    [6] -1  0   0x - 0x0009 (0xa) MX[B]    [7] -1  0   0xb020a400 - 0xb020a4ff (0x100) MX[B]    [8] -1  0   0xb0209800 - 0xb02098ff (0x100) MX[B]    [9] -1  0   0xb0209c00 - 0xb0209cff (0x100) MX[B]
    [10] -1 0   0xb020a000 - 0xb020a0ff (0x100) MX[B]    [11] -1 0   0xb0206000 - 0xb0207fff (0x2000) MX[B]    [12] -1 0   0xb020 - 0xb0203fff (0x4000) MX[B]    [13] -1 0   0xb0209000 - 0xb02097ff (0x800) MX[B]
    [14] -1 0   0xb0204000 - 0xb0205fff (0x2000) MX[B]    [15] -1 0   0xb0003800 - 0xb00038ff (0x100) MX[B]    [16] -1 0   0xb0003400 - 0xb00034ff (0x100) MX[B]    [17] -1 0   0xb0003000 - 0xb00033ff (0x400) MX[B]
    [18] -1 0   0xb0002000 - 0xb0002fff (0x1000) MX[B]    [19] -1 0   0xb0001000 - 0xb0001fff (0x1000) MX[B]    [20] -1 0   0xb000 - 0xbfff (0x1000) MX[B]    [21] -1 0   0xb010 - 0xb010 (0x1) MX[B](B)
    [22] -1 0   0xc000 - 0xcfff (0x1000) MX[B](B)    [23] 0  0   0x000a - 0x000a (0x1) MS[B]    [24] 0  0   0x000b - 0x000b7fff (0x8000) MS[B]    [25] 0  0   0x000b8000 - 0x000b (0x8000) MS[B]
    [26] 0  0   0x9000 - 0x90ff (0x100) IX[B]    [27] -1 0   0x - 0x (0x1) IX[B]    [28] -1 0   0x - 0x00ff (0x100) IX[B]    [29] -1 0   0xa000 - 0xa0ff (0x100) IX[B]
    [30] -1 0   0x8410 - 0x841f (0x10) IX[B]    [31] -1 0   0x8420 - 0x8420 (0x1) IX[B]    [32] -1 0   0x8428 - 0x8428 (0x1) IX[B]    [33] -1 0   0x8424 - 0x8424 (0x1) IX[B]
    [34] -1 0   0x8430 - 0x8430 (0x1) IX[B]    [35] -1 0   0x8400 - 0x840f (0x10) IX[B]    [36] -1 0   0x9000 - 0x90ff (0x100) IX[B](B)    [37] 0  0   0xb01203b0 - 0xb01203bb (0xc) IS[B]
    [38] 0  0   0xb01203c0 - 0xb01203df (0x20) IS[B]Complete map (Broken DRI):(II) resource ranges after preInit:    [0] 0   0   0xb010 - 0xb010 (0x1) MX[B]    [1] 0   0   0xc000 - 0xcfff (0x1000) MX[B]
    [2] -1  0   0x0010 - 0x3fff (0x3ff0) MX[B]E(B)    [3] -1  0   0x000f - 0x000f (0x1) MX[B]    [4] -1  0   0x000c - 0x000e (0x3) MX[B]    [5] -1  0   0x - 0x0009 (0xa) MX[B]
    [6] -1  0   0xb020a400 - 0xb020a4ff (0x100) MX[B]    [7] -1  0   0xb0209800 - 0xb02098ff (0x100) MX[B]    [8] -1  0   0xb0209c00 - 0xb0209cff (0x

Re: ATI Radeon XPRESS 200M

[Alex Deucher]

On 10/23/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Alex,
>
> > 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.
>
> Ok.  Well, I might run into a problem later on using the BIOS settings, but
> I should be good for now.
>
> The latest and greatest ATI fglrx (8.29.6) drivers will just hang when using
> I use them on my laptop.  I emailed ATI about this, and they said that it is
> an HP problem. (Thanks, ATI.)
>
> However, I do have the an older version of the driver ( 8.24.X) which does
> work WITH DRI.  So, even if the support isn't perfect, if I can get the
> opensource drivers to work AT LEAST as well the 8.24.X drivers, I'll be very
> happy.
>
> >
> > 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.
>
> Ok.  I'm going to try to get the latest Xserver/Mesa/DRM thing built and
> running.  I'm probably be heads down a little bit trying to get all of the
> pieces compiled and running.  There's plenty of guides on the net, so I
> should be fine.
>
> (I've used jhbuild to check out X server, DRM, Mesa.  For some reason it
> didn't check out and build the ati driver.  The Xorg server also complains
> about some other missing modules. In any event, I'll figure it out, but
> it'll keep me busy.)

Let me know if you run into any problems.

>
> > 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.
>
> What's strange is that ALL of the indexes (0 to 0x3f) print out zeros.
> Maybe I'll just try to iterate through  the 0x18-0x2F range and see if
> anything is different.

It could also be that the XPRESS chips have a different memory
controller altogether (although this is somewhat doubtful).

>
> > As for the MC
> > INDEX reg, I don't know that it retains the index on read back.  I
> > wouldn't worry about that.
>
> Ok. cool.
>
> >
> > The memory controller handles all memory (FB and AGP/PCI/PCIE) related
> > activities on the radeon.  The GPU is basicaly a specialized mini CPU.
> > Different parts of the chip vie for access to memory (display
> > controllers, pixel pipelines, etc.). The MC configuration registers
> > allow you to tweak the controller (everything from latencies, timing,
> > cache control, DRAM driving strength, etc.  It's fairly complicated,
> > and I think is generally best left to the bios.  I'd be careful
> > changing the MC regs unless you are reasonably sure what you are
> > doing.  I take no responsibility for anyone who hoses their hardware.
>
> Ok.  You've scared me off. ;-)  I'll try to avoid screwing with it if
> possible.
>
> >
> > Give it a shot and see what happens.  I've heard reports of users
> > having success with the the DRI using fglrx and setting the FB size in
> > the bios to a reasonably large level.
>
> I do have DRI working w/fglrx, it is with an older driver ( 8.24), but I
> hope it is enough to figure out
> (Getting DRI to work was an effort in itself... New stuff (8.29.X) is
> broken, and the old stuff (8.24.X) needed to be hacked to work with my
> recent FC5 kernel.)
>
> FWIW, I set the local memory to 128M (That's also the amount of graphics
> memory I had.) to get it to work.  (I haven't tried other values yet..)
>
> > If you can get the DRI going
> > with fglrx, you might just want to dump the regular MMIO regs and we
> > can see if anything interesting jumps out at us.
>
>  I've already run radeon dump on the fglrx w/DRI configuration.  The results
> are attached.  (Both my Xorg.0.log file and the radeon dump itself. )
>
> Unfortunately, it doesn't appear to give nice register names w/values, but
> maybe the dump will be of some use to you.

FWIW, radeontool
(http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary)
will give you a nicer (though more limited) dump.

>
> > You might also want
> > to try some of the radeon command buffer dumpers from the old r300
> > project with fglrx.  I'm not sure anyone has looked at those since DRI
> > support for XPRESS chips was added to fglrx.  It would be alot easier
> > to n

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

Roland, On 10/23/06, Roland Scheidegger <[EMAIL PROTECTED]> wrote:
Alex Deucher wrote:> 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.
There is actually no code in the dri driver preventing loading it onxpress 200 igps, it will just output a warning. Apart from enabling itin ddx, you will need to add your chip id to the drm, however (an old
patch doing just that:https://bugs.freedesktop.org/attachment.cgi?id=4971 - it probably won'tapply, and you should add RADEON_NEW_MEMMAP too).
Ok.  Thanks this helps.  Before your note, I hacked DRI to add support for 0x5955, but I wasn't sure what the proper flags were for the rest of the settings. 
Roland--Phil
-
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

[Roland Scheidegger]

Alex Deucher wrote:
> 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.
There is actually no code in the dri driver preventing loading it on
xpress 200 igps, it will just output a warning. Apart from enabling it 
in ddx, you will need to add your chip id to the drm, however (an old 
patch doing just that: 
https://bugs.freedesktop.org/attachment.cgi?id=4971 - it probably won't 
apply, and you should add RADEON_NEW_MEMMAP too).

Roland

-
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 Deucher]

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

Re: ATI Radeon XPRESS 200M

[Phillip Ezolt]

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_

Re: ATI Radeon XPRESS 200M

[Alex Deucher]

On 10/18/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Hi All,
>I know that this topic has come up many times in the past, but here goes.
>  I'm one of the poor schleps with a XPRESS 200M in my Compaq laptop.  The
> open-source driver doesn't support it, and the latest fglrx driver just
> hangs upon X startup.

The open source driver supports modesetting and basic 2D accel.

>
> So... I want to try to fix this.  From the DRI mail threads/bug reports that
> I've read so far, it appears as if the memory controller is radically
> different than the other ATI cards.
>
> There was a post in early September (
> http://marc.theaimsgroup.com/?l=dri-devel&m=115713477422878&w=2
> ), describing how to support this with the opensource driver.
>
> 1) Get an ATI proprietary driver running on the machine. (DONE:  fglrx:
> 8.24.8 & FC5)
> 2) Dump MC registers/record initialization sequence (Working on it.)
> 3) Build a custom Xorg webserver with intialization matching the ATI
> proprietary driver (and will allow DRM to be installed)
> 4) Fixs bugs & goto 3
> 5) Profit.
>
> Questions
> 1) (I'm a complete Xorg/DRI/Mesa developer newbie.)
>
> What specific parts of the system have to be changed?  Is this a DRM driver
> issue? Is it something in Mesa? Is it something in the X.org server?  (Even
> better, which files should I look at? )  (radeon_display.c from
> xf86-video-ati/src looks promising.)

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.

>
> 2) What tools are best to dump the radeon register information?
>
> I've used radeon_dump to get things after I started up, but it only gives me
> the final state of the registers. I stumbled upon another dumper here:  "
> http://people.freedesktop.org/~glisse/";. (I think that this
> will track register initialization through-out the startup process).
>
> Are these the best tools to use?
>

Unfortunately, I don't know of any reg dumper that handles the MC
regs.  Some are directly accessed via MMIO, others are indexed and
accessed similarly to the radeon PLL regs (or vga regs if you are
familiar with vga).

Adding the direct access MC regs to radeontool should be pretty easy.
you'd basically just add new names and offsets.  Most of the MC regs
are prefixed with MC in their symbolic names.  some of them may
already be in radeon_reg.h in the radeon DDX.  I can help you fill in
any missing ones.

There may be some PCIE related regs that you will need to look at as
well, but unfortunately, I don't know much about those.

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.


> 3) Finally, where is the best place to discuss the ATI development/ask
> questions?

this list or the xorg list.

>
> Is there an overview of how radeons are laid out?  I've looks through some
> of the DRI documentation (
> http://dri.freedesktop.org/wiki/Documentation), but none
> seem to reference the radeon specifically.

what do you mean by "laid out"? :)

most of the configuration is done via MMIO and things like 2D and 3D
are done via the command processor which is basically a buffer you
feed commands to.

>
> NOTE: I don't know if this is typical of most graphics cards, but the
> "hyper-memory" on the XPress cards seems to be more than just a software
> manager.  According to (
> http://www.ati.com/technology/HyperMemory_Whitepaper.pdf),
> there is also a PCI express auxilary channel that can shuffle things back
> and forth from the VPU to memory.

As I understand it hypermemory is just a marketing term.  with the
exception of the IGP chips there is no difference between the regular
cards and the hypermemory cards.  They just put less vram on the cards
to keep costs down and then use pcie gart to use system memory same as
a non-hypermemory card.

Alex

>
> Cheers & Thanks,
> --Phil
>

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technol

ATI Radeon XPRESS 200M

[Phillip Ezolt]

Hi All,    I know that this topic has come up many times in the past, but here goes.  I'm one of the poor schleps with a XPRESS 200M in my Compaq laptop.  The open-source driver doesn't support it, and the latest fglrx driver just hangs upon X startup. 
So... I want to try to fix this.  From the DRI mail threads/bug reports that I've read so far, it appears as if the memory controller is radically different than the other ATI cards. There was a post in early September (
http://marc.theaimsgroup.com/?l=dri-devel&m=115713477422878&w=2
), describing how to support this with the opensource driver. 
1) Get an ATI proprietary driver running on the machine. (DONE:  fglrx: 8.24.8 & FC5)2) Dump MC registers/record initialization sequence (Working on it.)3) Build a custom Xorg webserver with intialization matching the ATI proprietary driver (and will allow DRM to be installed) 
4) Fixs bugs & goto 3 5) Profit.Questions1) (I'm a complete Xorg/DRI/Mesa developer newbie.) What specific parts of the system have to be changed?  Is this a DRM driver issue? Is it something in Mesa? Is it something in the 
X.org server?  (Even better, which files should I look at? )  (radeon_display.c from xf86-video-ati/src looks promising.)
2) What tools are best to dump the radeon register information? I've used radeon_dump to get things after I started up, but it only gives me the final state of the registers. I stumbled upon another dumper here:  "
http://people.freedesktop.org/~glisse/". (I think that this will track register initialization through-out the startup process).   
Are these the best tools to use? 3) Finally, where is the best place to discuss the ATI development/ask questions? Is there an overview of how radeons are laid out?  I've looks through some of the DRI documentation (
http://dri.freedesktop.org/wiki/Documentation), but none seem to reference the radeon specifically. NOTE: I don't know if this is typical of most graphics cards, but the "hyper-memory" on the XPress cards seems to be more than just a software manager.  According to (
http://www.ati.com/technology/HyperMemory_Whitepaper.pdf), there is also a PCI express auxilary channel that can shuffle things back and forth from the VPU to memory. 
Cheers & Thanks,--Phil

-
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