Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Tuesday 15 February 2005 01:55, Frans Pop wrote:
> Hello Tony,
>
> Thanks for your reaction.
>
> On Monday 14 February 2005 17:59, Antonino A. Daplas wrote:
> > The above timings are screwed.  This is 1024x768 at 85Hz INTERLACED.
> > The fb_find_mode() function picked up this mode when you specified
> > 1024x768@75, since there is no such mode in the mode database.
> > And the atyfb driver accepted the mode without differentiating between
> > interlaced and non-interlaced.
>
> Right. I tried with 1024x768@70 and that gives some improvement.
> For a very, very short time I see the Linux logo and some boot messages
> flash on the display, but then the monitor still goes into suspend.
>
> It really is just a flash, but I think I see some of the atyfb debug
> messages. That would indicate that the suspend is activated somewhere near
> the end of console initialization (maybe at the "switching to colour frame
> buffer device 128x48"?). But again, this is based on an impression.
>
> So it seems there are two bugs:
> - missing/incorrect default mode settings for sparc in the driver;
> - incorrect activation of suspend.

Try editing drivers/video/console/fbcon.c, look for the function
fbcon_startup(). After the line 'ops->currcon = -1;', insert this line:

ops->blank_state = -1;

Also, try changing the graphics state such as doing an
fbset -depth 16 or the like.

What happens if you switch consoles?

You can also try commenting out .fb_blank = atyfb_blank from
static struct fb_ops atyfb_ops and disable CONFIG_PM from your kernel
config.

>
> > PS:  There was also a massive atyfb update between 2.6.10-rc1 and rc2.
> > Here's the changelog:
>
> How best to proceed? Can you help?

I'll CC fbdev-devel list.

>
> Cheers,
> Frans Pop

Tony

>
>
> For comparison, here are the relevant lines from kern.log when
> booting with a Debian 2.6.8 kernel:
> atyfb: 3D RAGE (GT) [0x4754 rev 0x9a] 2M SGRAM, 14.31818 MHz XTAL, 200 MHz
> PLL, 67 Mhz MCLK fb0: ATY Mach64 frame buffer device on PCI
> Console: switching to mono PROM 80x34
> Console: switching to colour frame buffer device 144x56
>
> And here the lines from 2.6.10-rc2 with video=atyfb:1024x768@70:
> atyfb: 3D RAGE (Mach64 GT) [0x4754 rev 0x02]
> atyfb: 2M SGRAM (1:1), 14.31818 MHz XTAL, 200 MHz PLL, 67 Mhz MCLK, 67 MHz
> XCLK atyfb: setting up CRTC
> atyfb: set primary CRT to 1024x768 NN composite N
> atyfb: CRTC_H_TOTAL_DISP: 7f00a5
> atyfb: CRTC_H_SYNC_STRT_WID: 310082
> atyfb: CRTC_V_TOTAL_DISP: 2ff0325
> atyfb: CRTC_V_SYNC_STRT_WID: 260302
> atyfb: CRTC_OFF_PITCH: 20000000
> atyfb: CRTC_VLINE_CRNT_VLINE: 0
> atyfb: CRTC_GEN_CNTL: b000200
> atyfb: atyfb_set_par
> atyfb:  Set Visible Mode to 1024x768-8
> atyfb:  Virtual resolution 1024x2016, pixclock_in_ps 13373 (calculated
> 13373) atyfb:  Dot clock:           74 MHz
> atyfb:  Horizontal sync:     56 kHz
> atyfb:  Vertical refresh:    69 Hz
> atyfb:  x  style: 74.10398 1024 1048 1184 1328   768 771 777 806
> atyfb:  fb style: 13373  144 1024 24 136 29 768 3 6
> debug atyfb: Mach64 non-shadow register values:
> debug atyfb: 0x2000:  007F00A5 00310082 02FF0325 00260302
> debug atyfb: 0x2010:  01AA0000 20000000 08000020 0B000200
> debug atyfb: 0x2020:  00380727 0120051B 00000000 00000000
> debug atyfb: 0x2030:  00000000 00000031 00000000 00000000
> debug atyfb: 0x2040:  00000000 00000000 00000000 00000000
> debug atyfb: 0x2050:  00000000 00000000 00000000 00000000
> debug atyfb: 0x2060:  00000000 AAAAAA0F 00000000 00000000
> debug atyfb: 0x2070:  00000000 00000000 00003020 00000000
> debug atyfb: 0x2080:  00000000 00000000 00000000 00000000
> debug atyfb: 0x2090:  00A63000 00000000 00000000 00000000
> debug atyfb: 0x20A0:  7B23A040 00000000 00000000 05000001
> debug atyfb: 0x20B0:  004210B3 00010000 00010000 00000000
> debug atyfb: 0x20C0:  00FF0000 86010182 00000000 00000000
> debug atyfb: 0x20D0:  00000100 00000000 00000000 00003842
> debug atyfb: 0x20E0:  9A004754 0000001D 00000000 00000000
> debug atyfb: 0x20F0:  00000000 00008E0D E17FFCF8 00000000
>
> debug atyfb: Mach64 PLL register values:
> debug atyfb: 0x00:  CDD52414 A80341BC 8E82E701 A61B0000
> debug atyfb: 0x10:  CDD52414 A80341BC 8E82E701 A61B0000
> debug atyfb: 0x20:  CDD52414 A80341BC 8E82E701 A61B0000
> debug atyfb: 0x30:  CDD52414 A80341BC 8E82E701 A61B0000
>
> Console: switching to colour frame buffer device 128x48
> atyfb: fb0: ATY Mach64 frame buffer device on PCI

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[David S. Miller]

I'm also going to read over those atyfb changes in the background and
see if I can figure anything out.

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Frans Pop]

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

