Twister savagefb doesn't sync

Twister savagefb doesn't sync

[Vassilis Virvilis]

Hi,

I am a newcomer to the list so please forgive any unforgivable mistake I may do.

The problem at hand is savagefb. The specific model is 0x5333:0x8d01 (twisterP).
I am using a recent enough kernel and I am trying to use fb through SDL.

I believe SDL is not the problem because one of the monitors I tried it is
an EIZO FlexScan 520 that has the extremely nice feature to report the freequency
of the signals the graphics adaptor emits.

See the table:
         640x480       800x600        1024x768
bpp 8   23.1/28.7     26.8/33.2       48.3/59.9 (works)
bpp 16  18.6/23.1     26.8/33.2       33.2/41.2
bpp 32  18.6/23.1     29.7/36.8       33.2/41.2

That means that 640x480x8 emits Horizontal sync at 23.1KHz / VF 28.Hz
which is out of the sync range of any monitor. So the savage clocks are
not programmed correctly (sorry for awkard use of terminology but I am
hardly a graphics expert).

As a workaround for my EIZO I tried (succesfully)

#This syncronize at 100Hz vertical refresh rate
#fbset -xres 640 -yres 480 -depth 16 -t 9260 48 16 33 10 96 2
#This syncronize at 60Hz vertical refresh rate (fbset -i repors 160Hz)
fbset -xres 640 -yres 480 -depth 16 -t 15385 48 16 33 10 96 2

This is not working for my other monitor a TFT Medion (1280x1024). So
I guess that makes it an EDID dependent bug.

So I tried to look the X source code. Looks like it is from the same
codebase more or less with the in kernel savage driver. However the
X driver supports the Option UseBios for mode switching. The default
setting is yes. I tried to disable it and bingo. X exhibits similar
behaviour to the FB driver. It programs the clocks like above. (more or less
I didn't try all the combinations).

So AFAIU neither kernel nor X knows how to program the specific savage card.
I would like it to debug it further but I don't know from where to start.
The code is nicely written but incomprehensible if you don't have the
manual in order to see what all these registers do.

I know howto patch/compile/test and I am willing to help with this if
there is somebody which can guide me a little bit.

          .bill


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

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Vassilis Virvilis wrote:
> Hi,

> The problem at hand is savagefb. The specific model is 0x5333:0x8d01 
> (twisterP).
> I am using a recent enough kernel and I am trying to use fb through SDL.
> 
[snip]

Any ideas on how should I proceed to make the S3 savage work with my monitors,
and preferably with any monitor?

For example since X / Bios combination works is it possible to get into the right
mode and then dump the registers somehow for examination or for later feeding?

Is it possible for the kernel driver to use Bios switching?

Any help / suggestion is greatly appreciated.

     .bill


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Antonino A. Daplas]

Vassilis Virvilis wrote:
> Vassilis Virvilis wrote:
>> Hi,
> 
>> The problem at hand is savagefb. The specific model is 0x5333:0x8d01
>> (twisterP).
>> I am using a recent enough kernel and I am trying to use fb through SDL.
>>
> [snip]
> 
> Any ideas on how should I proceed to make the S3 savage work with my
> monitors,
> and preferably with any monitor?
> 
> For example since X / Bios combination works is it possible to get into
> the right
> mode and then dump the registers somehow for examination or for later
> feeding?
> 

If you can somehow dump the registers of the working and non-working mode,
we might be able find a pattern.

If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.

> Is it possible for the kernel driver to use Bios switching?
> 

Currently, no.

Tony


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Knut Petersen]

>If you can somehow dump the registers of the working and non-working mode,
>we might be able find a pattern.
>
>If you don't know how to dump the register contents, let me know and I'll
>send you a userspace utility to do that.
>
>  
>
>>Is it possible for the kernel driver to use Bios switching?
>>
>>    
>>
>
>Currently, no.
>
>  
>
Vassilis,

Try http://dev.gentoo.org/~spock/projects/vesafb-tng/ for a
vesafb that supports bios mode switching and dump the regs
if it works for you.

cu,
 Knut


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Antonino A. Daplas wrote:
> Vassilis Virvilis wrote:
> 
> If you can somehow dump the registers of the working and non-working mode,
> we might be able find a pattern.
> 
> If you don't know how to dump the register contents, let me know and I'll
> send you a userspace utility to do that.
> 
Thanks for answering...

No I don't know how to dump the registers. I have been googling for that but
so I saw no light. Please dos send me/point to the utility.

When I have enough info I will post it here with the output of dccprobe.

     .bill


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Knut Petersen wrote:

>>
> Vassilis,
> 
> Try http://dev.gentoo.org/~spock/projects/vesafb-tng/ for a
> vesafb that supports bios mode switching and dump the regs
> if it works for you.
> 

Knut, thanks for answering...
I can use X to set the mode. X driver uses BIOS unless told
otherwise (UseBios = false) so the two solutions should be
equivalent. If this fails I will try vesafb-tng.

        .bill


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Antonino A. Daplas wrote:

> If you can somehow dump the registers of the working and non-working mode,
> we might be able find a pattern.
> 
> If you don't know how to dump the register contents, let me know and I'll
> send you a userspace utility to do that.
> 
> 

I found dumpreg from the svgalib distribution (svgalib-bin in debian). Is this
sufficient? If not could you please send me the userspace utility you mentioned
the other day?

  Thanks in advance.

     .bill


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

Vassilis Virvilis wrote:
> Antonino A. Daplas wrote:
> 
>> If you can somehow dump the registers of the working and non-working
>> mode,
>> we might be able find a pattern.
>>
>> If you don't know how to dump the register contents, let me know and I'll
>> send you a userspace utility to do that.
>>
>>
> 
> I found dumpreg from the svgalib distribution (svgalib-bin in debian).
> Is this
> sufficient? 

It might not be sufficient as it won't be able to recognize savage extended
VGA registers.

> If not could you please send me the userspace utility you
> mentioned
> the other day?
> 

Ok, attached, it's a quick hack. Before using it open the file savagedump.c 
and look for the following defines:

#define PCI_ID        0x8d04  /* put the PCI id of the device here */
#define PCI_PBASE     0xdfe80000  /* put the start address of the PCI resource here */

and replace the above values with your own. First do "lspci -n | grep "Class 0300"
and you'll get something like this:

01:00.0 Class 0300: 5333:8d04

Use the last 4 digit ID for the PCI_ID (ie 8d04):

Then do lspci -v -n 5333:8d04 (using instead the vendor:device that you got) and you
should get something like this:

01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] (prog-if 00 [VGA])
        Subsystem: Asustek Computer, Inc.: Unknown device 807b
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
        Memory at dfe80000 (32-bit, non-prefetchable) [size=512K]
        Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at dfe70000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [80] AGP version 2.0

Look for the (32-bit, non-prefetchable) string, the 32-bit hex number is what you're going
to use for your PCI_PBASE.

Once you've done all of the above, compile the app:

gcc -o savagedump savagedump.c

You can now run savagedump as root inside X or the console. Better if you run it in xterm
with X at different modes and with "UseBIOS" set to True and False.

./savagedump > /tmp/savagedump.txt

Send me the files you got, or you may examine it on your own to find a pattern.

Tony

PS: This utility dumps only the CRTC and Sequencer registers.  Hopefully that's enough.
If not, we can revise it so it dumps all registers.


