[Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
Hi, I've found something strange in reporting the chipset: I've got ATI R128 on VIA kt 266 chipset, Yet the driver writes: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB [drm] Initialized r128 2.1.6 20010405 on minor 0 the chipset IS kt266 goran@glaugrung:~\>> /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] I couldn't find why it doesnt report KT 266 how it should. any ideas? please cc: me, as I'm not on the list. Thanks. Goran ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
> I've found something strange in reporting the chipset: > > I've got ATI R128 on VIA kt 266 chipset, Yet the driver writes: > > [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB > [drm] Initialized r128 2.1.6 20010405 on minor 0 > > the chipset IS kt266 > goran@glaugrung:~\>> /sbin/lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266] > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] > > I couldn't find why it doesnt report KT 266 how it should. > any ideas? > please cc: me, as I'm not on the list. The two chipsets have the same PCI ID, as far as I know. Thus, AGPGART will think it's a KT133. This shouldn't be a problem in general. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
Martin 'Goran' Moravec wrote: > Hi, > I've found something strange in reporting the chipset: > > I've got ATI R128 on VIA kt 266 chipset, Yet the driver writes: > > [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe000 64MB > [drm] Initialized r128 2.1.6 20010405 on minor 0 > > the chipset IS kt266 > goran@glaugrung:~\>> /sbin/lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266] > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] > > I couldn't find why it doesnt report KT 266 how it should. > any ideas? > please cc: me, as I'm not on the list. > > Thanks. > Goran > Hello Which kernel version are you using ? Can you also send the output of 'lspci -nv' s.t. one can see whether your chipset is correctly detected ? a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
Gareth Hughes wrote: > > The two chipsets have the same PCI ID, as far as I know. Thus, AGPGART > will think it's a KT133. This shouldn't be a problem in general. > I would be quite surprised if the two chipsets had the same PCI id (have a look at the pci.ids in the linux kernel)... they should only share the same vendor id, which makes the agpgart code work properly (I think Via is less silly than Intel that has the nasty habit of changing the adresses of AGP registers throughout their chipset releases) a+ -- Nicolas Aspert Signal Processing Laboratory (LTS) Swiss Federal Institute of Technology (EPFL) Office: ELE 237 Phone: +41 - 21 - 693 36 32 (LTS Office) Fax: +41 - 21 - 693 76 00 Web: http://ltswww.epfl.ch/~aspert ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
> > Hello > > Which kernel version are you using ? Can you also send the output of > 'lspci -nv' s.t. one can see whether your chipset is correctly detected ? > kernel 2.4.17 - no patches glaugrung:/home/goran# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] 00:05.0 Ethernet controller: 3Com Corporation 3c900B-Combo [Etherlink XL Combo] (rev 04) 00:08.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 18) 00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 18) 00:11.4 USB Controller: VIA Technologies, Inc. UHCI USB (rev 18) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RL glaugrung:/home/goran# lspci -nv 00:00.0 Class 0600: 1106:3099 Flags: bus master, medium devsel, latency 8 Memory at e000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 Class 0604: 1106:b099 Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-afff Memory behind bridge: dfe0-dfef Prefetchable memory behind bridge: d7c0-dfcf Capabilities: [80] Power Management version 2 00:05.0 Class 0200: 10b7:9005 (rev 04) Subsystem: 10b7:9005 Flags: bus master, medium devsel, latency 64, IRQ 11 I/O ports at d800 [size=128] Memory at df80 (32-bit, non-prefetchable) [size=128] Expansion ROM at dffc [disabled] [size=128K] Capabilities: [dc] Power Management version 1 00:08.0 Class 0401: 1274:5880 (rev 02) Subsystem: 1274:2000 Flags: bus master, slow devsel, latency 64, IRQ 10 I/O ports at d400 [size=64] Capabilities: [dc] Power Management version 1 00:11.0 Class 0601: 1106:3074 Subsystem: 1106:3074 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00:11.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: 1106:0571 Flags: bus master, medium devsel, latency 32 I/O ports at ff00 [size=16] Capabilities: [c0] Power Management version 2 00:11.2 Class 0c03: 1106:3038 (rev 18) Subsystem: 0925:1234 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 00:11.3 Class 0c03: 1106:3038 (rev 18) Subsystem: 0925:1234 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 00:11.4 Class 0c03: 1106:3038 (rev 18) Subsystem: 0925:1234 Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 01:00.0 Class 0300: 1002:524c Subsystem: 1002:0088 Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 11 Memory at d800 (32-bit, prefetchable) [size=64M] I/O ports at a800 [size=256] Memory at dfefc000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at dfec [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 1 -- Martin 'Goran' Moravec , |\/| , Owner of www.komik.cz, root at xercom.cz and / \(oo)/ \ egeria.cz. Netadmin and bofh at ipp.cas.cz. //''\\ Web: www.ucw.cz/~goran Email: [EMAIL PROTECTED] //\ /\\ phone: 0604-123-564\/\/`\ \/ /`\/\/ ^^--^^ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
> I would be quite surprised if the two chipsets had the same PCI id (have > a look at the pci.ids in the linux kernel)... they should only share the > same vendor id, which makes the agpgart code work properly (I think Via > is less silly than Intel that has the nasty habit of changing the > adresses of AGP registers throughout their chipset releases) Perhaps it was different revisions of the same chipset. I'm not sure of the exact details, however I do remember someone complaining about this fact. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [goran@ucw.cz: drm_agpsupport.h]
>
> Perhaps it was different revisions of the same chipset. I'm not sure
> of the exact details, however I do remember someone complaining about
> this fact.
>
Anyway, there is a correct entry for the chipset in agpgart_be.c :
{ PCI_DEVICE_ID_VIA_8367_0,
PCI_VENDOR_ID_VIA,
VIA_APOLLO_KT133,
"Via",
"Apollo Pro KT266",
via_generic_setup },
Martin, if you look in /var/log/message right after loading the agp
module, you should see sthg like "Detected Via Apollo Pro KT266"
The drm reports a KT133 stuff because the agp bridge is declared as
VIA_APOLLO_KT133.
(in drm_agpsupport.h : case VIA_APOLLO_KT133: head->chipset = "VIA Apollo KT133";)
So anything should go smoothly (since all the via chipsets share the
same init. routine in the agp backend), even if the drm reports a KT133
bridge...
a+
--
Nicolas Aspert Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM/DRI porting guide?
greetings; i am interested in writing the bits required to get dri working on the SiS 630E (which evidently contains an SiS300 and SiS 301, among other things) on FreeBSD. It's my understanding that this chipset is supported under Linux, but i havent poked around in the tree yet. is there such a thing as a porting guide? i have glanced at docs ref'd at http://dri.sourceforge.net/doc/DRIintro.html the docs are kinda old. and the one that seems most pertinent: DRICompile.html, is an invalid link. now, i understand the basics: 1. Kernel Support 2. Make drm aware of the kernel support. shoulnd't this be all? isnt it independent after that? that's what the drm is for? so, if there is a hardware porting guide beyond "Use The Source Luke!" i'd love to take advantage of it. is there a porting harness? ie, a stub that i can use to poke at the kernel support so that i can make sure that it does what it's supposed to? if the answer to both is no, cool. just let me know so that i done waste time googling for something that doesnt exist ( ie: OpenGL "porting guide" gives me lotsa links about how to move your apps from 'ClosedGL' to OpenGL but i obviously am interested in the other end of the pipeline! ) tnx! johnu -- John L. Utz III [EMAIL PROTECTED] Idiocy is the Impulse Function in the Convolution of Life ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