Hi Tony,

I've tried your suggestions and the one about using fbset resulted in a 
breakthrough. 'fbset -depth' gave no results, but comparing the output of 
'fbset -i' from a working kernel and a new one gave me something to try.

From 2.6.8 kernel (working framebuffer):
mode "1152x900-66"
    # D: 93.870 MHz, H: 61.433 kHz, V: 65.564 Hz
    geometry 1152 900 1152 1792 8
    timings 10653 190 58 31 2 128 4
    hsync high
    csync high
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : ATY Mach64
    Address     : 0xe1800000
    Size        : 2088960
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1152
    MMIO Address: 0xfffffc00
    MMIO Size   : 2048
    Accelerator : ATI Mach64GT
<end>

From 2.6.10-rc2 (not working):
mode "1024x768-70"
    # D: 74.778 MHz, H: 56.308 kHz, V: 69.862 Hz
    geometry 1024 768 1024 2016 8
    timings 13373 144 24 29 3 136 6
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : ATY Mach64
    Address     : 0xe1800000
    Size        : 2088960
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1024
    MMIO Address: 0xe17ff800
    MMIO Size   : 2048
    Accelerator : ATI Mach64GT
<end>

The significant difference is in the settings for hsync and csync. After 
setting both 'high' (hsync alone did nothing) from a SSH terminal the 
monitor turned on :-D

I hope this will be enough of a clue for those who know the driver code to 
work out a patch.

These values also tell that the old default mode was 1152x900-66, 
resulting in a 144x56 textconsole. My personal opinion is that that is 
very high for a default mode. The 1024x768-70 (resulting in 128x48) I've 
been using now (or maybe even something a bit lower) seems more 
reasonable to me.

For completeness sake I've included the answers to your questions below.

Cheers,
Frans

On Tuesday 15 February 2005 00:40, Antonino A. Daplas wrote:
> Try editing drivers/video/console/fbcon.c, look for the function
> fbcon_startup(). After the line 'ops->currcon = -1;', insert this line:
>
> ops->blank_state = -1;