[-- Attachment #2: savagedump.c --]
[-- Type: text/plain, Size: 6882 bytes --]

#include <stdarg.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <string.h>
#include <errno.h>

#define PCI_ID        0x8d04  /* put the PCI id of the device here */
#define PCI_PBASE     0xdfe80000  /* put the start address of the PCI resource here */

#define PCI_CHIP_SAVAGE4      0x8a22
#define PCI_CHIP_SAVAGE3D     0x8a20
#define PCI_CHIP_SAVAGE3D_MV  0x8a21
#define PCI_CHIP_SAVAGE2000   0x9102
#define PCI_CHIP_SAVAGE_MX_MV 0x8c10
#define PCI_CHIP_SAVAGE_MX    0x8c11
#define PCI_CHIP_SAVAGE_IX_MV 0x8c12
#define PCI_CHIP_SAVAGE_IX    0x8c13
#define PCI_CHIP_PROSAVAGE_PM 0x8a25
#define PCI_CHIP_PROSAVAGE_KM 0x8a26
#define PCI_CHIP_S3TWISTER_P  0x8d01
#define PCI_CHIP_S3TWISTER_K  0x8d02
#define PCI_CHIP_PROSAVAGE_DDR          0x8d03
#define PCI_CHIP_PROSAVAGE_DDRK         0x8d04
#define PCI_CHIP_SUPSAV_MX128		0x8c22
#define PCI_CHIP_SUPSAV_MX64		0x8c24
#define PCI_CHIP_SUPSAV_MX64C		0x8c26
#define PCI_CHIP_SUPSAV_IX128SDR	0x8c2a
#define PCI_CHIP_SUPSAV_IX128DDR	0x8c2b
#define PCI_CHIP_SUPSAV_IX64SDR		0x8c2c
#define PCI_CHIP_SUPSAV_IX64DDR		0x8c2d
#define PCI_CHIP_SUPSAV_IXCSDR		0x8c2e
#define PCI_CHIP_SUPSAV_IXCDDR		0x8c2f

#define FB_ACCEL_SAVAGE4        0x80	/* S3 Savage4                   */
#define FB_ACCEL_SAVAGE3D       0x81	/* S3 Savage3D                  */
#define FB_ACCEL_SAVAGE3D_MV    0x82	/* S3 Savage3D-MV               */
#define FB_ACCEL_SAVAGE2000     0x83	/* S3 Savage2000                */
#define FB_ACCEL_SAVAGE_MX_MV   0x84	/* S3 Savage/MX-MV              */
#define FB_ACCEL_SAVAGE_MX      0x85	/* S3 Savage/MX                 */
#define FB_ACCEL_SAVAGE_IX_MV   0x86	/* S3 Savage/IX-MV              */
#define FB_ACCEL_SAVAGE_IX      0x87	/* S3 Savage/IX                 */
#define FB_ACCEL_PROSAVAGE_PM   0x88	/* S3 ProSavage PM133           */
#define FB_ACCEL_PROSAVAGE_KM   0x89	/* S3 ProSavage KM133           */
#define FB_ACCEL_S3TWISTER_P    0x8a	/* S3 Twister                   */
#define FB_ACCEL_S3TWISTER_K    0x8b	/* S3 TwisterK                  */
#define FB_ACCEL_SUPERSAVAGE    0x8c    /* S3 Supersavage               */
#define FB_ACCEL_PROSAVAGE_DDR  0x8d	/* S3 ProSavage DDR             */
#define FB_ACCEL_PROSAVAGE_DDRK 0x8e	/* S3 ProSavage DDR-K           */

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define SAVAGE_NEWMMIO_REGBASE_S3    0x1000000  /* 16MB */
#define SAVAGE_NEWMMIO_REGBASE_S4    0x0000000

#define savage_readb(mmio_base, where)                     \
        *((volatile char *) (mmio_base + where))

#define savage_readw(mmio_base, where)                     \
        *((volatile short *) (mmio_base + where))

#define savage_readl(mmio_base, where)                     \
        *((volatile int *) (mmio_base + where))

#define savage_writeb(mmio_base, where, val)                              \
	*((volatile char *) (mmio_base + where)) = (volatile char) val

#define savage_writew(mmio_base, where, val)                              \
	*((volatile short *) (mmio_base + where)) = (volatile short) val

#define savage_writel(mmio_base, where, val)                              \
	*((volatile int *) (mmio_base + where)) = (volatile int) val

typedef enum {
  S3_UNKNOWN = 0,
  S3_SAVAGE3D,
  S3_SAVAGE_MX,
  S3_SAVAGE4,
  S3_PROSAVAGE,
  S3_SUPERSAVAGE,
  S3_SAVAGE2000,
  S3_LAST
} savage_chipset;

struct s3_device {
	int id;
	int chip;
};

static struct s3_device savage_device[] =  {
	{PCI_CHIP_SUPSAV_MX128, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_MX64, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_MX64C, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IX128SDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IX128DDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IX64SDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IX64DDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IXCSDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SUPSAV_IXCDDR, FB_ACCEL_SUPERSAVAGE},
	{PCI_CHIP_SAVAGE4, FB_ACCEL_SAVAGE4},
	{PCI_CHIP_SAVAGE3D, FB_ACCEL_SAVAGE3D},
	{PCI_CHIP_SAVAGE3D_MV, FB_ACCEL_SAVAGE3D_MV},
	{PCI_CHIP_SAVAGE2000, FB_ACCEL_SAVAGE2000},
	{PCI_CHIP_SAVAGE_MX_MV, FB_ACCEL_SAVAGE_MX_MV},
	{PCI_CHIP_SAVAGE_MX, FB_ACCEL_SAVAGE_MX},
	{PCI_CHIP_SAVAGE_IX_MV, FB_ACCEL_SAVAGE_IX_MV},
	{PCI_CHIP_SAVAGE_IX, FB_ACCEL_SAVAGE_IX},
	{PCI_CHIP_PROSAVAGE_PM, FB_ACCEL_PROSAVAGE_PM},
	{PCI_CHIP_PROSAVAGE_KM, FB_ACCEL_PROSAVAGE_KM},
	{PCI_CHIP_S3TWISTER_P, FB_ACCEL_S3TWISTER_P},
	{PCI_CHIP_S3TWISTER_K, FB_ACCEL_S3TWISTER_K},
	{PCI_CHIP_PROSAVAGE_DDR, FB_ACCEL_PROSAVAGE_DDR},
	{PCI_CHIP_PROSAVAGE_DDRK, FB_ACCEL_PROSAVAGE_DDRK},
};	

int main(int argc, char *argv[])
{
	int mem, j, accel, chip, pbase;
	unsigned char i, *mmio;
	int vgaCRIndex = 0x3d4;
	int vgaCRReg = 0x3d5;

	mem = open("/dev/mem", O_RDWR);

	if (mem == -1)
		exit(1);
	
	for (i = 0; i < ARRAY_SIZE(savage_device); i++) {
		if (savage_device[i].id == PCI_ID) {
			accel = savage_device[i].chip;
			break;
		}
	}

	switch (accel) {
	case FB_ACCEL_SUPERSAVAGE:
		chip = S3_SUPERSAVAGE;
		printf("SuperSavage");
		break;
	case FB_ACCEL_SAVAGE4:
		chip = S3_SAVAGE4;
		printf("Savage4");
		break;
	case FB_ACCEL_SAVAGE3D:
		chip = S3_SAVAGE3D;
		printf("Savage3D");
		break;
	case FB_ACCEL_SAVAGE3D_MV:
		chip = S3_SAVAGE3D;
		printf("Savage3D-MV");
		break;
	case FB_ACCEL_SAVAGE2000:
		chip = S3_SAVAGE2000;
		printf("Savage2000");
		break;
	case FB_ACCEL_SAVAGE_MX_MV:
		chip = S3_SAVAGE_MX;
		printf("Savage/MX-MV");
		break;
	case FB_ACCEL_SAVAGE_MX:
		chip = S3_SAVAGE_MX;
		printf("Savage/MX");
		break;
	case FB_ACCEL_SAVAGE_IX_MV:
		chip = S3_SAVAGE_MX;
		printf("Savage/IX-MV");
		break;
	case FB_ACCEL_SAVAGE_IX:
		chip = S3_SAVAGE_MX;
		printf("Savage/IX");
		break;
	case FB_ACCEL_PROSAVAGE_PM:
		chip = S3_PROSAVAGE;
		printf("ProSavagePM");
		break;
	case FB_ACCEL_PROSAVAGE_KM:
		chip = S3_PROSAVAGE;
		printf("ProSavageKM");
		break;
	case FB_ACCEL_S3TWISTER_P:
		chip = S3_PROSAVAGE;
		printf("TwisterP");
		break;
	case FB_ACCEL_S3TWISTER_K:
		chip = S3_PROSAVAGE;
		printf("TwisterK");
		break;
	case FB_ACCEL_PROSAVAGE_DDR:
		chip = S3_PROSAVAGE;
		printf("ProSavageDDR");
		break;
	case FB_ACCEL_PROSAVAGE_DDRK:
		chip = S3_PROSAVAGE;
		printf("ProSavage8");
		break;
	}

	printf("\n");

	if ((chip >= S3_SAVAGE3D) && (chip <= S3_SAVAGE_MX))
		pbase = PCI_PBASE + SAVAGE_NEWMMIO_REGBASE_S3;
	else
		pbase = PCI_PBASE + SAVAGE_NEWMMIO_REGBASE_S4;

	mmio = mmap(NULL, 512 * 1024, PROT_WRITE | PROT_READ, MAP_SHARED, mem,
		    pbase);

	if (!mmio)
		exit(1);
	
	for (i = 0; i < 0x70; i++) {
		if (!(i % 16))
			printf("\nSR%xx ", i >> 4);
		savage_writeb(mmio, 0x3c4 + 0x8000, i);
		printf(" %02x", savage_readb(mmio, 0x8000 + 0x3c5));
	}

	for (i = 0; i < 0xB7; i++) {
		if (!(i % 16))
			printf("\nCR%xx ", i >> 4);
		savage_writeb(mmio, 0x8000 + vgaCRIndex, i);
		printf(" %02x", savage_readb(mmio, 0x8000 + vgaCRReg));
	}

	printf("\n\n");

	exit(0);
}

Re: Twister savagefb doesn't sync

[Antonino A. Daplas]

Antonino A. Daplas wrote:
> Vassilis Virvilis wrote:
>> Antonino A. Daplas wrote:
>>
>>> If you can somehow dump the registers of the working and non-working
>>> mode,
>>> we might be able find a pattern.
>>>
>>> If you don't know how to dump the register contents, let me know and I'll
>>> send you a userspace utility to do that.
>>>
>>>
>> I found dumpreg from the svgalib distribution (svgalib-bin in debian).
>> Is this
>> sufficient? 
> 
> It might not be sufficient as it won't be able to recognize savage extended
> VGA registers.
> 
>> If not could you please send me the userspace utility you
>> mentioned
>> the other day?
>>
> 
> Ok, attached, it's a quick hack. Before using it open the file savagedump.c 
> and look for the following defines:
> 
> #define PCI_ID        0x8d04  /* put the PCI id of the device here */
> #define PCI_PBASE     0xdfe80000  /* put the start address of the PCI resource here */
> 
> and replace the above values with your own. First do "lspci -n | grep "Class 0300"
> and you'll get something like this:
> 
> 01:00.0 Class 0300: 5333:8d04
> 
> Use the last 4 digit ID for the PCI_ID (ie 8d04):
> 
> Then do lspci -v -n 5333:8d04 (using instead the vendor:device that you got) and you

Typo.  I meant

lspci -v -d 5333:8d04

Tony


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

[-- Attachment #1: Type: text/plain, Size: 3879 bytes --]

Antonino A. Daplas wrote:

> 
> lspci -v -d 5333:8d04
> 
OK I have done a lot of tests. First my device is
5333:8d01 and the non-prefetchable memory is at ec000000
so we have

#define PCI_ID        0x8d01  /* put the PCI id of the device here */
#define PCI_PBASE     0xec000000  /* put the start address of the PCI resource here */

Ok. I tried both X (with use bios), and SDL testsprite in 640x480, 800x600, 1024x768 at
8, 16, 24 bpp.

testsprite is a SDL demo that accepts the following options
(-width, -height, -bpp). I made both sets of tests in a medion TFT 18 screen and in an
EIZO F520 CRT.

All X modes are working.
SDL works for 1024x768 bpp=* in CRT and TFT
SDL work in 800x600 bpp={16, 24} (not 8bpp) only in TFT and __not in CRT__

I am attaching the output of savagedump for all modes, for both monitors (#36),
just for future reference.

I will try to understand the differences but the registers are too many and without
documentation it is a bit hopeless I am afraid. Or is there documentation somewhere publicly
available?

Is there any way to replay the working set of registers to get the correct mode settings?
       .bill

Here is the output for just one case TFT 640x480-256

X- working
TwisterP

SR0x  03 01 0f 00 0e 05 06 07 06 00 0a 00 0c 00 0e 0f
SR1x  67 7d ffffffc5 fffffffc 00 ffffff81 0c ffffff8f 00 02 02 12 00 fffffff8 0a 00
SR2x  20 21 22 23 24 25 26 04 0c 00 2a 02 18 00 2e 2f
SR3x  10 17 41 63 00 00 00 00 00 00 3a 3b 3c 00 3e 00
SR4x  40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
SR5x  00 00 21 fffffff7 1f 1f 1f 7f 08 60 18 7e 77 fffffff7 02 04
SR6x  ffffffa3 7f ffffff80 06 ffffff83 fffffff4 ffffff80 00 24 ffffffff ffffffff 24 02 ffffff88 ffffffa3 32
CR0x  5f 4f 50 ffffff82 52 ffffff9e 0b 3e 00 40 00 00 00 00 ffffffff 00
CR1x  ffffffe9 0b ffffffdf 50 60 ffffffe7 03 ffffffab ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
CR2x  ffffffff ffffffff 1b ffffffff 20 20 20 20 20 20 20 20 20 ffffff8d 01 02
CR3x  ffffffe1 0c 00 08 10 00 ffffffbf ffffffdb 5b ffffffb8 11 58 32 00 00 00
CR4x  01 19 00 00 00 00 01 39 38 ffffffe9 00 ffffffff 7f 7c 40 40
CR5x  ffffffc1 00 00 00 00 00 00 00 13 ffffffe0 00 00 00 00 00 00
CR6x  00 00 00 00 00 00 ffffff89 00 ffffffff ffffff80 00 03 00 ffffffff 00 ffffffee
CR7x  10 ffffffc0 07 1f 1f 1f 00 1f 01 04 1f 1f 17 17 17 17
CR8x  00 00 00 00 70 13 00 00 18 18 18 18 18 18 18 18
CR9x  ffffff80 4f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRax  1a 00 00 00 00 ffffffc0 ffffffc6 ffffffb6 6d 00 00 00 00 00 00 00
CRbx  fffffff7 0c 00 00 00 00 00


SDL testsprite (not working)
TwisterP

SR0x  03 01 0f 00 0e 05 06 07 06 00 0a 00 0c 00 0e 0f
SR1x  67 7d ffffffc5 78 00 ffffff83 0c ffffff8f 00 02 02 ffffff82 00 fffffff8 0a 00
SR2x  20 21 22 23 24 25 26 04 0c 00 2a 02 18 00 2e 2f
SR3x  10 17 41 63 00 00 00 00 00 00 3a 3b 3c 00 3e 00
SR4x  40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
SR5x  00 00 21 fffffff7 1f 1f 1f 7f 08 60 18 76 77 fffffff7 02 04
SR6x  ffffffa3 7f ffffff80 06 ffffff83 fffffff4 ffffff80 00 24 ffffffff ffffffff 24 02 ffffff88 ffffffa3 32
CR0x  63 4f 52 ffffff97 53 18 06 3e 00 40 00 00 00 00 00 00
CR1x  ffffffe9 2c ffffffdf 50 00 ffffffe8 ffffffeb ffffffeb ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
CR2x  ffffffff 00 00 00 00 00 00 00 00 00 00 00 00 ffffff8d 01 02
CR3x  ffffffe1 0c 40 20 10 00 ffffffbf ffffffdb 5b ffffffbd 15 5b 31 00 00 00
CR4x  01 03 00 00 00 00 02 ffffff80 ffffff81 ffffff88 00 ffffffff 7f 7c 40 40
CR5x  ffffffc1 00 00 00 00 00 00 00 13 ffffffe0 00 00 00 00 40 00
CR6x  00 00 00 00 00 00 ffffff89 01 ffffffff 00 00 03 00 ffffffff 00 ffffffee
CR7x  10 ffffffc0 07 1f 1f 1f 00 1f 01 04 1f 1f 17 17 17 17
CR8x  00 00 00 00 70 10 00 00 08 08 08 08 08 08 08 08
CR9x  ffffff80 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRax  1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRbx  fffffff7 0c 00 00 00 00 00

[-- Attachment #2: fbtest.tgz --]
[-- Type: application/x-compressed-tar, Size: 4406 bytes --]

Re: Twister savagefb doesn't sync

[Antonino A. Daplas]

Vassilis Virvilis wrote:
> Antonino A. Daplas wrote:
> 
>>
>> lspci -v -d 5333:8d04
>>
> OK I have done a lot of tests. First my device is
> 5333:8d01 and the non-prefetchable memory is at ec000000
> so we have
> 
> #define PCI_ID        0x8d01  /* put the PCI id of the device here */
> #define PCI_PBASE     0xec000000  /* put the start address of the PCI
> resource here */
> 
> Ok. I tried both X (with use bios), and SDL testsprite in 640x480,
> 800x600, 1024x768 at
> 8, 16, 24 bpp.
> 
> testsprite is a SDL demo that accepts the following options
> (-width, -height, -bpp). I made both sets of tests in a medion TFT 18
> screen and in an
> EIZO F520 CRT.
> 
> All X modes are working.
> SDL works for 1024x768 bpp=* in CRT and TFT
> SDL work in 800x600 bpp={16, 24} (not 8bpp) only in TFT and __not in CRT__
> 
> I am attaching the output of savagedump for all modes, for both monitors
> (#36),
> just for future reference.
> 
> I will try to understand the differences but the registers are too many
> and without
> documentation it is a bit hopeless I am afraid. Or is there

Too many differences since the timings for the 2 modes are also different.
If you can match the timings, as shown by fbset and xvidtune, this should
minimize the variation.

> documentation somewhere publicly
> available?

There are no docs.

> 
> Is there any way to replay the working set of registers to get the
> correct mode settings?

savagefb does save the initial registers and reuses part of them when setting
the mode, so if you can boot with vga= parameter that matches the initial mode
of savagefb, it might help. Try this:

video=savagefb:1024x768-16@60 vga=0x317

Tony


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Antonino A. Daplas wrote:

> 
> Too many differences since the timings for the 2 modes are also different.
> If you can match the timings, as shown by fbset and xvidtune, this should
> minimize the variation.
> 
[snip]
> 
> savagefb does save the initial registers and reuses part of them when setting
> the mode, so if you can boot with vga= parameter that matches the initial mode
> of savagefb, it might help. Try this:
> 
> video=savagefb:1024x768-16@60 vga=0x317
> 

thanks for the hand holding.

Let me reiterate to make sure I understood correctly.

Let's concentrate in one mode because trying all the modes is very time consuming.
Since I am interested mainly in 640x480-16@xx that means vga=0x311. That also
means I shouldn't fiddle with SVGATextMode before loading the savagefb driver.
Right now I am doing a lot of mode3; SVGATextMode -x to restore the console.

So I am booting with video=savagefb:640x480-16@60 vga=0x317 and prevent
SVGATextMode from running.

Now for mode setting. I will run X, xvidtune, fetch the mode. I will use
http://www.tldp.org/HOWTO/Framebuffer-HOWTO-18.html
instructions to convert the mode to a line fbset understands. Then
I will force my SDL test app to use the mode previously set by fbset
and then I will run the savagedump to compare with the X dump.

I will try the procedure above ASAP and report back unless you have any
objections in the methodology.

         .bill


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Antonino A. Daplas]

Vassilis Virvilis wrote:
> Antonino A. Daplas wrote:
> 
>>
>> Too many differences since the timings for the 2 modes are also
>> different.
>> If you can match the timings, as shown by fbset and xvidtune, this should
>> minimize the variation.
>>
> [snip]
>>
>> savagefb does save the initial registers and reuses part of them when
>> setting
>> the mode, so if you can boot with vga= parameter that matches the
>> initial mode
>> of savagefb, it might help. Try this:
>>
>> video=savagefb:1024x768-16@60 vga=0x317
>>
> 
> thanks for the hand holding.
> 
> Let me reiterate to make sure I understood correctly.
> 
> Let's concentrate in one mode because trying all the modes is very time
> consuming.
> Since I am interested mainly in 640x480-16@xx that means vga=0x311. That
> also
> means I shouldn't fiddle with SVGATextMode before loading the savagefb
> driver.
> Right now I am doing a lot of mode3; SVGATextMode -x to restore the
> console.
> 
> So I am booting with video=savagefb:640x480-16@60 vga=0x317 and prevent
> SVGATextMode from running.
> 
> Now for mode setting. I will run X, xvidtune, fetch the mode. I will use
> http://www.tldp.org/HOWTO/Framebuffer-HOWTO-18.html
> instructions to convert the mode to a line fbset understands. Then
> I will force my SDL test app to use the mode previously set by fbset
> and then I will run the savagedump to compare with the X dump.
> 
> I will try the procedure above ASAP and report back unless you have any
> objections in the methodology.

Much simpler if you just load X first with UseBIOS False then dump the regs.
Do the same with UseBIOS True.  You mentioned that X does not work if the
option UseBIOS is false.

Tony 


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

Antonino A. Daplas wrote:
> Vassilis Virvilis wrote:
> 

> 
> Much simpler if you just load X first with UseBIOS False then dump the regs.
> Do the same with UseBIOS True.  You mentioned that X does not work if the
> option UseBIOS is false.
> 
> Tony 
> 

That implies the kernel and the X driver are in sync yes?

Anyway I am attaching a little awk script that works a litle
better that diff for the untrained eye... along with the dumps
you asked. Maybe it makes some sense to you...


Here is the output
regdiff

$>./regdiff fb-640x480-64K@60 X-640x480-64K\@60-usebios\=false
Register:           X working (Bios)   X not working (UseBios=false)
-------------------------------------------------
SR1[0x0]:                  50                  00
SR1[0x1]:                  7d                  00
SR1[0x2]:            ffffffc1            ffffffc7
SR1[0x3]:                  28                  7d
SR1[0x7]:            ffffffc1            fffffffe
SR1[0xB]:            ffffff82                  12
SR5[0xB]:                  7e                  76
CR0[0x2]:                  51                  4f
CR0[0x3]:            ffffff9d            ffffff80
CR0[0xA]:                  1f                  00
CR0[0xB]:                  1e                  00
CR1[0x5]:            ffffffe9            ffffffdf
CR1[0x6]:            ffffffeb                  0b
CR2[0x1]:                  00            ffffffff
CR2[0x3]:                  00            ffffffff
CR2[0x4]:                  00                  20
CR2[0x5]:                  00                  20
CR2[0x6]:                  00                  20
CR2[0x7]:                  00                  20
CR2[0x8]:                  00                  20
CR2[0x9]:                  00                  20
CR2[0xA]:                  00                  20
CR2[0xB]:                  00                  20
CR2[0xC]:                  00                  20
CR3[0x9]:            ffffffbd            ffffffb8
CR3[0xA]:                  15            ffffff91
CR4[0x6]:                  00                  01
CR4[0x7]:            ffffff8a                  39
CR4[0x8]:            ffffff89                  38
CR4[0x9]:                  61            ffffffe9
CR6[0x9]:                  00            ffffff80
CR8[0x6]:                  00                  08
CR8[0x8]:                  08                  10
CR8[0x9]:                  08                  10
CR8[0xA]:                  08                  10
CR8[0xB]:                  08                  10
CR8[0xC]:                  08                  10
CR8[0xD]:                  08                  10
CR8[0xE]:                  08                  10

[-- Attachment #2: regdiff --]
[-- Type: text/plain, Size: 618 bytes --]

#!/bin/awk -f

BEGIN {
	if (ARGC != 3) {
		print "Syntax: regdiff dump1 dump2\n" > "/dev/stderr";
		exit(1);
	}

	f1 = ARGV[1];
	f2 = ARGV[2];

	if ((getline l1 < f1) <= 0 || (getline l2 < f2) <= 0) {
		printf("Cannot find file %s or %s\n", f1, f2) > "/dev/stderr";
		exit(1);
	}

	while (1) {
		if  ((getline l1 < f1) <= 0 || (getline l2 < f2) <= 0)
			break;
		l1n = split(l1, l1a);
		l2n = split(l2, l2a);
		for (i = 1; i < l1n; i++) {
			if (l1a[i] != l2a[i]) {
				reg = sprintf("%s[0x%X]", substr(l1a[1], 0, length(l1a[1]) - 1), i - 2);
				printf("%s:%20s%20s\n", reg, l1a[i], l2a[i]);
			}
		}
	}

	exit(0);
}

[-- Attachment #3: X-640x480-64K@60 --]
[-- Type: text/plain, Size: 1328 bytes --]

TwisterP

SR0x  03 01 0f 00 0e 05 06 07 06 00 0a 00 0c 00 0e 0f
SR1x  00 00 ffffffc5 fffffffc 00 00 0c fffffffe 40 02 02 12 00 fffffff8 0a 00
SR2x  20 21 22 23 24 25 26 04 0c 00 2a 02 18 00 2e 2f
SR3x  10 17 41 63 00 00 00 00 00 00 3a 3b 3c 00 3e 00
SR4x  40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
SR5x  00 00 21 fffffff7 1f 1f 1f 7f 08 60 18 7e 77 fffffff7 02 04
SR6x  ffffffa3 7f ffffff80 06 ffffff83 fffffff4 ffffff80 00 24 ffffffff ffffffff 24 02 ffffff98 ffffffa3 32
CR0x  5f 4f 50 ffffff82 52 ffffff9e 0b 3e 00 40 00 00 00 00 ffffffff 00
CR1x  ffffffe9 0b ffffffdf ffffffa0 60 ffffffe7 03 ffffffab ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
CR2x  ffffffff ffffffff 6c ffffffff 20 20 20 20 20 20 20 20 20 ffffff8d 01 02
CR3x  ffffffe1 0c 00 08 00 00 ffffffbf ffffffdb 5b ffffffb8 10 58 32 00 00 00
CR4x  01 20 00 00 00 01 00 ffffffff fffffff8 3e 00 ffffffff 7f 7c 40 40
CR5x  ffffffd1 00 00 08 00 00 00 00 13 ffffffe0 00 00 00 00 00 00
CR6x  00 00 00 00 00 04 ffffff89 40 ffffffff ffffff80 00 03 00 ffffffff 00 ffffffee
CR7x  10 ffffffc0 07 1f 1f 1f 00 1f 01 04 1f 1f 17 17 17 17
CR8x  00 00 00 00 70 13 00 00 10 10 10 10 10 10 10 10
CR9x  ffffff80 ffffff9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRax  1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRbx  fffffff7 0c 00 00 00 00 00


[-- Attachment #4: X-640x480-64K@60-usebios=false --]
[-- Type: text/plain, Size: 1316 bytes --]

TwisterP

SR0x  03 01 0f 00 0e 05 06 07 06 00 0a 00 0c 00 0e 0f
SR1x  00 00 ffffffc7 7d 00 ffffff83 0c fffffffe 00 02 02 12 00 fffffff8 0a 00
SR2x  20 21 22 23 24 25 26 04 0c 00 2a 02 18 00 2e 2f
SR3x  10 17 41 63 00 00 00 00 00 00 3a 3b 3c 00 3e 00
SR4x  40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
SR5x  00 00 21 fffffff7 1f 1f 1f 7f 08 60 18 76 77 fffffff7 02 04
SR6x  ffffffa3 7f ffffff80 06 ffffff83 fffffff4 ffffff80 00 24 ffffffff ffffffff 24 02 ffffff98 ffffffa3 32
CR0x  5f 4f 4f ffffff80 52 1e 0b 3e 00 40 00 00 00 00 00 00
CR1x  ffffffea 2c ffffffdf ffffffa0 00 ffffffdf 0b ffffffeb ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
CR2x  ffffffff ffffffff 00 ffffffff 20 20 20 20 20 20 20 20 20 ffffff8d 01 02
CR3x  ffffffe1 0c 40 08 10 00 ffffffbf ffffffdb 5b ffffffb8 ffffff91 59 2f 00 00 00
CR4x  01 03 00 00 00 00 01 39 38 ffffffe9 00 ffffffff 7f 7c 40 40
CR5x  ffffffd1 00 00 00 00 00 00 00 13 ffffffe0 00 00 00 00 40 00
CR6x  00 00 00 00 00 00 ffffff89 41 ffffffff ffffff80 00 03 00 ffffffff 00 ffffffee
CR7x  10 ffffffc0 07 1f 1f 1f 00 1f 01 04 1f 1f 17 17 17 17
CR8x  00 00 00 00 70 10 08 00 10 10 10 10 10 10 10 10
CR9x  ffffff80 ffffffa0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRax  1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CRbx  fffffff7 0c 00 00 00 00 00

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Antonino A. Daplas wrote:
> 
> Much simpler if you just load X first with UseBIOS False then dump the regs.
> Do the same with UseBIOS True.  You mentioned that X does not work if the
> option UseBIOS is false.
> 
> Tony 
> 

Any ideas about the data I posted?
http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=114908868820818&w=2

I can undestand that is problem difficult to tackle remotely.

Thanks anyway.

    .bill

Re: Twister savagefb doesn't sync

[Alex Deucher]

On 6/5/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> Antonino A. Daplas wrote:
> >
> > Much simpler if you just load X first with UseBIOS False then dump the regs.
> > Do the same with UseBIOS True.  You mentioned that X does not work if the
> > option UseBIOS is false.
> >
> > Tony
> >
>
> Any ideas about the data I posted?
> http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=114908868820818&w=2
>
> I can undestand that is problem difficult to tackle remotely.
>

The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
 the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead.  I tried for a while to add non-bios mode setting to crtc2
without much luck.

For a short term fix, just program the registers with the new values
from the bios.  You may be able to just get away with adjusting the
crtc1 dclk (SR12, SR13, SR29). A real fix may require special
calculations or tables for different chip/panel combos.

Alex


> Thanks anyway.
>
>     .bill
>

Re: Twister savagefb doesn't sync

[Vassilis Virvilis]

Alex Deucher wrote:
> On 6/5/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> 
> The reason the savage xorg drver uses the bios is because almost every
> panel they connect to the chip seems to require fairly custom timings.
> the twisters and prosavages are even worse than the discrete chips.
> Also, only the bios seems to know the magic incantation necessary for
> dualhead.  I tried for a while to add non-bios mode setting to crtc2
> without much luck.

I don't care for dualhead right now. I can imagine it is 4 times weirder
than my current setup. What is crtc*?

> 
> For a short term fix, just program the registers with the new values
> from the bios.  You may be able to just get away with adjusting the
> crtc1 dclk (SR12, SR13, SR29).

I will try that. Thanks for the suggestion.

A real fix may require special
> calculations or tables for different chip/panel combos.
> 

I will try for both of my monitors and I will report here any
success or failure unless of course I am told that this info is
not desirable.

Do you know if changing the number of colors 256/64K/16M requires
clock adjustments (SR12, SR13, SR29)?

Thanks for answering.

      .bill

Re: Twister savagefb doesn't sync

[Alex Deucher]

On 6/6/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> Alex Deucher wrote:
> > On 6/5/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> >
> > The reason the savage xorg drver uses the bios is because almost every
> > panel they connect to the chip seems to require fairly custom timings.
> > the twisters and prosavages are even worse than the discrete chips.
> > Also, only the bios seems to know the magic incantation necessary for
> > dualhead.  I tried for a while to add non-bios mode setting to crtc2
> > without much luck.
>
> I don't care for dualhead right now. I can imagine it is 4 times weirder
> than my current setup. What is crtc*?

twisters/prosavages can't do dualhead anyway. crtc stands for crt
controller.  it's just another name for a display controller (ie,
thing that scans out the image).

>
> >
> > For a short term fix, just program the registers with the new values
> > from the bios.  You may be able to just get away with adjusting the
> > crtc1 dclk (SR12, SR13, SR29).
>
> I will try that. Thanks for the suggestion.
>
> A real fix may require special
> > calculations or tables for different chip/panel combos.
> >
>
> I will try for both of my monitors and I will report here any
> success or failure unless of course I am told that this info is
> not desirable.

Sounds good.

>
> Do you know if changing the number of colors 256/64K/16M requires
> clock adjustments (SR12, SR13, SR29)?

It shouldn't.

>
> Thanks for answering.

No problem.

Alex

>
>       .bill
>

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Vassilis Virvilis]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

Hi Alex,

I would like to thank you and Antonino for all the help so far. I have finally
manage to make my twister to sync with both of my screens (one TFT, one CRT).

I am attaching the patch. The patch itself disables all modes other than
640x480@64K-60Hz. Note that the patch is clearly inapropriate but it
may sparkle some discussion about how this thing works.

One more question:

Alex Deucher wrote:
>> > The reason the savage xorg drver uses the bios is because almost every
>> > panel they connect to the chip seems to require fairly custom timings.
>> > the twisters and prosavages are even worse than the discrete chips.
>> > Also, only the bios seems to know the magic incantation necessary for
>> > dualhead.  I tried for a while to add non-bios mode setting to crtc2
>> > without much luck.
>>

When you say panel what do you mean?
a) The rest of the framebuffer and scan logic resided in CRTC?
b) The screen attached to CRTC?

I believe a) but I would like to know for sure.

Thanks again...

    .bill

[-- Attachment #2: savage-640x48064K.patch --]
[-- Type: text/x-patch, Size: 774 bytes --]

diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
index 10e6b3a..117205e 100644
--- a/drivers/video/savage/savagefb_driver.c
+++ b/drivers/video/savage/savagefb_driver.c
@@ -901,6 +901,7 @@ static int savagefb_decode_var (struct f
 
 	SavageCalcClock (dclk, 1, 1, 127, 0, 4, 180000, 360000, &m, &n, &r);
 	/* m = 107; n = 4; r = 2; */
+	m = 0xfc; n = 0x5; r = 0x3; /* TwisterP */
 
 	if (par->MCLK <= 0) {
 		par->SR10 = 255;
@@ -908,6 +909,7 @@ static int savagefb_decode_var (struct f
 	} else {
 		common_calc_clock (par->MCLK, 1, 1, 31, 0, 3, 135000, 270000,
 				   &par->SR11, &par->SR10);
+		par->SR10 = 0x0; par->SR11 = 0x0; /* TwisterP */
 		/*      par->SR10 = 80; // MCLK == 286000 */
 		/*      par->SR11 = 125; */
 	}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Alex Deucher]

On 6/11/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> Hi Alex,
>
> I would like to thank you and Antonino for all the help so far. I have finally
> manage to make my twister to sync with both of my screens (one TFT, one CRT).
>
> I am attaching the patch. The patch itself disables all modes other than
> 640x480@64K-60Hz. Note that the patch is clearly inapropriate but it
> may sparkle some discussion about how this thing works.
>
> One more question:
>
> Alex Deucher wrote:
> >> > The reason the savage xorg drver uses the bios is because almost every
> >> > panel they connect to the chip seems to require fairly custom timings.
> >> > the twisters and prosavages are even worse than the discrete chips.
> >> > Also, only the bios seems to know the magic incantation necessary for
> >> > dualhead.  I tried for a while to add non-bios mode setting to crtc2
> >> > without much luck.
> >>
>
> When you say panel what do you mean?
> a) The rest of the framebuffer and scan logic resided in CRTC?
> b) The screen attached to CRTC?
>
> I believe a) but I would like to know for sure.

I'm not sure I understand your question.  The panel connects to the
chip via a built in flat panel interface, however it has to be driven
with timings and a clock just like a CRT.  The CRTC can drive either
the FP interface or the DAC or both.  Based on you patch it seems you
only need to tweak the clock.  Perhaps if we had a few more testers we
could figure out a pattern for common panels and put in some sort of
generic fix.

Alex

>
> Thanks again...
>
>     .bill
>
>
>

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Vassilis Virvilis]

