[U-Boot] Possible OMAP3 regression with current mainline

[Simon Glass]

Hi Enric,

On 30 January 2015 at 01:10, Enric Balletbo Serra <eballetbo at gmail.com> wrote:
> Hi Simon,
>
> 2015-01-30 2:24 GMT+01:00 Simon Glass <sjg at chromium.org>:
>> Hi Enric,
>>
>> On 26 January 2015 at 10:55, Enric Balletbo Serra <eballetbo at gmail.com> wrote:
>>> I just tried boot with my OMAP3 based board (IGEPv2) and I found that
>>> is broken in current mainline and v2015.01. The boot process stops at
>>>
>>> reading u-boot.img
>>>
>>> Did someone, with another OMAP3 board, have the same problem?
>>>
>>> I bisected the problem and looks that was introduced in following commit.
>>>
>>>   commit b3f4ca1135edd66d14254089bbeb8077c6d0bb72
>>>   dm: omap3: Move to driver model for GPIO and serial
>>>
>>> Reverting the patch boots again. Any clue?
>>
>> It looks like someone else had this problem:
>>
>> http://patchwork.ozlabs.org/patch/433866/
>>
>
> This patch is made by me, I sent this patch :)
>
> But the patch only replaces the use of show_boot_progress for the
> STATUS_LED API, Which is better for that purpose. But the root problem
> is not solved.
>
> Looks like the problem is the gpio_request call inside the function
> show_boot_progress. If I'm not wrong the gpio_request implementation
> is different when device model is used, and for some reason doing a
> gpio_request inside the show_boot_progress function hangs. If I remove
> the gpio_request from show_boot_progress it boots as expected. What's
> the difference between gpio_request implementation when using DM or
> not? Maybe it's a malloc problem?

Well gpio_request() is probably a no-op in the non-driver-model case.

We should call gpio_request() once, in the board init, ideally before
any calls to show_boot_progress(), since otherwise GPIO operations
will fail.

Regards,
Simon