Hmm. Results in a compilation error when I tried that in -rc2: no such 
variable in that structure.
I checked 2.6.11-rc3-bk2 and noticed it was added there, so I tested this 
suggestion with that version. No difference.

> Also, try changing the graphics state such as doing an
> fbset -depth 16 or the like.

I tried that from my ssh terminal and only -depth 8 was accepted.
Both 16 and 24 gave the same result:
# fbset -depth 16 -fb /dev/fb0
ioctl FBIOPUT_VSCREENINFO: Invalid argument

> What happens if you switch consoles?

Nothing at all. Hitting keys does nothing either, also not after leaving 
the system alone for a long time.

> You can also try commenting out .fb_blank = atyfb_blank from
> static struct fb_ops atyfb_ops and disable CONFIG_PM from your kernel
> config.

The first suggestion makes no difference.
As to the CONFIG_PM: there is no such setting in my .config for sparc64 
(i386 does have it). I do have CONFIG_FB_PM2, but that is not set.

> I'll CC fbdev-devel list.

Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-fbdev-devel] Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Geert Uytterhoeven]

On Tue, 15 Feb 2005, Frans Pop wrote:
> These values also tell that the old default mode was 1152x900-66, 
> resulting in a 144x56 textconsole. My personal opinion is that that is 
> very high for a default mode. The 1024x768-70 (resulting in 128x48) I've 
> been using now (or maybe even something a bit lower) seems more 
> reasonable to me.

1152x900 is the default Sun mode.

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: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Tuesday 15 February 2005 14:22, Frans Pop wrote:
> Hi Tony,
>
> I've tried your suggestions and the one about using fbset resulted in a
> breakthrough. 'fbset -depth' gave no results, but comparing the output of
> 'fbset -i' from a working kernel and a new one gave me something to try.
>

Okay.  It seems that in the working kernel, the default mode, 1152x900, was
taken from the prom (since there is no 1152x900 in the mode database) if you
did not specify any boot mode option.

In the non-working version, without the boot mode option, the default_var
was used (which is only 640x480) or taken from the mode database if you
specified a boot mode.  Unfortunately, none of the entries in the mode
database nor the default var has the composite sync set to high, which
causes your display to go out of sync.  If I'm going to guess, the 2.6.10
version failed to get the default mode from the prom.

Can you verify if this is the case?  Insert a bunch of printk's in and around this
line "if (node == pcp->prom_node) {" in atyfb_setup_sparc().  For the 2.6.8
kernel, this line is in atyfb_init().

As a workaround, a boot option can be added for csync, hsync and vsync. 

Tony

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[David S. Miller]

On Tue, 15 Feb 2005 20:10:21 +0800
"Antonino A. Daplas" <adaplas@hotpop.com> wrote:

> Okay.  It seems that in the working kernel, the default mode, 1152x900, was
> taken from the prom (since there is no 1152x900 in the mode database) if you
> did not specify any boot mode option.
> 
> In the non-working version, without the boot mode option, the default_var
> was used (which is only 640x480) or taken from the mode database if you
> specified a boot mode.

I think the bug is in the changes made to the fb_find_mode() calls
in the !CONFIG_PPC case.  That looked suspicious to me the first time
I scanned the atyfb driver diffs in 2.6.11

First of all, a file global declared as "static char *mode" is asking for
all sorts of trouble.  It's very easy to use such a simple name as
a function local variable, thus making the global one invisible.

I reviewed the driver and there are no cases of local variables named
"mode" right now, but this is still asking for trouble in the future.
It should be thus renamed.

Now let's get back to the fb_find_mode() call in aty_init().  The old
code for the non-CONFIG_PPC case did this:

#ifdef __sparc__
	if (mode_option) {
		if (!fb_find_mode(...))
			var = default_var;
	} else
		var = default_var;
