iMX35 3stack framebuffer problem

[Boaz Ben-David]

Hi all,

I haven't been able to solve this problem.
The issue I'm having here is that when I'm using a GPIO to power down 
the LCD during the kernel boot
the flicker had already happened. Meaning, when I finally have control 
over the GPIOs it is too late.
As far as I understand the arch specific code is called in the 
start_kernel function, and what I would like to
do is set the controlling GPIO to low before the setup_arch function is 
called in start_kernel function.
Is that even possible? I've been trying to fiddle around using physical 
addresses to do that but all I achieved is
getting the kernel stuck at boot.

Thanks,

Boaz.

On 05/29/11 10:28, Baruch Siach wrote:
> Hi Boaz,
>
> On Sun, May 29, 2011 at 10:14:27AM +0300, Boaz Ben-David wrote:
>> I think I will have to be creative on this.
>> The only GPIO I can use is the same as the LCD contrast pin.
> You probably mean LCD brightness here. If so, this is probably the best you
> can do if you can't power down the LCD completely with a GPIO.
>
>> I think I need to
>> start it as a GPIO, put 0 on it and after the FB is inited mux it
>> back to LCD contrast function,  if that is possible.
> Ugly, but definitely possible. You have the .enable callback for that.
>
> baruch
>
>> On 05/29/11 09:33, Baruch Siach wrote:
>>> Hi Boaz,
>>>
>>> On Sun, May 29, 2011 at 09:08:58AM +0300, Boaz Ben-David wrote:
>>>> Revisiting the issue below, it there a convinient way
>>>> to use the FB in barebox without creating a flicker on the LCD in
>>>> the transition from Barebox to the kernel?
>>> Probably not, at the moment.
>>>
>>> One big problem (not the only one) is that the mx3fb driver uses DMA to
>>> transfer the display image from the system RAM to the LCD. The ARM booting
>>> document, however, requires the bootloader to "quiesce all DMA capable
>>> devices" (Documentation/arm/Booting).
>>>
>>> The best you can achieve (assuming you have designed your hardware correctly)
>>> is to blank your LCD using a GPIO just before booting the kernel, and then
>>> switch this GPIO again just after painting your logo from the newly boot
>>> kernel.
>>>
>>> baruch
>>>
>>>> On 03/08/11 09:10, Baruch Siach wrote:
>>>>> Hi Boaz,
>>>>>
>>>>> On Tue, Mar 08, 2011 at 09:03:55AM +0200, Boaz Ben-David wrote:
>>>>>> Yes, I am using the freescale kernel unfotunately.
>>>>>> Do you know of some way to fix this (a patch for the freescale kernel
>>>>>> maybe)?
>>>>> A simple way to check whether this is the problems is to just disable the
>>>>> framebuffer in the kernel build, and make sure that you can boot again.
>>>>>
>>>>> Then, the fix for this problem is to move the request_irq() call to the end of
>>>>> the .probe routine.
>>>>>
>>>>> You should not expect any kind of support from Freescale for their released
>>>>> Linux kernels.
>>>>>
>>>>> baruch
>>>>>
>>>>>> On Tue, 2011-03-08 at 16:35 +1100, Marc Reilly wrote:
>>>>>>> On Tuesday, March 08, 2011 03:35:10 am Boaz Ben-David wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When using the iMX35 freescale 3stack we are having some issues with the FB
>>>>>>>> driver. On device boot we enable the fb using "fb0.enable=1" and then try
>>>>>>>> to boot the kernel from nand. The problem is that after the kernel is
>>>>>>>> loaded to RAM and extracted the board hangs. If we do not init the fb0
>>>>>>>> device but simply boot the kernel it works fine. Trying "fb0.enable=0"
>>>>>>>> before booting also did not help.
>>>>>>>> Did anyone encounter this issue yet or are we doing something wrong?
>>>>>>> Are you using the freescale kernel? It doesn't handle loading the IPU driver
>>>>>>> if the IPU has been enabled previously.. (an IRQ fires before all the driver
>>>>>>> structures have been initialized and crashes)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Marc
>>
>> --
>>
>>
>> *Boaz Ben-David*
>> R&D Engineer
>>
>>
>>
>> cid:image001.jpg at 01CBF829.06DE9870
>>
>> *Tel:*+972.2.6470.709
>>
>>
>>
>> *Mob:*+972.54.678.1511**
>>
>>
>>
>> *Email**: *boaz.bd at wellsense-tech.com
>>
>>
>>
>> www.themapsystem.com<redir.aspx?C=e6361e2526464b699e255e33ea5cfebb&URL=http%3a%2f%2fwww.themapsystem.com%2f>
>>
>> cid:image002.gif at 01CBF829.06DE9870 Please consider the impact on the
>> environment before printing this e-mail and/or the attachment(s).
>>
>>
> --
>                                                       ~. .~   Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
>     - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6185 (20110606) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>