Alex Deucher wrote:

> 
> I'm not sure I understand your question.

That is because it wasn't a brilliant question and when I say screen
I mean monitor. Sorry for the confusion. I was trying to figure out
if the thing was external to the PCI card (i.e. in the monitor) or internal
(i.e. DAC). But since I am not familiar with the domain I don't know
how to ask the questions properly.

Anyway is there a way to probe for that FP thing? or to distinguish
between them?


> Perhaps if we had a few more testers we
> could figure out a pattern for common panels and put in some sort of
> generic fix.
> 

I don't mind produce more data or test things as long as I have the
equipment...


       .bill

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Geert Uytterhoeven]

On Sun, 11 Jun 2006, Vassilis Virvilis wrote:
> Alex Deucher wrote:
> > > > The reason the savage xorg drver uses the bios is because almost every
> > > > panel they connect to the chip seems to require fairly custom timings.
> > > > the twisters and prosavages are even worse than the discrete chips.
> > > > Also, only the bios seems to know the magic incantation necessary for
> > > > dualhead.  I tried for a while to add non-bios mode setting to crtc2
> > > > without much luck.
> > > 
> 
> When you say panel what do you mean?
> a) The rest of the framebuffer and scan logic resided in CRTC?
> b) The screen attached to CRTC?
> 
> I believe a) but I would like to know for sure.