#else
	if (!fb_find_mode(...))
		var = default_var;
#endif

The new code calls fb_find_mode() always, this is wrong for Sparc's
desired behavior:

	if (!fb_find_mode(...))
		var = default_var;

On sparc, when "mode" is NULL, we should always use default_var as
setup by PROM probed values.

Here is the fix:

===== drivers/video/aty/atyfb_base.c 1.82 vs edited =====
--- 1.82/drivers/video/aty/atyfb_base.c	2005-01-04 18:48:32 -08:00
+++ edited/drivers/video/aty/atyfb_base.c	2005-02-15 08:19:00 -08:00
@@ -2511,7 +2511,15 @@
 		}
 	} else
 #endif /* !CONFIG_PPC */
-	if (!fb_find_mode(&var, info, mode, NULL, 0, &defmode, 8))
+	if (
+#if defined(CONFIG_SPARC32) || defined(CONFIG_SPARC64)
+	   /* On Sparc, unless the user gave a specific mode
+	    * specification, use the PROM probed values in
+	    * default_var.
+	    */
+	    !mode ||
+#endif
+	    !fb_find_mode(&var, info, mode, NULL, 0, &defmode, 8))
 		var = default_var;
 
 	if (noaccel)

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Frans Pop]

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

On Tuesday 15 February 2005 17:49, David S. Miller wrote:
> On sparc, when "mode" is NULL, we should always use default_var as
> setup by PROM probed values.
>
> Here is the fix:

Excellent!
Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the 
old behavior. I guess that solves the regression since 2.6.10-rc2.

Please let me know if this patch will be submitted for inclusion as is so 
I can also submit it for inclusion in the Debian 2.6.10 kernel.


From my experiences in tracing and testing this, I have a couple of 
questions I'd like to put before you and the lists. (I should add that my 
experience with sparcs is still very limited.)

I would like to set a lower default resolution as my monitor barely 
supports 1152x900@66. I tried two things:
- # eeprom output-device=screen:r1024x768x70
  This seems to be completely ignored during boot; resolution is still
  1152x900.

- boot with parameter 'video=atyfb:1024x768@70'
  This does work, but csync is not set to high and so the monitor again
  goes into suspend; after 'fbset -csync high' the monitor turns on.
  Is csync something that needs to be set by the user or should the driver
  take care of that also at frequencies other then 1152x900?


The second question concerns the use of Stop-A.
With the console at 1152x900@66, if I press Stop-A, I get the openprom 
prompt. The screen has the last display before pressing Stop-A with a 
white square inside it containing the openprom display (filling about 75% 
of the screen).
If I do the same at 1024x768@70, I get a garbled display (no readable text 
from the openprom). I can still press go to return to linux though and 
the display is restored after clearing it.

Can/should this be fixed or should the conclusion be that resolutions 
other than 1152x900@66 are just not supported?

Cheers,
Frans Pop

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[David S. Miller]

On Wed, 16 Feb 2005 03:27:51 +0100
Frans Pop <aragorn@tiscali.nl> wrote:

> Excellent!
> Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the 
> old behavior. I guess that solves the regression since 2.6.10-rc2.
> 
> Please let me know if this patch will be submitted for inclusion as is so 
> I can also submit it for inclusion in the Debian 2.6.10 kernel.

I applied it and will push upstream.

> I would like to set a lower default resolution as my monitor barely 
> supports 1152x900@66. I tried two things:
> - # eeprom output-device=screen:r1024x768x70
>   This seems to be completely ignored during boot; resolution is still
>   1152x900.

The PROM console driver will only accept certain settings.  I believe
the allowable settings is documented in the Sun Framebuffer Handbook
or something like that.

> - boot with parameter 'video=atyfb:1024x768@70'
>   This does work, but csync is not set to high and so the monitor again
>   goes into suspend; after 'fbset -csync high' the monitor turns on.
>   Is csync something that needs to be set by the user or should the driver
>   take care of that also at frequencies other then 1152x900?

