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

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


-------------------------------------------------------
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