Subject: Re: Framebuffer driver on Assabet

From: [email-masked]
Date: Mon, 8 May 2000 12:11:22 -0400

I'm currently running it with Microwindows and it works fine.  The one thing you
have to remember is that it is a "reflective" LCD, meaning you need a light
source to be able to see much.  Unfortunately Intel didn't include the
appropriate
circuits to drive the front light included on the Sharp LCD, which means you are
forced to depend on ambient light.  You must compile microwindows with a
configuration that does not have keyboard or mouse/touchscreen support.
Other than that it just works.  The touch screen support should be available
real
soon now.

Erik

Jeff Sutherland <[email-masked]> on 05/08/2000 10:46:34 AM

To:   "Linux ARM kernel mailing list (E-mail)"
      <[email-masked]>
cc:    (bcc: Erik Bunce/USER/US/LHS)
Fax to:
Subject:  Framebuffer driver on Assabet

I thought someone mentioned that the frame buffer device on the Assabet was
fixed in 2.3.99-pre6.  I didn't notice any difference from the operation of
-pre3.  Also I was under the impression that it was a rather simple fix.
Could someone advise, please...

Thanks.
//Jeff

unsubscribe: body of `unsubscribe linux-arm-kernel' to
[email-masked]

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Jeff Sutherland <[email-masked]>
Date: Mon, 8 May 2000 15:18:33 -0400

> On Mon, 8 May 2000, Jeff Sutherland wrote:
> 
> > OK, well I'm glad it works, just wish I could get either 
> one of our Assabets
> > to function.  Nicolas Pitre said it had something to do 
> with a missing
> > BCR_clear(BCR_LCD_12RGB); instruction (clears Assabet's board config
> > register bit 10 which is supposed to put the CPLD into 16 
> bit mode).  OK,
> > where would this instruction go?  Grepping for it shows 
> it's in sa1100fb.c
> > at a seemingly appropriate place.  Defines are correct in 
> hardware.h.
> 
> So you have currently known to work code...
> 
> > Display symptoms showing the initial 'splash' image on boot 
> are: top half: 2
> > Penguin images and two blinking cursors; bottom half: alternating
> > black/white horizontal lines of various lengths.  This 
> happens on old style
> > Assabet and newer AssabetPlus with 2.3.99-pre6rmk1np1.  ????
> 
> I guess you might have a different LCD than what the code is 
> configured
> for...
> 
> Nicolas

OK.  I have a Sharp LQ039Q2DS54 on both of these critters (active matrix,
reflective color, 3.9" with integral touch panel).  Wanna bet it's a problem
in the CPLD instead?  Suppose I'll have to go bug the CE guys to see how
they got it working...

//Jeff

---

From: [email-masked]
Date: Mon, 8 May 2000 15:22:44 -0400

Jeff Sutherland writes:
>OK, well I'm glad it works, just wish I could get either one of our Assabets
>to function.  Nicolas Pitre said it had something to do with a missing
>register bit 10 which is supposed to put the CPLD into 16 bit mode).  OK,
>where would this instruction go?  Grepping for it shows it's in sa1100fb.c
>at a seemingly appropriate place.  Defines are correct in hardware.h.
>Display symptoms showing the initial 'splash' image on boot are: top half: 2
>black/white horizontal lines of various lengths.  This happens on old style

What rev/phase of Assabet are you running?  What make/model LCD does it have?
Also what do you mean by AssabetPlus? Do you mean an Assabet w/ Neponsett
attached?

It sounds like a mismatch with your LCD, or possibly a bad LCD cable.
The working Assabets we have are all phase 4 boards w/ Sharp LCD Model
#LQ039Q2DS54
(data sheet at
http://www.sharpsma.com/datasheets/displays/tft/lq039q2ds54_d.pdf).

Erik

---

From: George France <[email-masked]>
Date: Tue, 9 May 2000 16:33:07 -0400

I think that Jamey Hicks [email-masked] has already submitted a patch to
Nicolas Pitre [[email-masked]]for this problem. You should e-mail one of them
or ask on the SA1100 mailing list.

--George

George France,      [email-masked]
Cambridge Research Laboratory, Compaq Computer Corporation
One Kendall Square, Building 700     MS: CRL
Cambridge, MA 02139 USA
Phone: (617) 551-7665 
FAX: (617) 551-7650

-----Original Message-----
From: Jeff Sutherland [mailto:[email-masked]]
Sent: Tuesday, May 09, 2000 4:23 PM
To: [email-masked]'
Cc: 'Linux ARM kernel mailing list (E-mail)'
Subject: RE: Framebuffer driver on Assabet

Ok, folks, I think I'm getting a handle on this.  The basic problem it seems
is that I have a display (and its controller implemented in a CPLD) thinking
it's a 16bpp device (which it is) looking at a frame buffer which is
configured with a 512 byte palette and loaded with an 8bpp image.  The
display *really* wants to see a frame buffer with no palette at the front
loaded with a 16bpp image, I believe.  Looking closely at the image on the
display (and after analyzing debug output from sa1100fb.c) it's apparent
that this is what's going on.  For most of the first scan line there's
random data (the palette) followed by about 1/2 screen of a double image,
then the rest is whatever DCAR1 is finding out beyond the end of the loaded
image until the frame pulse hits.  If "16" is not valid for
current_par.max_bpp, what's the magic fix?

//Jeff

---

From: Jeff Sutherland <[email-masked]>
Date: Tue, 9 May 2000 16:58:27 -0400

> On Tue, 9 May 2000, Jeff Sutherland wrote:
> 
> > loaded with a 16bpp image, I believe.
> 
> However if you configure the LCD controller for 8 bpp which the code
> currently does, it should work anyway.  It apparently works for some
> people at least.
> 
> Of course a proper 16 bpp mode support would be the best solution...
> 
> 
> 
> Nicolas

Hmm...  How does one set the controller for 8 bit mode?  The documentation
says it depends on the setting of BCR bit 10, but changing it seems to have
no effect.  ie, do a BCR_set() as opposed to BCR_clear()...
//Jeff

---

From: James Hicks <[email-masked]>
Date: Tue, 9 May 2000 18:38:28 -0400

I don't know what happened to the patch I submitted, so here it is again.

The key bits (other than my changes to the debug messages and additions for
a development board I'm porting to) are:
1) Config.in -- enable 16bit by default for SA1100FB.
2) Set palette size to 0 for truecolor (allocation fails if size is -1)
3) Skip palette operations for truecolor.
4) In the platform specific code, make sure LCCR0, ..., LCCR3 are set up properly (active/passive, etc)
5) Make sure you enable all the GPIO's needed for a 16bit LCD

If you enable console on virtual terminal, you should see the penguin when
it boots.  I also enabled console on serial port and passed console=0 on
the kernel commandline so I could see the debug messages even though the
LCD was not working.

-Jamey

Patch wrt 2.3.99-pre6-rmk1-np2:

Index: drivers/video/Config.in
===================================================================
RCS file: /cvs/linux/kernel/drivers/video/Config.in,v
retrieving revision 1.1.1.3
retrieving revision 1.4
diff -r1.1.1.3 -r1.4
253c253,254
< 	   "$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_3DFX" = "y" ]; then
---
> 	   "$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_3DFX" = "y"  -o \
> 	   "$CONFIG_FB_SA1100" = "y" ]; then
265c266,267
< 	      "$CONFIG_FB_CYBER2000" = "m" ]; then
---
> 	      "$CONFIG_FB_CYBER2000" = "m"  -o \
> 	      "$CONFIG_FB_SA1100" = "m"]; then
Index: drivers/video//sa1100fb.c
===================================================================
RCS file: /cvs/linux/kernel/drivers/video/sa1100fb.c,v
retrieving revision 1.1.1.3
diff -r1.1.1.3 sa1100fb.c
56c56
< // #define DEBUG 
---
> #define DEBUG 
58c58
< #  define DPRINTK(fmt, args...)	printk(KERN_DEBUG "%s: " fmt, __FUNCTION__ , ## args)
---
> #  define DPRINTK(fmt, args...)	printk("%s: " fmt, __FUNCTION__ , ## args)
86c86
< #define SA1100_NAME	"SA1100"
---
> #define SA1100_NAME	"SA1100"
269a270
>         DPRINTK("current_par.visual=%d\n", current_par.visual);
285a287
>         DPRINTK("current_par.visual=%d\n", current_par.visual);
323a326
>         DPRINTK("var->bits_per_pixel=%d\n", var->bits_per_pixel);
379a383
>         DPRINTK("par->bits_per_pixel=%d\n", par->bits_per_pixel);
396c400
< 		par->palette_size = -1; 
---
> 		par->palette_size = 0; 
397a402,403
> #else
> #error NO FBCON_HAS_CFB16
423a430
>         DPRINTK("con=%d\n", con);
475a483
> 	DPRINTK("chgvar=%d\n", chgvar);
489a498,499
>         DPRINTK("display->var.bits_per_pixel=%d xres=%d yres=%d display->dispsw=%p\n", 
>                 display->var.bits_per_pixel, var->xres, var->yres, display->dispsw);
516,517c526,528
< 	/* If the current console is selected, update the palette */
< 	if (con == current_par.currcon) {
---
>         // If the current console is selected and it's not truecolor, update the palette 
> 	if ((con == current_par.currcon) && (current_par.visual != FB_VISUAL_TRUECOLOR))
>         {
524a536
>                 DPRINTK("visual=%d palette_size=%d cmap=%p\n", current_par.visual, current_par.palette_size, cmap);
608a621,628
> 	} else if (machine_is_bitsy()) {
> 		current_par.max_xres	= 320;
> 		current_par.max_yres	= 240;
> 		current_par.max_bpp	= 16;
> 		init_var.red.length	   = 5;
> 		init_var.green.length	   = 6;
> 		init_var.blue.length	   = 5;
> 		init_var.grayscale	   = 0;
703a724,725
> 	DPRINTK("-1-");
733a756
> 	memset(VideoMemRegion_phys, 0xAA, ALLOCATED_FB_MEM_SIZE);
756a780
> #ifdef CONFIG_SA1100_TIFON
765a790
> #endif
776c801,804
< 	int pcd = get_pcd(var->pixclock);
---
> 	int pcd = 0;
> #ifdef CONFIG_SA1100_TIFON
> 	pcd = get_pcd(var->pixclock);
> #endif
782a811,812
> 	DPRINTK("activating\n");
806a837,850
> 	} else if (machine_is_bitsy()) {
> 		DPRINTK("Configuring  Bitsy LCD\n");
> 		lcd_shadow.lccr0 = LCCR0_LEN + LCCR0_Color + LCCR0_Sngl + LCCR0_Act +
> 				   LCCR0_LtlEnd + LCCR0_LDM + LCCR0_BAM + LCCR0_ERM + 
> 				   LCCR0_DMADel(0);
> 		lcd_shadow.lccr1 = LCCR1_DisWdth( var->xres ) +
> 				   LCCR1_HorSnchWdth( 4 ) +
> 				   LCCR1_BegLnDel( 0x1f ) +
> 				   LCCR1_EndLnDel( 0x1f );
> 		lcd_shadow.lccr2 = LCCR2_DisHght( var->yres ) +
> 				   LCCR2_VrtSnchWdth( 1 )+
> 				   LCCR2_BegFrmDel( 0 ) +
> 				   LCCR2_EndFrmDel( 0 );
> 		lcd_shadow.lccr3 = 15;
935c979
< 	DPRINTK("sa1100fb:  Disabling LCD controller\n");
---
>         DPRINTK("Disabling LCD controller\n");
940c984
< 		DPRINTK("sa1100fb: LCD already disabled\n");
---
> 		DPRINTK("LCD already disabled\n");
947a992,993
> 	} else if (machine_is_bitsy()) {
> 	        clr_bitsy_egpio(EGPIO_BITSY_LCD_ON | EGPIO_BITSY_LCD_PCI | EGPIO_BITSY_LCD_5V_ON | EGPIO_BITSY_LVDD_ON);
975a1022
>         printk(__FUNCTION__ ": state=%d", current_par.controller_state);
981c1028
< 		DPRINTK("sa1100fb: Enabling LCD controller\n");
---
> 		DPRINTK("Enabling LCD controller\n");
999a1047,1053
> 		} else if (machine_is_bitsy()) {
>                         set_bitsy_egpio(EGPIO_BITSY_LCD_ON | EGPIO_BITSY_LCD_PCI | EGPIO_BITSY_LCD_5V_ON | EGPIO_BITSY_LVDD_ON)
> 			DPRINTK("DBAR1=%p\n", DBAR1);
> 			DPRINTK("LCCR0=%x\n", LCCR0);
> 			DPRINTK("LCCR1=%x\n", LCCR1);
> 			DPRINTK("LCCR2=%x\n", LCCR2);
> 			DPRINTK("LCCR3=%x\n", LCCR3);
1054a1109
>   	DPRINTK("blank=%d info->modename=%s\n", blank, info->modename);
1060a1116
>                 if (current_par.visual != FB_VISUAL_TRUECOLOR)
1064a1121
> #warning Bitsy support for blanking display
1076d1132
< 	struct fb_cmap *cmap;
1077a1134,1136
>   	DPRINTK("con=%d info->modename=%s\n", con, info->modename);
>         if (current_par.visual != FB_VISUAL_TRUECOLOR) {
>                 struct fb_cmap *cmap;
1084a1144
>         }
1087a1148
> 	DPRINTK("fb_display[%d].var.activate=%x\n", con, fb_display[con].var.activate);
1116a1178,1181
> 	} else if (machine_is_penny()) {
> #warning Configure GPIO for Bitsy LCD
> 		GPDR = GPIO_LDD15 | GPIO_LDD14 | GPIO_LDD13 | GPIO_LDD12 | GPIO_LDD11 | GPIO_LDD10 | GPIO_LDD9 | GPIO_LDD8;
> 		GAFR = GPIO_LDD15 | GPIO_LDD14 | GPIO_LDD13 | GPIO_LDD12 | GPIO_LDD11 | GPIO_LDD10 | GPIO_LDD9 | GPIO_LDD8;