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.