Re: PXA frame buffer not enabled in 1 bit per pixel mode.

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.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642