linux-fbdev-users

[Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[James S. <jam...@op...>]

Hi All,

Please note that I am now a suscribed member so if a previous email of
the same subject does make it through the moderator, ignore it.

I have a question regarding the PXA framebuffer support.  I've emailed
the ARM linux list but to no avail.  We've configured uboot to talk to
the LCD connected to our board and the LCD works fine.

Setting up the pxafb for the kernel is proving somewhat more testing.
Kernel is 2.6.15.1 with no patches to the video drivers.

My current modprobe looks like this;
modprobe pxafb \
options=mode:320x240-1,mono,single,vsynclen:3,hsynclen:1,left:1, \
right:1,upper:1,lower:1,vsync:1,hsync:1,pixclockpol:0,4pix, \
pixclock:643023

This gives the same LCCRX register setup as uboot was configured for,
with just 2 differences.
LCCR0_PDD=1 in uboot, =0 from pxafb.
LCCR0_QDM=0 in uboot, =1 from pxafb.

I forced LCCR0_PDD on but with no effect.

I turned on some debugging and got the following;
pxa2xx-fb pxa2xx-fb: overriding resolution: 320x240
pxa2xx-fb pxa2xx-fb: overriding bit depth: 1
pxa2xx-fb pxa2xx-fb: override vsynclen: 3
pxa2xx-fb pxa2xx-fb: override hsynclen: 1
pxa2xx-fb pxa2xx-fb: override left: 1
pxa2xx-fb pxa2xx-fb: override right: 1
pxa2xx-fb pxa2xx-fb: override upper: 1
pxa2xx-fb pxa2xx-fb: override lower: 1
pxa2xx-fb pxa2xx-fb: override vsync: Active High
pxa2xx-fb pxa2xx-fb: override hsync: Active High
pxa2xx-fb pxa2xx-fb: override pixel clock polarity: falling edge
pxa2xx-fb pxa2xx-fb: override pixclock: 643023
pxa2xx-fb pxa2xx-fb: Upper and lower margins must be 0 in passive mode

*** Why is this so?  It worked with uboot with these settings!***

pxafb: palette_mem_size = 0x00000020
pxafb: set_par
pxafb: palette_mem_size = 0x00000008
pxafb: true_color = 0
pxafb: Configuring PXA LCD
var: xres=320 hslen=1 lm=1 rm=1
var: yres=240 vslen=3 um=1 bm=1
var: pixclock=643023 pcd=32
nlccr0 = 0x0030187a
nlccr1 = 0x0000013f
nlccr2 = 0x010108ef
nlccr3 = 0x00400020
pxafb: Enabling LCD controller
fdadr0 0xa7fd4fe8
fdadr1 0xa7fd4fc8
reg_lccr0 0x0030187a
reg_lccr1 0x0000013f
reg_lccr2 0x010108ef
reg_lccr3 0x00400020
FDADR0 0xa7fd4fe0
FDADR1 0xa7fd4fc0
LCCR0 0x0030187b
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020
pxafb: LCD power on
pxafb: backlight on

However when I run pxaregs LCCR0 I find that the LCCR0_ENB is not set -
but the debug shows it was set by the driver.

So who's disabling the FB?

If I spec 320x240-8, the enable bit stays set and I get a screen full of
beautiful vertical lines about 4 pixels appart - not very useful.

Any ideas where I'm going wrong?

I did RTFM and googled too but still don't see what the problem is.

Regards,
James.

[Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[James S. <jam...@op...>]

Hi All,

Please note that I am not a suscribed member so please reply direct to
me (jamessteward_AT_optusnet.com.au replacing the _AT_ with you know
what :-)

I have a question regarding the PXA framebuffer support.  I've emailed
the ARM linux list but to no avail.  We've configured uboot to talk to
the LCD connected to our board and the LCD works fine.

Setting up the pxafb for the kernel is proving somewhat more testing.

My current modprobe looks like this;
modprobe pxafb \
options=mode:320x240-1,mono,single,vsynclen:3,hsynclen:1,left:1, \
right:1,upper:1,lower:1,vsync:1,hsync:1,pixclockpol:0,4pix, \
pixclock:643023

This gives the same LCCRX register setup as uboot was configured for,
with just 2 differences.
LCCR0_PDD=1 in uboot, =0 from pxafb.
LCCR0_QDM=0 in uboot, =1 from pxafb.

I forced LCCR0_PDD on but with no effect.

I turned on some debugging and got the following;
pxa2xx-fb pxa2xx-fb: overriding resolution: 320x240
pxa2xx-fb pxa2xx-fb: overriding bit depth: 1
pxa2xx-fb pxa2xx-fb: override vsynclen: 3
pxa2xx-fb pxa2xx-fb: override hsynclen: 1
pxa2xx-fb pxa2xx-fb: override left: 1
pxa2xx-fb pxa2xx-fb: override right: 1
pxa2xx-fb pxa2xx-fb: override upper: 1
pxa2xx-fb pxa2xx-fb: override lower: 1
pxa2xx-fb pxa2xx-fb: override vsync: Active High
pxa2xx-fb pxa2xx-fb: override hsync: Active High
pxa2xx-fb pxa2xx-fb: override pixel clock polarity: falling edge
pxa2xx-fb pxa2xx-fb: override pixclock: 643023
pxa2xx-fb pxa2xx-fb: Upper and lower margins must be 0 in passive mode

*** Why is this so?  It worked with uboot with these settings!***

pxafb: palette_mem_size = 0x00000020
pxafb: set_par
pxafb: palette_mem_size = 0x00000008
pxafb: true_color = 0
pxafb: Configuring PXA LCD
var: xres=320 hslen=1 lm=1 rm=1
var: yres=240 vslen=3 um=1 bm=1
var: pixclock=643023 pcd=32
nlccr0 = 0x0030187a
nlccr1 = 0x0000013f
nlccr2 = 0x010108ef
nlccr3 = 0x00400020
pxafb: Enabling LCD controller
fdadr0 0xa7fd4fe8
fdadr1 0xa7fd4fc8
reg_lccr0 0x0030187a
reg_lccr1 0x0000013f
reg_lccr2 0x010108ef
reg_lccr3 0x00400020
FDADR0 0xa7fd4fe0
FDADR1 0xa7fd4fc0
LCCR0 0x0030187b
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020
pxafb: LCD power on
pxafb: backlight on

However when I run pxaregs LCCR0 I find that the LCCR0_ENB is not set -
but the debug shows it was set by the driver.

So who's disabling the FB?

If I spec 320x240-8, the enable bit stays set and I get a screen full of
beautiful vertical lines about 4 pixels appart - not very useful.

Any ideas where I'm going wrong?

I did RTFM and googled too but still don't see what the problem is.

Regards,
James.

Re: [Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[Antonino A. D. <ad...@gm...>]

James Steward wrote:
> Hi All,
> 
> Please note that I am now a suscribed member so if a previous email of
> the same subject does make it through the moderator, ignore it.
> 
> I have a question regarding the PXA framebuffer support.  I've emailed
> the ARM linux list but to no avail.  We've configured uboot to talk to
> the LCD connected to our board and the LCD works fine.
> 
> Setting up the pxafb for the kernel is proving somewhat more testing.
> Kernel is 2.6.15.1 with no patches to the video drivers.
> 
> My current modprobe looks like this;
> modprobe pxafb \
> options=mode:320x240-1,mono,single,vsynclen:3,hsynclen:1,left:1, \
> right:1,upper:1,lower:1,vsync:1,hsync:1,pixclockpol:0,4pix, \
> pixclock:643023
> 
> This gives the same LCCRX register setup as uboot was configured for,
> with just 2 differences.
> LCCR0_PDD=1 in uboot, =0 from pxafb.
> LCCR0_QDM=0 in uboot, =1 from pxafb.
> 
> I forced LCCR0_PDD on but with no effect.
> 
> I turned on some debugging and got the following;
> pxa2xx-fb pxa2xx-fb: overriding resolution: 320x240
> pxa2xx-fb pxa2xx-fb: overriding bit depth: 1
> pxa2xx-fb pxa2xx-fb: override vsynclen: 3
> pxa2xx-fb pxa2xx-fb: override hsynclen: 1
> pxa2xx-fb pxa2xx-fb: override left: 1
> pxa2xx-fb pxa2xx-fb: override right: 1
> pxa2xx-fb pxa2xx-fb: override upper: 1
> pxa2xx-fb pxa2xx-fb: override lower: 1
> pxa2xx-fb pxa2xx-fb: override vsync: Active High
> pxa2xx-fb pxa2xx-fb: override hsync: Active High
> pxa2xx-fb pxa2xx-fb: override pixel clock polarity: falling edge
> pxa2xx-fb pxa2xx-fb: override pixclock: 643023
> pxa2xx-fb pxa2xx-fb: Upper and lower margins must be 0 in passive mode
> 
> *** Why is this so?  It worked with uboot with these settings!***

These are just over-verbose messages...

> 
> pxafb: palette_mem_size = 0x00000020
> pxafb: set_par
> pxafb: palette_mem_size = 0x00000008
> pxafb: true_color = 0
> pxafb: Configuring PXA LCD
> var: xres=320 hslen=1 lm=1 rm=1
> var: yres=240 vslen=3 um=1 bm=1
> var: pixclock=643023 pcd=32
> nlccr0 = 0x0030187a
> nlccr1 = 0x0000013f
> nlccr2 = 0x010108ef
> nlccr3 = 0x00400020
> pxafb: Enabling LCD controller
> fdadr0 0xa7fd4fe8
> fdadr1 0xa7fd4fc8
> reg_lccr0 0x0030187a
> reg_lccr1 0x0000013f
> reg_lccr2 0x010108ef
> reg_lccr3 0x00400020
> FDADR0 0xa7fd4fe0
> FDADR1 0xa7fd4fc0
> LCCR0 0x0030187b
> LCCR1 0x0000013f
> LCCR2 0x010108ef
> LCCR3 0x00400020
> pxafb: LCD power on
> pxafb: backlight on
> 
> However when I run pxaregs LCCR0 I find that the LCCR0_ENB is not set -
> but the debug shows it was set by the driver.
> 
> So who's disabling the FB?

Try unconditinally calling pxafb_schedule_work() in pxafb_activate_var().
Then reread the register.

Tony

Re: [Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[James S. <jam...@op...>]

On Fri, 2006-02-17 at 17:31 +0800, Antonino A. Daplas wrote:
> James Steward wrote:
> > pxa2xx-fb pxa2xx-fb: Upper and lower margins must be 0 in passive mode
> > 
> > *** Why is this so?  It worked with uboot with these settings!***
> 
> These are just over-verbose messages...

Ok, I'll ignore then.

> > So who's disabling the FB?
> 
> Try unconditinally calling pxafb_schedule_work() in pxafb_activate_var().
> Then reread the register.
> 

Thanks Tony!  I'll give it a try first thing Monday morning.

Regards,
James.

Re: [Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[James S. <jam...@op...>]

On Sat, 2006-02-18 at 12:52 +1100, James Steward wrote:
> On Fri, 2006-02-17 at 17:31 +0800, Antonino A. Daplas wrote:
> > James Steward wrote:
> > > pxa2xx-fb pxa2xx-fb: Upper and lower margins must be 0 in passive mode
> > > 
> > > *** Why is this so?  It worked with uboot with these settings!***
> > 
> > These are just over-verbose messages...
> 
> Ok, I'll ignore then.
> 
> > > So who's disabling the FB?
> > 
> > Try unconditinally calling pxafb_schedule_work() in pxafb_activate_var().
> > Then reread the register.
> > 
> 
> Thanks Tony!  I'll give it a try first thing Monday morning.
> 
Sorry Tony but that didn't seem to do anything for me.
I've since added more debuggery...

pxafb: Configuring PXA LCD
var: xres=320 hslen=1 lm=1 rm=1
var: yres=240 vslen=3 um=1 bm=1
var: pixclock=643023 pcd=32
nlccr0 = 0x0030187a          <-- The enable bit[0] is not set.
nlccr1 = 0x0000013f
nlccr2 = 0x010108ef
nlccr3 = 0x00400020
fbi->dmadesc_fblow_cpu = 0xffc00fc8
fbi->dmadesc_fbhigh_cpu = 0xffc00fd8
fbi->dmadesc_palette_cpu = 0xffc00fe8
fbi->dmadesc_fblow_dma = 0xa73f0fc8
fbi->dmadesc_fbhigh_dma = 0xa73f0fd8
fbi->dmadesc_palette_dma = 0xa73f0fe8
fbi->dmadesc_fblow_cpu->fdadr = 0xa73f0fc8
fbi->dmadesc_fbhigh_cpu->fdadr = 0xa73f0fe8
fbi->dmadesc_palette_cpu->fdadr = 0xa73f0fd8
fbi->dmadesc_fblow_cpu->fsadr = 0xa73f3580
fbi->dmadesc_fbhigh_cpu->fsadr = 0xa73f1000
fbi->dmadesc_palette_cpu->fsadr = 0xa73f0ff8
fbi->dmadesc_fblow_cpu->ldcmd = 0x2580
fbi->dmadesc_fbhigh_cpu->ldcmd = 0x2580
fbi->dmadesc_palette_cpu->ldcmd = 0x4000008
pxafb: Enabling LCD controller
fdadr0 0xa73f0fe8
fdadr1 0xa73f0fc8
reg_lccr0 0x0030187a     <-- The enable bit[0] is still not set.
reg_lccr1 0x0000013f
reg_lccr2 0x010108ef
reg_lccr3 0x00400020
pxafb: End of enabling LCD controller
FDADR0 0x00000000
FDADR1 0xa73f0fc0
LCCR0 0x0030187b        <-- Code in the enable routine sets bit[0]
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020
pxafb: LCD power on
pxafb: backlight on
End of set_ctrlr_state state 7->1   {old state -> new state}
FDADR0 0x00000000
FDADR1 0xa73f0fc0
LCCR0 0x0030187b  <-- bit[0] still set at the end of set_ctrlr_state
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020
End of set_ctrlr_state state 1->1   {old state -> new state}
FDADR0 0xea000210
FDADR1 0xa73f0fc0
LCCR0 0x0030187a  <-- bit[0] for some reason now cleared!!
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020

So set_ctrlr_state is called a second time and afterwards the enable bit
is cleared.

Any further thoughts?

Regards,
James.

Re: [Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[Antonino A. D. <ad...@gm...>]

James Steward wrote:
> On Sat, 2006-02-18 at 12:52 +1100, James Steward wrote:
>> On Fri, 2006-02-17 at 17:31 +0800, Antonino A. Daplas wrote:
>>> James Steward wrote:
> End of set_ctrlr_state state 1->1   {old state -> new state}
> FDADR0 0xea000210
> FDADR1 0xa73f0fc0
> LCCR0 0x0030187a  <-- bit[0] for some reason now cleared!!
> LCCR1 0x0000013f
> LCCR2 0x010108ef
> LCCR3 0x00400020
> 
> So set_ctrlr_state is called a second time and afterwards the enable bit
> is cleared.
> 
> Any further thoughts?

pxafb_set_par is called first by the pxafb before register_framebuffer, then
pxafb_set_par() will be called a second time during fbcon initialization. For
some reason, the second set_par() disables your controller.

Temporarily,  find out first if your driver works. You can comment out the explicit
pxafb_set_par() call in pxafb_probe() (or for correctness sake, enclose  it in #ifndef CONFIG_FRAMEBUFFER_CONSOLE/#endif).

Or, just add something like this in the beginning of pxafb_set_par().

	static int initialized = 0;

	if (initialized)
		return 0;

	initialized = 1;

The above 2 methods will hopefully eliminate the extra call to set_par().

Once you've verified that your driver first, then it's time to debug why the enable bit
is cleared.  

On the first call, the state is CM_STARTUP, on the second call, the state is CM_ENABLE.
You can probably debug how the code differs depending on the state.

Tony

Re: [Linux-fbdev-users] PXA frame buffer not enabled in 1 bit per pixel mode.

[James S. <jam...@op...>]

On Mon, 2006-02-20 at 12:57 +0800, Antonino A. Daplas wrote:
> James Steward wrote:
> > On Mon, 2006-02-20 at 09:03 +0800, Antonino A. Daplas wrote:
> >> James Steward wrote:
> >>> On Mon, 2006-02-20 at 08:28 +0800, Antonino A. Daplas wrote:
> >>>> James Steward wrote:
> >>>>> On Sat, 2006-02-18 at 12:52 +1100, James Steward wrote:
> >>>>>> On Fri, 2006-02-17 at 17:31 +0800, Antonino A. Daplas wrote:
> >>>>>>> James Steward wrote:
> >>>>> End of set_ctrlr_state state 1->1   {old state -> new state}
> >>>>> FDADR0 0xea000210
> >>>>> FDADR1 0xa73f0fc0
> >>>>> LCCR0 0x0030187a  <-- bit[0] for some reason now cleared!!
> >>>>> LCCR1 0x0000013f
> >>>>> LCCR2 0x010108ef
> >>>>> LCCR3 0x00400020
> >>>>>
> >>>>> So set_ctrlr_state is called a second time and afterwards the enable bit
> >>>>> is cleared.
> >>>>>
> >>>>> Any further thoughts?
> >>>> pxafb_set_par is called first by the pxafb before register_framebuffer, then
> >>>> pxafb_set_par() will be called a second time during fbcon initialization. For
> >>>> some reason, the second set_par() disables your controller.
> >>>>
> >>>> Temporarily,  find out first if your driver works. You can comment out the explicit
> >>>> pxafb_set_par() call in pxafb_probe() (or for correctness sake, enclose  it in #ifndef CONFIG_FRAMEBUFFER_CONSOLE/#endif).
> >>>>
> >>>> Or, just add something like this in the beginning of pxafb_set_par().
> >>>>
> >>>> 	static int initialized = 0;
> >>>>
> >>>> 	if (initialized)
> >>>> 		return 0;
> >>>>
> >>>> 	initialized = 1;
> >>> CONFIG_FRAMEBUFFER_CONSOLE doesn't appear in my .config so I tried the
> >>> second method of making sure set_par() is only called once.
> >>>
> >>>> The above 2 methods will hopefully eliminate the extra call to set_par().
> >>>>
> >>>> Once you've verified that your driver first, then it's time to debug why the enable bit
> >>>> is cleared.  
> >>>>
> >>>> On the first call, the state is CM_STARTUP, on the second call, the state is CM_ENABLE.
> >>>> You can probably debug how the code differs depending on the state.
> >>> The debug messages I posted contained all debug messages -  there were
> >>> no snips in between.  set_par() is only called once by the looks.
> >> Okay.
> >>
> >>> The only other place I see set_ctrlr_state() called possibly is
> >>> pxafb_task(), as CONFIG_PM is not set and neither is CONFIG_CPU_FREQ.
> >>>
> >>> So after the initial enable in pxafb_probe(), pxafb_task() is the only
> >>> other candidate I can see.  I'll command out the call to
> >>> set_ctrlr_state() there and see what happens.
> >> pxafb_task is the callback of the workqueue.  Check what functions call
> >> pxafb_schedule_work().
> > 
> >>From further debugging code, I still can't see what calls
> > set_ctrlr_state().  If I comment out the call in pxafb_task() it's not
> > enabled to begin with.
> > 
> > I have noticed that on the last call to set_ctrlr_state() that FDADR0 is
> > changed.
> > 
> > I'm not building any console drivers by the way.
> > 
> 
> I see where set_ctrlr_state() is called.  It's after register_framebuffer() in
> pxafb_probe().

Ok, so it's called near the end of pxafb_probe() as you say, also in
pxafb_task(), as well as pxafb_freq_transition() however CONFIG_CPU_FREQ
is not defined so that doesn't count, neither does the calls in
pxafb_suspend() or pxafb_resume() as CONFIG_PM is not defined.

So it appears the pxafb_probe() happens after the pxafb_task().  I shall
disable the pxafb_probe call and see if it stays enabled.
...rebooting now...

So now the second call to set_ctrlr_state() is commented out, but the
controller is still disabled!

End of set_ctrlr_state state 7->1
FDADR0 0x00000000
FDADR1 0xa7354fc0
LCCR0 0x0030187b    <--looks good here
LCCR1 0x0000013f
LCCR2 0x010108ef
LCCR3 0x00400020

# pxaregs LCCR0
LCD Controller Control Register 0 (7-23)
LCCR0                    0x0030187a  00000000 00110000 00011000 01111010
LCCR0_ENB                         0  LCD controller enable

Not enabled now.

In any case, as the previous state was C_ENABLE and the state sent from
pxafb_probe() is also C_ENABLE, set_ctrlr_state() shouldn't do anything.

So somewhere inbetween is where the disablement is happening.  Feel like
I need a white cane here.  I'm sure the answer is there - I just don't
see it.

Regards,
James.