iMX35 3stack framebuffer problem

[Boaz Ben-David]

Thanks,

I think I will have to be creative on this.
The only GPIO I can use is the same as the LCD contrast pin. 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.

Boaz.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20110529/0d04932d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2930 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20110529/0d04932d/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 510 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20110529/0d04932d/attachment.gif>