Stephan von Krawczynski wrote:
>On Sun, 25 Nov 2001 15:09:13 +0100
>Didier Moens <[email protected]> wrote:
>
>>Dear,
>>
>>Stephan von Krawczynski wrote:
>>
>>>
>>>Hello Marcelo,
>>>
>>>I tried to find the current maintainer of agpgart module, but couldn't
>>>find any in the MAINTAINERS list. Who is it?
>>>I obviously could fix the oops, but I would need some input on how
>>>I830M chipset looks like on a working config to further investigate
>>>Didiers problem.
>>>Any hints?
>>>
>>>Regards,
>>>Stephan
>>>
>>>
>>Anything I can do to help out ?
>>
>
>Hm, well if you can get your hands on another box with i830, another lspci
>output would be of interest.
>
Examining the code :
if (i810_dev == NULL) {
printk(KERN_ERR PFX "agpgart: Detected an "
"Intel i815, but could not find the"
" secondary device. Assuming a "
"non-integrated video card.\n");
break;
This leads me to believe the "secondary device" could be the integrated
graphics component on the i810/815.
As the i830M doesn't have one (the i830MG does), I suppose this could
lead to the aforementioned error message, and hence failure of the
agpgart modprobe ?
Could it be that one has to differentiate between i830MG (secondary
device, and hence analoguous to i810/i815) and i830M (no secondary
device, and possibly analoguous to i830/i840/i845/... : no check for 2nd
device needed ) ?
Offcourse, I could be utterly wrong.
Regards,
Didier
> if (i810_dev == NULL) {
> printk(KERN_ERR PFX "agpgart: Detected an "
> "Intel i815, but could not find the"
> " secondary device. Assuming a "
> "non-integrated video card.\n");
> break;
>
>
> This leads me to believe the "secondary device" could be the integrated
> graphics component on the i810/815.
>
> As the i830M doesn't have one (the i830MG does), I suppose this could
> lead to the aforementioned error message, and hence failure of the
> agpgart modprobe ?
>
> Could it be that one has to differentiate between i830MG (secondary
> device, and hence analoguous to i810/i815) and i830M (no secondary
> device, and possibly analoguous to i830/i840/i845/... : no check for 2nd
> device needed ) ?
>
>
> Offcourse, I could be utterly wrong.
>
Hello
It seems like you have pointed out the problem... From what you had sent
previously (the output of 'lspci' on your machine), and what the Intel
doc says, it looks to me like the code for i830 initialization is not
correct for your version of the chipset. But I am not too sure of what
is to be done in that case... should we switch back to a 'classic' AGP
initialization, similar to the other i8xx chipsets (820/840/860...) ?
Robert (or somebody else), any clue about this one ?
I'll try to figure out where the 'i830_configure' performs call on the
secondary device...
Best regards
--
Nicolas Aspert Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)
On Mon, 2001-11-26 at 06:47, Nicolas Aspert wrote:
> It seems like you have pointed out the problem... From what you had sent
> previously (the output of 'lspci' on your machine), and what the Intel
> doc says, it looks to me like the code for i830 initialization is not
> correct for your version of the chipset. But I am not too sure of what
> is to be done in that case... should we switch back to a 'classic' AGP
> initialization, similar to the other i8xx chipsets (820/840/860...) ?
> Robert (or somebody else), any clue about this one ?
It looks like you got it right ... at any rate, you know as much as me
about a chipset neither of us have (ie, we have docs), so its all a
guess.
Has the user tried your patch? Results?
Robert Love
Dear Robert, Nicolas, Stephan, :)
Robert Love wrote:
> On Mon, 2001-11-26 at 06:47, Nicolas Aspert wrote:
>
>
>>It seems like you have pointed out the problem... From what you had sent
>>previously (the output of 'lspci' on your machine), and what the Intel
>>doc says, it looks to me like the code for i830 initialization is not
>>correct for your version of the chipset. But I am not too sure of what
>>is to be done in that case... should we switch back to a 'classic' AGP
>>initialization, similar to the other i8xx chipsets (820/840/860...) ?
>>Robert (or somebody else), any clue about this one ?
>>
>
> It looks like you got it right ... at any rate, you know as much as me
> about a chipset neither of us have (ie, we have docs), so its all a
> guess.
>
> Has the user tried your patch? Results?
I got two patches :
1. From Stephan, to test whether my assumption about the secondary
device was right :
Stephan wrote :
But if you want you can check that out pretty simple: just add a "break"
right
after the case :
case PCI_DEVICE_ID_INTEL_830_M_0:
---> break;
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
This patch left me with a loaded agpgart, and accelerated X (DRM/DRI).
The acceleration is still not up to par with an ATI Mobility-128 (30%
lower, while it should be at least 200% faster), but I suspect an X
CVS-problem here.
Quitting and restarting X leaves me with a locked black screen.
2. And the one from Nicolas, in which I changed all references from
830MG to 830M.
Results :
1a. Nicolas' patches yielded an oops, which was corrected by
implementing Stephan's first patch :
+ if(i810_dev && ( PCI_FUNC(i810_dev->devfn) != 0) ) {
- if(PCI_FUNC(i810_dev->devfn) != 0) {
1b. After Stephan's firsat patch, Nicolas' code loaded the agpgart, but
left me with a messed-up X (XFree86 CVS 4.1.99.1 2001/11/26) : only a
cursor, locked black screen, restart to ssh session.
(I need the CVS-version of X : standard 4.1.0 doesn't detect the LCD
panel size, and bugs out).
Conclusion : Stephan's break-patch loads agpgart, loads X, and locks
when reloading X ; Nicolas' patch (when combined with Stephan's first
patch) loads agpgart and locks X hard.
FYI : Dell has an i830M-design (the new i8100, together with a NVidia
Mobile), and Gateway, Compaq, ... should have them too, I guess.
The requested "lspci -vn" :
00:00.0 Class 0600: 8086:3575 (rev 02)
Subsystem: 1014:021d
Flags: bus master, fast devsel, latency 0
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Capabilities: [40] #09 [0105]
Capabilities: [a0] AGP version 2.0
00:01.0 Class 0604: 8086:3576 (rev 02)
Flags: bus master, 66Mhz, fast devsel, latency 96
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00003000-00003fff
Memory behind bridge: c0100000-c01fffff
Prefetchable memory behind bridge: e0000000-e7ffffff
00:1d.0 Class 0c03: 8086:2482 (rev 01)
Subsystem: 1014:0220
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1800 [size=32]
00:1d.1 Class 0c03: 8086:2484 (rev 01)
Subsystem: 1014:0220
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1820 [size=32]
00:1d.2 Class 0c03: 8086:2487 (rev 01)
Subsystem: 1014:0220
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1840 [size=32]
00:1e.0 Class 0604: 8086:2448 (rev 41)
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=08, sec-latency=64
I/O behind bridge: 00004000-00008fff
Memory behind bridge: c0200000-cfffffff
Prefetchable memory behind bridge: e8000000-f00fffff
00:1f.0 Class 0601: 8086:248c (rev 01)
Flags: bus master, medium devsel, latency 0
00:1f.1 Class 0101: 8086:248a (rev 01) (prog-if 8a [Master SecP PriP])
Subsystem: 1014:0220
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 01f0 [size=8]
I/O ports at 03f4
I/O ports at 0170 [size=8]
I/O ports at 0374
I/O ports at 1860 [size=16]
Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
00:1f.3 Class 0c05: 8086:2483 (rev 01)
Subsystem: 1014:0220
Flags: medium devsel, IRQ 11
I/O ports at 1880 [size=32]
00:1f.5 Class 0401: 8086:2485 (rev 01)
Subsystem: 1014:0222
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1c00 [size=256]
I/O ports at 18c0 [size=64]
00:1f.6 Class 0703: 8086:2486 (rev 01)
Subsystem: 1014:0227
Flags: medium devsel, IRQ 11
I/O ports at 2400 [size=256]
I/O ports at 2000 [size=128]
01:00.0 Class 0300: 1002:4c59
Subsystem: 1014:0235
Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel,
latency 66, IRQ 11
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at 3000 [size=256]
Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
02:00.0 Class 0607: 1180:0478 (rev a0)
Subsystem: 1014:0184
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at c0202000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=05, sec-latency=176
Memory window 0: e8000000-e83ff000 (prefetchable)
Memory window 1: c0400000-c07ff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
02:00.1 Class 0607: 1180:0478 (rev a0)
Subsystem: 1014:0184
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at c0203000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=06, subordinate=08, sec-latency=176
Memory window 0: e8400000-e87ff000 (prefetchable)
Memory window 1: c0800000-c0bff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
16-bit legacy interface ports at 0001
02:00.2 Class 0c00: 1180:0522 (prog-if 10)
Subsystem: 1014:01cf
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at c0201000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
02:02.0 Class 0280: 1260:3873 (rev 01)
Subsystem: 1668:0406
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
02:08.0 Class 0200: 8086:1031 (rev 41)
Subsystem: 1014:0209
Flags: bus master, medium devsel, latency 66, IRQ 11
Memory at c0200000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 8000 [size=64]
Capabilities: [dc] Power Management version 2
-[00]-+-00.0 8086:3575
+-01.0-[01]----00.0 1002:4c59
+-1d.0 8086:2482
+-1d.1 8086:2484
+-1d.2 8086:2487
+-1e.0-[02-08]--+-00.0 1180:0478
| +-00.1 1180:0478
| +-00.2 1180:0522
| +-02.0 1260:3873
| \-08.0 8086:1031
+-1f.0 8086:248c
+-1f.1 8086:248a
+-1f.3 8086:2483
+-1f.5 8086:2485
\-1f.6 8086:2486
Kind regards,
Didier
Didier Moens
-----
RUG/VIB - Dept. Molecular Biology - Core IT
tel ++32(9)2645309 fax ++32(9)2645348
http://www.dmb.rug.ac.be
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/time.h>
#include <linux/types.h>
#include <linux/agpgart.h>
#include <asm/mtrr.h>
#include <errno.h>
unsigned char *gart;
int gartfd;
int mtrr;
int usec( void ) {
struct timeval tv;
struct timezone tz;
gettimeofday( &tv, &tz );
return (tv.tv_sec & 2047) * 1000000 + tv.tv_usec;
}
int MemoryBenchmark( void *buffer, int dwords ) {
int i;
int start, end;
int mb;
int *base;
base = (int *)buffer;
start = usec();
for ( i = 0 ; i < dwords ; i += 8 ) {
base[i] =
base[i+1] =
base[i+2] =
base[i+3] =
base[i+4] =
base[i+5] =
base[i+6] =
base[i+7] = 0x15151515; /* dmapad nops */
}
end = usec();
mb = ( (float)dwords / 0x40000 ) * 1000000 / (end - start);
printf("MemoryBenchmark: %i mb/s\n", mb );
return mb;
}
int insert_gart(int page, int size)
{
agp_allocate entry;
agp_bind bind;
entry.type = 0;
entry.pg_count = size;
#ifdef DEBUG
printf("Using AGPIOC_ALLOCATE\n");
#endif
if(ioctl(gartfd, AGPIOC_ALLOCATE, &entry) != 0)
{
perror("ioctl(AGPIOC_ALLOCATE)");
exit(1);
}
bind.key = entry.key;
bind.pg_start = page;
#ifdef DEBUG
printf("Using AGPIOC_BIND\n");
#endif
if(ioctl(gartfd, AGPIOC_BIND, &bind))
{
perror("ioctl(AGPIOC_BIND)");
exit(1);
}
printf("entry.key : %i\n", entry.key);
return(entry.key);
}
int unbind_gart(int key)
{
agp_unbind unbind;
unbind.key = key;
#ifdef DEBUG
printf("Using AGPIOC_UNBIND\n");
#endif
if(ioctl(gartfd, AGPIOC_UNBIND, &unbind) != 0)
{
perror("ioctl(AGPIOC_UNBIND)");
exit(1);
}
return(0);
}
int bind_gart(int key, int page)
{
agp_bind bind;
bind.key = key;
bind.pg_start = page;
#ifdef DEBUG
printf("Using AGPIOC_BIND\n");
#endif
if(ioctl(gartfd, AGPIOC_BIND, &bind) != 0)
{
perror("ioctl(AGPIOC_BIND)");
exit(1);
}
return(0);
}
int remove_gart(int key)
{
#ifdef DEBUG
printf("Using AGPIOC_DEALLOCATE\n");
#endif
if(ioctl(gartfd, AGPIOC_DEALLOCATE, key) != 0)
{
perror("ioctl(GARTIOCREMOVE)");
exit(1);
}
return(0);
}
void openmtrr(void)
{
if ((mtrr = open("/proc/mtrr", O_WRONLY, 0)) == -1)
{
if (errno == ENOENT) {
perror("/proc/mtrr not found: MTRR not enabled\n");
} else {
perror("Error opening /proc/mtrr:");
perror("MTRR not enabled\n");
exit(1);
}
return;
}
}
int CoverRangeWithMTRR( int base, int range, int type )
{
int count;
/* set it if we aren't just checking the number */
if ( type != -1 ) {
struct mtrr_sentry sentry;
sentry.base = base;
sentry.size = range;
sentry.type = type;
if ( ioctl(mtrr, MTRRIOC_ADD_ENTRY, &sentry) == -1 ) {
perror("mtrr");
exit(1);
}
}
}
int init_agp(void)
{
agp_info info;
agp_setup setup;
#ifdef DEBUG
printf("Using AGPIOC_ACQUIRE\n");
#endif
if(ioctl(gartfd, AGPIOC_ACQUIRE) != 0)
{
perror("ioctl(AGPIOC_ACQUIRE)");
exit(1);
}
#ifdef DEBUG
printf("Using AGPIOC_INFO\n");
#endif
if(ioctl(gartfd, AGPIOC_INFO, &info) != 0)
{
perror("ioctl(AGPIOC_INFO)");
exit(1);
}
printf("version: %i.%i\n", info.version.major, info.version.minor);
printf("bridge id: 0x%lx\n", info.bridge_id);
printf("agp_mode: 0x%lx\n", info.agp_mode);
printf("aper_base: 0x%lx\n", info.aper_base);
printf("aper_size: %i\n", info.aper_size);
printf("pg_total: %i\n", info.pg_total);
printf("pg_system: %i\n", info.pg_system);
printf("pg_used: %i\n", info.pg_used);
openmtrr();
if (mtrr != -1) {
CoverRangeWithMTRR(info.aper_base, info.aper_size * 0x100000,
MTRR_TYPE_WRCOMB);
}
gart = mmap(NULL, info.aper_size * 0x100000, PROT_READ | PROT_WRITE, MAP_SHARED, gartfd, 0);
if(gart == (unsigned char *) 0xffffffff)
{
perror("mmap");
close(gartfd);
exit(1);
}
setup.agp_mode = info.agp_mode;
#ifdef DEBUG
printf("Using AGPIOC_SETUP\n");
#endif
if(ioctl(gartfd, AGPIOC_SETUP, &setup) != 0)
{
perror("ioctl(AGPIOC_SETUP)");
exit(1);
}
return(0);
}
int xchangeDummy;
void FlushWriteCombining( void ) {
__asm__ volatile( " push %%eax ; xchg %%eax, %0 ; pop %%eax" : : "m" (xchangeDummy));
__asm__ volatile( " push %%eax ; push %%ebx ; push %%ecx ; push %%edx ; movl $0,%%eax ; cpuid ; pop %%edx ; pop %%ecx ; pop %%ebx ; pop %%eax" : /* no outputs */ : /* no inputs */ );
}
void BenchMark()
{
int i, worked = 1;
i = MemoryBenchmark(gart, (1024 * 1024 * 4) / 4) +
MemoryBenchmark(gart, (1024 * 1024 * 4) / 4) +
MemoryBenchmark(gart, (1024 * 1024 * 4) / 4);
printf("Average speed: %i mb/s\n", i /3);
printf("Testing data integrity (1st pass): ");
fflush(stdout);
FlushWriteCombining();
for (i=0; i < 8 * 0x100000; i++)
{
gart[i] = i % 256;
}
FlushWriteCombining();
for (i=0; i < 8 * 0x100000; i++)
{
if(!(gart[i] == i % 256))
{
#ifdef DEBUG
printf("failed on %i, gart[i] = %i\n", i, gart[i]);
#endif
worked = 0;
}
}
if (!worked)
printf("failed on first pass!\n");
else
printf("passed on first pass.\n");
unbind_gart(0);
unbind_gart(1);
bind_gart(0, 0);
bind_gart(1, 1024);
worked = 1;
printf("Testing data integrity (2nd pass): ");
fflush(stdout);
for (i=0; i < 8 * 0x100000; i++)
{
if(!(gart[i] == i % 256))
{
#ifdef DEBUG
printf("failed on %i, gart[i] = %i\n", i, gart[i]);
#endif
worked = 0;
}
}
if (!worked)
printf("failed on second pass!\n");
else
printf("passed on second pass.\n");
}
int main()
{
int i;
int key;
int key2;
agp_info info;
gartfd = open("/dev/agpgart", O_RDWR);
if (gartfd == -1)
{
perror("open");
exit(1);
}
init_agp();
key = insert_gart(0, 1024);
key2 = insert_gart(1024, 1024);
#ifdef DEBUG
printf("Using AGPIOC_INFO\n");
if(ioctl(gartfd, AGPIOC_INFO, &info) != 0)
{
perror("ioctl(AGPIOC_INFO)");
exit(1);
}
printf("version: %i.%i\n", info.version.major, info.version.minor);
printf("bridge id: 0x%lx\n", info.bridge_id);
printf("agp_mode: 0x%lx\n", info.agp_mode);
printf("aper_base: 0x%lx\n", info.aper_base);
printf("aper_size: %i\n", info.aper_size);
printf("pg_total: %i\n", info.pg_total);
printf("pg_system: %i\n", info.pg_system);
printf("pg_used: %i\n", info.pg_used);
#endif
printf("Allocated 8 megs of GART memory\n");
BenchMark();
remove_gart(key);
remove_gart(key2);
#ifdef DEBUG
printf("Using AGPIOC_RELEASE\n");
#endif
if(ioctl(gartfd, AGPIOC_RELEASE) != 0)
{
perror("ioctl(AGPIOC_RELEASE)");
exit(1);
}
close(gartfd);
}
Hi Didier!
I misunderstood. I thought you have an on-board 830M video card :P
So you have an 830M motherboard, with a Radeon display card?
> >
> >
> > VideoRam "65536"
> >
>
> Are you sure about this ? I only have 32 MB.
As I said, I misunderstood. I thought you were using the i810 display driver
and I wanted to see what happens if you force the GART module to allocate
some additional system memory.
> Should this be tested with both patches ? I'm getting several
> suggestions about this problem : the possible permutations are
> augmenting, and I have some work to do too ... :)
If you have a Radeon display card and an 830M motherboard chipset, it might
be that the agpgart module is trying to use the 830M display chipset code.
that would definitely cause problems.
Before applying any patches, make sure that you have selected the following
[*] Intel 440LX/BX/GX and I815/I830M/I840/I850 support
(i.e. CONFIG_AGP_INTEL=y)
when compiling the kernel, but NOT!!!!! the following:
[ ] Intel I810/I815/I830M (on-board) support
(i.e. CONFIG_AGP_I810=n)
If the agpgart module then crashes when you load it, there is a bug and you
should send me/kernel mailinglist the oops.
As for display problems, you should ask on the dri-devel mailinglist which
is the proper place to post display driver bugs. (If it we're the i810
display driver I could help you)
--
Regards
Abraham
Don't drink when you drive -- you might hit a bump and spill it.
__________________________________________________________
Abraham vd Merwe - 2d3D, Inc.
Device Driver Development, Outsourcing, Embedded Systems
Cell: +27 82 565 4451 Snailmail:
Tel: +27 21 761 7549 Block C, Antree Park
Fax: +27 21 761 7648 Doncaster Road
Email: [email protected] Kenilworth, 7700
Http: http://www.2d3d.com South Africa
Abraham vd Merwe wrote:
> Hi Didier!
>
> I misunderstood. I thought you have an on-board 830M video card :P
>
> So you have an 830M motherboard, with a Radeon display card?
Seems like I'm having some egg on my face here. Argh !
According to http://developer.intel.com/design/chipsets/mobile/830.htm :
830MP : supports external AGP2X/4X graphics
830M : includes Intel's next generation performance oriented integrated
graphics controller, featuring Intel? Graphics Technology, as well as
external AGP2X/4X graphics support
830MG : supports value oriented integrated graphics for value priced
notebook segments
To sum up : this is an IBM A30p, with an "external" Radeon Mobility LY
(32 MB), and an 830MP instead of an 830M. The 830MP is common for both
IBM A30 and A30p models.
Sorry about wasting your time this way : I should get my facts straight
in the first place. I did have oopses, though. ;)
No mention of the 830MP in the kernel sources ; patches are welcome. :)
> If you have a Radeon display card and an 830M motherboard chipset, it might
> be that the agpgart module is trying to use the 830M display chipset code.
> that would definitely cause problems.
Regards,
Didier
diff -Nru linux-2.4.16.clean/drivers/char/agp/agp.h linux-2.4.16.dirty/drivers/char/agp/agp.h
--- linux-2.4.16.clean/drivers/char/agp/agp.h Fri Nov 9 23:01:21 2001
+++ linux-2.4.16.dirty/drivers/char/agp/agp.h Mon Nov 26 13:25:56 2001
@@ -276,6 +276,8 @@
#define I830_RDRAM_ND(x) (((x) & 0x20) >> 5)
#define I830_RDRAM_DDT(x) (((x) & 0x18) >> 3)
+#define INTEL_I830_ERRSTS 0x92
+
/* intel i820 registers */
#define INTEL_I820_RDCR 0x51
#define INTEL_I820_ERRSTS 0xc8
diff -Nru linux-2.4.16.clean/drivers/char/agp/agpgart_be.c linux-2.4.16.dirty/drivers/char/agp/agpgart_be.c
--- linux-2.4.16.clean/drivers/char/agp/agpgart_be.c Fri Nov 16 19:11:22 2001
+++ linux-2.4.16.dirty/drivers/char/agp/agpgart_be.c Tue Nov 27 11:00:39 2001
@@ -1705,6 +1705,38 @@
return 0;
}
+static int intel_830mp_configure(void)
+{
+ u32 temp;
+ u16 temp2;
+ aper_size_info_8 *current_size;
+
+ current_size = A_SIZE_8(agp_bridge.current_size);
+
+ /* aperture size */
+ pci_write_config_byte(agp_bridge.dev, INTEL_APSIZE,
+ current_size->size_value);
+
+ /* address to map to */
+ pci_read_config_dword(agp_bridge.dev, INTEL_APBASE, &temp);
+ agp_bridge.gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
+
+ /* attbase - aperture base */
+ pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
+ agp_bridge.gatt_bus_addr);
+
+ /* agpctrl */
+ pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000);
+
+ /* gmch */
+ pci_read_config_word(agp_bridge.dev, INTEL_NBXCFG, &temp2);
+ pci_write_config_word(agp_bridge.dev, INTEL_NBXCFG,
+ temp2 | (1 << 9));
+ /* clear any possible AGP-related error conditions */
+ pci_write_config_word(agp_bridge.dev, INTEL_I830_ERRSTS, 0x1c);
+ return 0;
+}
+
static unsigned long intel_mask_memory(unsigned long addr, int type)
{
/* Memory type is ignored */
@@ -1745,6 +1777,14 @@
{4, 1024, 0, 63}
};
+static aper_size_info_8 intel_830mp_sizes[4] =
+{
+ {256, 65536, 6, 0},
+ {128, 32768, 5, 32},
+ {64, 16384, 4, 48},
+ {32, 8192, 3, 56}
+};
+
static int __init intel_generic_setup (struct pci_dev *pdev)
{
agp_bridge.masks = intel_generic_masks;
@@ -1809,6 +1849,35 @@
(void) pdev; /* unused */
}
+static int __init intel_830mp_setup (struct pci_dev *pdev)
+{
+ agp_bridge.masks = intel_generic_masks;
+ agp_bridge.num_of_masks = 1;
+ agp_bridge.aperture_sizes = (void *) intel_830mp_sizes;
+ agp_bridge.size_type = U8_APER_SIZE;
+ agp_bridge.num_aperture_sizes = 4;
+ agp_bridge.dev_private_data = NULL;
+ agp_bridge.needs_scratch_page = FALSE;
+ agp_bridge.configure = intel_830mp_configure;
+ agp_bridge.fetch_size = intel_8xx_fetch_size;
+ agp_bridge.cleanup = intel_8xx_cleanup;
+ agp_bridge.tlb_flush = intel_8xx_tlbflush;
+ agp_bridge.mask_memory = intel_mask_memory;
+ agp_bridge.agp_enable = agp_generic_agp_enable;
+ agp_bridge.cache_flush = global_cache_flush;
+ agp_bridge.create_gatt_table = agp_generic_create_gatt_table;
+ agp_bridge.free_gatt_table = agp_generic_free_gatt_table;
+ agp_bridge.insert_memory = agp_generic_insert_memory;
+ agp_bridge.remove_memory = agp_generic_remove_memory;
+ agp_bridge.alloc_by_type = agp_generic_alloc_by_type;
+ agp_bridge.free_by_type = agp_generic_free_by_type;
+ agp_bridge.agp_alloc_page = agp_generic_alloc_page;
+ agp_bridge.agp_destroy_page = agp_generic_destroy_page;
+
+ return 0;
+
+ (void) pdev; /* unused */
+}
static int __init intel_840_setup (struct pci_dev *pdev)
{
@@ -3557,7 +3626,7 @@
INTEL_I830_M,
"Intel",
"i830M",
- intel_generic_setup },
+ intel_830mp_setup },
{ PCI_DEVICE_ID_INTEL_840_0,
PCI_VENDOR_ID_INTEL,
INTEL_I840,
@@ -3879,18 +3948,20 @@
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
NULL);
- if(PCI_FUNC(i810_dev->devfn) != 0) {
+ if(i810_dev && PCI_FUNC(i810_dev->devfn) != 0) {
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
i810_dev);
}
if (i810_dev == NULL) {
- printk(KERN_ERR PFX "Detected an "
+ printk(KERN_INFO PFX "Detected an "
"Intel 830M, but could not find the"
- " secondary device.\n");
- agp_bridge.type = NOT_SUPPORTED;
- return -ENODEV;
+ " secondary device.\n");
+ printk(KERN_INFO PFX "Trying the "
+ "Intel 830MP stuff\n");
+ agp_bridge.type = INTEL_I830_M;
+ break;
}
printk(KERN_INFO PFX "Detected an Intel "
"830M Chipset.\n");
Nicolas Aspert wrote:
>
>>
>>
>> To sum up : this is an IBM A30p, with an "external" Radeon Mobility LY
>> (32 MB), and an 830MP instead of an 830M. The 830MP is common for both
>> IBM A30 and A30p models.
>>
>>
>
> OK ! so you _do_ have an external graphic card (that's what looked
> unclear to me),
> for which AGP should work in the same way it does for other Intel
> chipsets...
>
> So why not trying the little patch I attach below, which should make
> your stuff work, without breaking too much the i830 support for on-board
> adapters... The patch is for 2.4.16, but is likely to be applied easily
> on another recent kernel. Keep me informed...
1. modprobe agpgart loads OK :
Nov 27 11:34:47 localhost kernel: Linux agpgart interface v0.99 (c) Jeff
Hartmann
Nov 27 11:34:47 localhost kernel: agpgart: Maximum main memory to use
for agp memory: 439M
Nov 27 11:34:47 localhost kernel: agpgart: Detected an Intel 830M, but
could not find the secondary device.
Nov 27 11:34:47 localhost kernel: agpgart: Trying the Intel 830MP stuff
Nov 27 11:34:47 localhost kernel: agpgart: Detected Intel i830M chipset
Nov 27 11:34:47 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000
[root@localhost agp]# /home/didier/repository/kernel/testgart
version: 0.99
bridge id: 0x35758086
agp_mode: 0x1f000217
aper_base: 0xd0000000
aper_size: 256
pg_total: 112384
pg_system: 112384
pg_used: 0
entry.key : 0
entry.key : 1
Allocated 8 megs of GART memory
MemoryBenchmark: 858 mb/s
MemoryBenchmark: 876 mb/s
MemoryBenchmark: 890 mb/s
Average speed: 874 mb/s
Testing data integrity (1st pass): passed on first pass.
Testing data integrity (2nd pass): passed on second pass.
2. compared to Stephan's original patches ("if i830m_dev ..." and
"break;") :
Nov 27 11:37:07 localhost kernel: Linux agpgart interface v0.99 (c) Jeff
Hartmann
Nov 27 11:37:07 localhost kernel: agpgart: Maximum main memory to use
for agp memory: 439M
Nov 27 11:37:07 localhost kernel: agpgart: Detected Intel i830M chipset
Nov 27 11:37:07 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000
[root@localhost agp]# /home/didier/repository/kernel/testgart
version: 0.99
bridge id: 0x35758086
agp_mode: 0x1f000217
aper_base: 0xd0000000
aper_size: 256
pg_total: 112384
pg_system: 112384
pg_used: 0
entry.key : 0
entry.key : 1
Allocated 8 megs of GART memory
MemoryBenchmark: 859 mb/s
MemoryBenchmark: 887 mb/s
MemoryBenchmark: 876 mb/s
Average speed: 874 mb/s
Testing data integrity (1st pass): passed on first pass.
Testing data integrity (2nd pass): passed on second pass.
Is the 8 megs of GART OK ?
Is the memory benchmark comparable to equally equipped machines (1.2G
P-III(M), i830(MP), ATI Radeon(M)) ? (I'm trying to differentiate my
performance problem between agpgart and X DRI/DRM).
Kind regards,
Didier
On Mon, 26 Nov 2001 23:16:33 +0100
Didier Moens <[email protected]> wrote:
> Dear Robert, Nicolas, Stephan, :)
>
> I got two patches :
>
>
> 1. From Stephan, to test whether my assumption about the secondary
> device was right :
>
> Stephan wrote :
>
> But if you want you can check that out pretty simple: just add a "break"
> right
> after the case :
>
> case PCI_DEVICE_ID_INTEL_830_M_0:
> ---> break;
>
> i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
>
>
> This patch left me with a loaded agpgart, and accelerated X (DRM/DRI).
> The acceleration is still not up to par with an ATI Mobility-128 (30%
> lower, while it should be at least 200% faster), but I suspect an X
> CVS-problem here.
>
> Quitting and restarting X leaves me with a locked black screen.
Can you provide the output provided by the agp module at load time, please?
This mini-patch of mine should indeed be technically sufficient. Of course I
will provide a "real-world" patch working for all i830 agp-chipsets (M or MG)
as soon as it is clear, that the detection still works.
I am a bit bothered by your X setup. Can you stabilize this somehow? Maybe
using some known-to-work (older) X version for your graphics card.
It looks solvable.
Regards,
Stephan
On Tue, 27 Nov 2001 11:48:35 +0100
Didier Moens <[email protected]> wrote:
> 2. compared to Stephan's original patches ("if i830m_dev ..." and
> "break;") :
>
> Nov 27 11:37:07 localhost kernel: Linux agpgart interface v0.99 (c) Jeff
> Hartmann
> Nov 27 11:37:07 localhost kernel: agpgart: Maximum main memory to use
> for agp memory: 439M
> Nov 27 11:37:07 localhost kernel: agpgart: Detected Intel i830M chipset
> Nov 27 11:37:07 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000
>
> [root@localhost agp]# /home/didier/repository/kernel/testgart
> version: 0.99
> bridge id: 0x35758086
> agp_mode: 0x1f000217
> aper_base: 0xd0000000
> aper_size: 256
> pg_total: 112384
> pg_system: 112384
> pg_used: 0
> entry.key : 0
> entry.key : 1
> Allocated 8 megs of GART memory
> MemoryBenchmark: 859 mb/s
> MemoryBenchmark: 887 mb/s
> MemoryBenchmark: 876 mb/s
> Average speed: 874 mb/s
> Testing data integrity (1st pass): passed on first pass.
> Testing data integrity (2nd pass): passed on second pass.
Ok, since performance and detection seems just ok, I would suggest the attached
patch as a fix. Unlike Nicolas I don't see a need for an additional i830MP
patch, its only the correct detection of the different i830 setups that needs
to be done IMHO.
If there are no further complaints we should submit the patch. What do you
think Nicolas?
Regards,
Stephan
--- agpgart_be.c-orig Tue Nov 27 12:07:14 2001
+++ agpgart_be.c Tue Nov 27 12:07:02 2001
@@ -3879,6 +3879,10 @@
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
NULL);
+ /* If we cannot find secondary, we probably have i830MP
+ which is detected later on */
+ if (i810_dev == NULL)
+ break;
if(PCI_FUNC(i810_dev->devfn) != 0) {
i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_830_M_1,
>
> Ok, since performance and detection seems just ok, I would suggest the attached
> patch as a fix. Unlike Nicolas I don't see a need for an additional i830MP
> patch, its only the correct detection of the different i830 setups that needs
> to be done IMHO.
> If there are no further complaints we should submit the patch. What do you
> think Nicolas?
>
Well, I prefer my version on the patch (of course :-), and I find it
cleaner. Let me explain why : by just adding the 'break', you will fall
back to the generic initialization routines, which work in most of the
cases. However, if you look deeper the code & the specs, they are not
really that good. Esp., you will see that the APSIZE register is
accessed through 16bit reads/writes, whereas the spec says this is a 8
bit register. I have been taught not to write where it is not
explicitely allowed to. Moreover, the 'tlbflush' mechanism also writes
over reserved bits when using the generic routine. My patch is just a
adaptation of what had been done for the Intel 8xx routines (to which I
have contributed), so my way is more consistent with what was previously
done.
However, before submitting the patch, I would like to hear from Didier
about the X server stuff.
Does it still hard-locks when you start it ? If testgart works (which
seems to be the case... btw, yes the 8MB alloced by the program are
normal) and X locks, this would look more like a DRI/X problem (I saw
some problems w. Radeon cards on the dri-devel list, which do not seem
to be fully solved yet)
Best regards
--
Nicolas Aspert Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)
On Tue, 27 Nov 2001 12:43:47 +0100
Nicolas Aspert <[email protected]> wrote:
> > If there are no further complaints we should submit the patch. What do you
> > think Nicolas?
> >
>
> Well, I prefer my version on the patch (of course :-),
Guess what: I expected that :-)
>and I find it
> cleaner. Let me explain why : by just adding the 'break', you will fall
> back to the generic initialization routines, which work in most of the
> cases. However, if you look deeper the code & the specs, they are not
> really that good.
I re-read the code according to your notes. Since I do not have the docs at
hand I am going to trust your word and indeed believe your patch is cleaner.
Only a personal add-on: make it a bit less verbosely talking to the user ;-) I
think we do not need to tell him three times he has i830. One line should be
sufficient. But obviously thats nothing of real importance.
> However, before submitting the patch, I would like to hear from Didier
> about the X server stuff.
> Does it still hard-locks when you start it ? If testgart works (which
> seems to be the case... btw, yes the 8MB alloced by the program are
> normal) and X locks, this would look more like a DRI/X problem (I saw
> some problems w. Radeon cards on the dri-devel list, which do not seem
> to be fully solved yet)
This really looks like an X issue to me and not related to agp.
Thanks for your support, Nicolas.
Regards,
Stephan
PS: you propose the patch to l & m :-) we killed yet another oops.
Nicolas Aspert wrote:
>
>>
>> Ok, since performance and detection seems just ok, I would suggest the
>> attached
>> patch as a fix. Unlike Nicolas I don't see a need for an additional
>> i830MP
>> patch, its only the correct detection of the different i830 setups
>> that needs
>> to be done IMHO.
>> If there are no further complaints we should submit the patch. What do
>> you
>> think Nicolas?
>>
>
> Well, I prefer my version on the patch (of course :-), and I find it
> cleaner. Let me explain why : by just adding the 'break', you will fall
> back to the generic initialization routines, which work in most of the
> cases. However, if you look deeper the code & the specs, they are not
> really that good. Esp., you will see that the APSIZE register is
> accessed through 16bit reads/writes, whereas the spec says this is a 8
> bit register. I have been taught not to write where it is not
> explicitely allowed to. Moreover, the 'tlbflush' mechanism also writes
> over reserved bits when using the generic routine. My patch is just a
> adaptation of what had been done for the Intel 8xx routines (to which I
> have contributed), so my way is more consistent with what was previously
> done.
> However, before submitting the patch, I would like to hear from Didier
> about the X server stuff.
> Does it still hard-locks when you start it ? If testgart works (which
> seems to be the case... btw, yes the 8MB alloced by the program are
> normal) and X locks, this would look more like a DRI/X problem (I saw
> some problems w. Radeon cards on the dri-devel list, which do not seem
> to be fully solved yet)
No more X hard locks.
Compiled & installed latest CVS X (20011127), which includes a Radeon
DGA 2.0 patch : everything fine and dandy (except for my 3D performance
problem).
Kudos to the developer community.
Kind regards,
Didier
Didier Moens
-----
RUG/VIB - Dept. Molecular Biology - Core IT
tel ++32(9)2645309 fax ++32(9)2645348
http://www.dmb.rug.ac.be