Unfortunately, the user needs to specify this.  I, at one point, even
convinced the XFREE86 mach64 maintainer to enable CSYNC by default
and that broke things for some users and thus the default had to be
changed back to off.

Therefore the kernel fb driver shouldn't turn CSYNC on by default either.

> The second question concerns the use of Stop-A.

If you tell the kernel to use a different resolution than the PROM had,
stop-a is not going to work.

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Wednesday 16 February 2005 11:20, David S. Miller wrote:
> On Wed, 16 Feb 2005 03:27:51 +0100
>
> Frans Pop <aragorn@tiscali.nl> wrote:
> > Excellent!
> > Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores
> > the old behavior. I guess that solves the regression since 2.6.10-rc2.
> >
> > Please let me know if this patch will be submitted for inclusion as is so
> > I can also submit it for inclusion in the Debian 2.6.10 kernel.
>
> I applied it and will push upstream.

Great, I was about to push this upstream. Thanks.

Tony 

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Frans Pop]

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

On Tuesday 15 February 2005 13:10, Antonino A. Daplas wrote:
> Can you verify if this is the case?  Insert a bunch of printk's in and
> around this line "if (node == pcp->prom_node) {" in
> atyfb_setup_sparc().  For the 2.6.8 kernel, this line is in
> atyfb_init().

Tested that and output is identical for both. That condition you cite is 
true for both kernels and the resolutions are retrieved from prom:
atyfb (fjp): crtc.vxres 1152
atyfb (fjp): crtc.vyres 900

> As a workaround, a boot option can be added for csync, hsync and vsync.

Hmm. I looked for the syntax for that, but can't find it.
I tried
  video=atyfb:1024x768@70,csync:1
and
  video=atyfb:1024x768@70,csync:high
but both failed miserably.
(I have checked that csync is sufficient to activate the monitor.)

What I get is boot messages 'vclk out of range' and 'not enough video RAM' 
and I end up with 640x480-60 with both hsync and _v_sync set high, but 
not csync (and a monitor in suspend of course).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Wednesday 16 February 2005 10:27, Frans Pop wrote:
> On Tuesday 15 February 2005 13:10, Antonino A. Daplas wrote:
> > Can you verify if this is the case?  Insert a bunch of printk's in and
> > around this line "if (node == pcp->prom_node) {" in
> > atyfb_setup_sparc().  For the 2.6.8 kernel, this line is in
> > atyfb_init().
>
> Tested that and output is identical for both. That condition you cite is
> true for both kernels and the resolutions are retrieved from prom:
> atyfb (fjp): crtc.vxres 1152
> atyfb (fjp): crtc.vyres 900
>
> > As a workaround, a boot option can be added for csync, hsync and vsync.
>
> Hmm. I looked for the syntax for that, but can't find it.
> I tried
>   video=atyfb:1024x768@70,csync:1
> and
>   video=atyfb:1024x768@70,csync:high
> but both failed miserably.
> (I have checked that csync is sufficient to activate the monitor.)

Nope, those are proposed options.  If nobody disagrees, I can easily add
this for atyfb.

Tony

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[David S. Miller]

On Wed, 16 Feb 2005 19:27:57 +0800
"Antonino A. Daplas" <adaplas@hotpop.com> wrote:

> Nope, those are proposed options.  If nobody disagrees, I can easily add
> this for atyfb.

Please do.

BTW, for Sparc we may wish to inherit the CSYNC setting from default_var.

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Frans Pop]

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

On Wednesday 16 February 2005 16:51, David S. Miller wrote:
> On Wed, 16 Feb 2005 19:27:57 +0800 Antonino A. Daplas wrote:
> > Nope, those are proposed options.  If nobody disagrees, I can easily
> > add this for atyfb.
>
> Please do.
>
> BTW, for Sparc we may wish to inherit the CSYNC setting from
> default_var.