panel = LCD panel (in contrast to CRT = Cathode Ray Tube)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Alex Deucher]

On 6/12/06, Vassilis Virvilis <vasvir@iit.demokritos.gr> wrote:
> Alex Deucher wrote:
>
> >
> > I'm not sure I understand your question.
>
> That is because it wasn't a brilliant question and when I say screen
> I mean monitor. Sorry for the confusion. I was trying to figure out
> if the thing was external to the PCI card (i.e. in the monitor) or internal
> (i.e. DAC). But since I am not familiar with the domain I don't know
> how to ask the questions properly.
>
> Anyway is there a way to probe for that FP thing? or to distinguish
> between them?

about they most you can get on the savage is detecting whether or not
there is a panel attached and what size the panel is.  AFAIK, there's
no way to detect the panel specifics.  However, if we got some more
datapoints and found that most panels need the plls tweaked to a
certain range we could probably handle it more gracefully.  You could
probably even get it working now if you used a special modeline.

Alex

>
>
> > Perhaps if we had a few more testers we
> > could figure out a pattern for common panels and put in some sort of
> > generic fix.
> >
>
> I don't mind produce more data or test things as long as I have the
> equipment...
>
>
>        .bill
>

Re: Twister savagefb doesn't sync (resolved for 640x480@64K)

[Vassilis Virvilis]

Alex Deucher wrote:
> 
> about they most you can get on the savage is detecting whether or not
> there is a panel attached and what size the panel is.  AFAIK, there's
> no way to detect the panel specifics.  However, if we got some more
> datapoints and found that most panels need the plls tweaked to a
> certain range we could probably handle it more gracefully.  You could
> probably even get it working now if you used a special modeline.
> 
> Alex
> 

That's true. See at the start of the thread...
http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=114781832315079&w=2

"""
 >As a workaround for my EIZO I tried (succesfully)

 >#This syncronize at 60Hz vertical refresh rate (fbset -i repors 160Hz)
 >fbset -xres 640 -yres 480 -depth 16 -t 15385 48 16 33 10 96 2

This is not working for my other monitor a TFT Medion (1280x1024). So
I guess that makes it an EDID dependent bug.
"""