Sounds like a nice idea.

If you have a patch that you would like to have tested, feel free to mail 
me.

Cheers,
FJP

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Thursday 17 February 2005 06:10, Frans Pop wrote:
> On Wednesday 16 February 2005 16:51, David S. Miller wrote:
> > On Wed, 16 Feb 2005 19:27:57 +0800 Antonino A. Daplas wrote:
> > > Nope, those are proposed options.  If nobody disagrees, I can easily
> > > add this for atyfb.
> >
> > Please do.
> >
> > BTW, for Sparc we may wish to inherit the CSYNC setting from
> > default_var.
>
> Sounds like a nice idea.
>
> If you have a patch that you would like to have tested, feel free to mail
> me.

Try this patch and let me know. 

video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>

n = 0 (low), 1 (high)

Tony

diff -Nru a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
--- a/drivers/video/aty/atyfb_base.c	2005-02-16 00:19:00 +08:00
+++ b/drivers/video/aty/atyfb_base.c	2005-02-17 06:56:29 +08:00
@@ -307,6 +307,9 @@
 static int pll;
 static int mclk;
 static int xclk;
+static int comp_sync __initdata = -1;
+static int vert_sync __initdata = -1;
+static int hor_sync  __initdata = -1;
 static char *mode;
 
 #ifdef CONFIG_PPC
@@ -2527,6 +2530,27 @@
 	else
 		var.accel_flags |= FB_ACCELF_TEXT;
 
+	if (comp_sync != -1) {
+		if (!comp_sync)
+			var.sync &= ~FB_SYNC_COMP_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_COMP_HIGH_ACT;
+	}
+
+	if (vert_sync != -1) {
+		if (!vert_sync)
+			var.sync &= ~FB_SYNC_VERT_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_VERT_HIGH_ACT;
+	}
+
+	if (hor_sync != -1) {
+		if (!hor_sync)
+			var.sync &= ~FB_SYNC_HOR_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_HOR_HIGH_ACT;
+	}
+
 	if (var.yres == var.yres_virtual) {
 		u32 videoram = (info->fix.smem_len - (PAGE_SIZE << 2));
 		var.yres_virtual = ((videoram * 8) / var.bits_per_pixel) / var.xres_virtual;
@@ -3611,6 +3635,12 @@
 			mclk = simple_strtoul(this_opt + 5, NULL, 0);
 		else if (!strncmp(this_opt, "xclk:", 5))
 			xclk = simple_strtoul(this_opt+5, NULL, 0);
+		else if (!strncmp(this_opt, "comp_sync:", 10))
+			comp_sync = simple_strtoul(this_opt+7, NULL, 0);
+		else if (!strncmp(this_opt, "vert_sync:", 10))
+			vert_sync = simple_strtoul(this_opt+7, NULL, 0);
+		else if (!strncmp(this_opt, "hor_sync:", 9))
+			hor_sync = simple_strtoul(this_opt+7, NULL, 0);
 #ifdef CONFIG_PPC
 		else if (!strncmp(this_opt, "vmode:", 6)) {
 			unsigned int vmode =
@@ -3701,6 +3731,12 @@
 MODULE_PARM_DESC(mclk, "int: override memory clock");
 module_param(xclk, int, 0);
 MODULE_PARM_DESC(xclk, "int: override accelerated engine clock");
+module_param(comp_sync, int, 0)
+MODULE_PARM_DESC(comp_sync, "Set composite sync signal to low (0) or high (1)");
+module_param(vert_sync, int, 0)
+MODULE_PARM_DESC(vert_sync, "Set vertical sync signal to low (0) or high (1)");
+module_param(hor_sync, int, 0)
+MODULE_PARM_DESC(hor_sync, "Set horizontal sync signal to low (0) or high (1)");
 module_param(mode, charp, 0);
 MODULE_PARM_DESC(mode, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
 #ifdef CONFIG_MTRR

Re: [Linux-fbdev-devel] Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Thursday 17 February 2005 07:02, Antonino A. Daplas wrote:
> On Thursday 17 February 2005 06:10, Frans Pop wrote:
> > On Wednesday 16 February 2005 16:51, David S. Miller wrote:
> > > On Wed, 16 Feb 2005 19:27:57 +0800 Antonino A. Daplas wrote:
> > > > Nope, those are proposed options.  If nobody disagrees, I can easily
> > > > add this for atyfb.
> > >
> > > Please do.
> > >
> > > BTW, for Sparc we may wish to inherit the CSYNC setting from
> > > default_var.
> >
> > Sounds like a nice idea.
> >
> > If you have a patch that you would like to have tested, feel free to mail
> > me.
>
> Try this patch and let me know.

The previous patch has a bug, try this instead.

Tony

diff -Nru a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
--- a/drivers/video/aty/atyfb_base.c	2005-02-16 00:19:00 +08:00
+++ b/drivers/video/aty/atyfb_base.c	2005-02-17 07:15:57 +08:00
@@ -307,6 +307,9 @@
 static int pll;
 static int mclk;
 static int xclk;
+static int comp_sync __initdata = -1;
+static int vert_sync __initdata = -1;
+static int hor_sync  __initdata = -1;
 static char *mode;
 
 #ifdef CONFIG_PPC
@@ -2527,6 +2530,27 @@
 	else
 		var.accel_flags |= FB_ACCELF_TEXT;
 
+	if (comp_sync != -1) {
+		if (!comp_sync)
+			var.sync &= ~FB_SYNC_COMP_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_COMP_HIGH_ACT;
+	}
+
+	if (vert_sync != -1) {
+		if (!vert_sync)
+			var.sync &= ~FB_SYNC_VERT_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_VERT_HIGH_ACT;
+	}
+
+	if (hor_sync != -1) {
+		if (!hor_sync)
+			var.sync &= ~FB_SYNC_HOR_HIGH_ACT;
+		else
+			var.sync |= FB_SYNC_HOR_HIGH_ACT;
+	}
+
 	if (var.yres == var.yres_virtual) {
 		u32 videoram = (info->fix.smem_len - (PAGE_SIZE << 2));
 		var.yres_virtual = ((videoram * 8) / var.bits_per_pixel) / var.xres_virtual;
@@ -3611,6 +3635,12 @@
 			mclk = simple_strtoul(this_opt + 5, NULL, 0);
 		else if (!strncmp(this_opt, "xclk:", 5))
 			xclk = simple_strtoul(this_opt+5, NULL, 0);
+		else if (!strncmp(this_opt, "comp_sync:", 10))
+			comp_sync = simple_strtoul(this_opt+10, NULL, 0);
+		else if (!strncmp(this_opt, "vert_sync:", 10))
+			vert_sync = simple_strtoul(this_opt+10, NULL, 0);
+		else if (!strncmp(this_opt, "hor_sync:", 9))
+			hor_sync = simple_strtoul(this_opt+9, NULL, 0);
 #ifdef CONFIG_PPC
 		else if (!strncmp(this_opt, "vmode:", 6)) {
 			unsigned int vmode =
@@ -3701,6 +3731,12 @@
 MODULE_PARM_DESC(mclk, "int: override memory clock");
 module_param(xclk, int, 0);
 MODULE_PARM_DESC(xclk, "int: override accelerated engine clock");
+module_param(comp_sync, int, 0)
+MODULE_PARM_DESC(comp_sync, "Set composite sync signal to low (0) or high (1)");
+module_param(vert_sync, int, 0)
+MODULE_PARM_DESC(vert_sync, "Set vertical sync signal to low (0) or high (1)");
+module_param(hor_sync, int, 0)
+MODULE_PARM_DESC(hor_sync, "Set horizontal sync signal to low (0) or high (1)");
 module_param(mode, charp, 0);
 MODULE_PARM_DESC(mode, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
 #ifdef CONFIG_MTRR

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Thursday 17 February 2005 07:02, Antonino A. Daplas wrote:
> On Thursday 17 February 2005 06:10, Frans Pop wrote:
> > On Wednesday 16 February 2005 16:51, David S. Miller wrote:
> > > On Wed, 16 Feb 2005 19:27:57 +0800 Antonino A. Daplas wrote:
> > > > Nope, those are proposed options.  If nobody disagrees, I can easily
> > > > add this for atyfb.
> > >
> > > Please do.
> > >
> > > BTW, for Sparc we may wish to inherit the CSYNC setting from
> > > default_var.
> >
> > Sounds like a nice idea.
> >
> > If you have a patch that you would like to have tested, feel free to mail
> > me.
>
> Try this patch and let me know.
>
> video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
>
> n = 0 (low), 1 (high)

BTW, the mode string should always be the last parameter, ie;

video=atyfb:comp_sync:1,1024x768@70

Tony

Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Frans Pop]

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

On Thursday 17 February 2005 00:24, Antonino A. Daplas wrote:
> > Try this patch and let me know.
> >
> > video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
> >
> > n = 0 (low), 1 (high)

I've tested with the following combinations:
- append="video=atyfb:comp_sync:1,1024x768@70"
  Works perfectly: csync is high and good display.
- append="video=atyfb:comp_sync:1,hor_sync:1,vert_sync:0,1024x768@70"
  csync is high, but for some reason not hsync; display is good.
- append="video=atyfb:1024x768@70,comp_sync:1"
  Same results as first test.

The sync settings were checked with 'fbset -i'.

> BTW, the mode string should always be the last parameter, ie;
>
> video=atyfb:comp_sync:1,1024x768@70

Hmmm. Wonder why you say that (considering the result of my last test).

Should these new options also be documented in Documentation/fb/?

Cheers,
Frans

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re: [atyfb] No display on Sparc Ultra 10 with kernel 2.6.10-rc2 or later

[Antonino A. Daplas]

On Thursday 17 February 2005 22:16, Frans Pop wrote:
> On Thursday 17 February 2005 00:24, Antonino A. Daplas wrote:
> > > Try this patch and let me know.
> > >
> > > video=atyfb:comp_sync:<n>,vert_sync:<n>,hor_sync:<n>
> > >
> > > n = 0 (low), 1 (high)
>
> I've tested with the following combinations:
> - append="video=atyfb:comp_sync:1,1024x768@70"
>   Works perfectly: csync is high and good display.
> - append="video=atyfb:comp_sync:1,hor_sync:1,vert_sync:0,1024x768@70"
>   csync is high, but for some reason not hsync; display is good.

Okay, it seems that overriding the vsync and hsync settings is useless in
atyfb as it has its own algo to do that:

	if(vdisplay < 400) {
		h_sync_pol = 1;
		v_sync_pol = 0;
	} else if(vdisplay < 480) {
		h_sync_pol = 0;
		v_sync_pol = 1;
	} else if(vdisplay < 768) {
		h_sync_pol = 0;
		v_sync_pol = 0;
	} else {
		h_sync_pol = 1;
		v_sync_pol = 1;
	}

I'll trim the patch for csync only.

> - append="video=atyfb:1024x768@70,comp_sync:1"
>   Same results as first test.
>
> The sync settings were checked with 'fbset -i'.
>
> > BTW, the mode string should always be the last parameter, ie;
> >
> > video=atyfb:comp_sync:1,1024x768@70
>
> Hmmm. Wonder why you say that (considering the result of my last test).

My mistake then.  Thanks for verifying.

>
> Should these new options also be documented in Documentation/fb/?

I'll add this and fix a few buglets when I push upstream.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click