On 01/23/2014 10:15 AM, Florian Vaussard wrote:
>
>
> On 01/23/2014 10:00 AM, Tero Kristo wrote:
>> On 01/23/2014 10:14 AM, Florian Vaussard wrote:
>>> Hello,
>>>
>>> On 01/23/2014 07:23 AM, Tero Kristo wrote:
>>>> On 01/23/2014 03:35 AM, Kevin Hilman wrote:
>>>>> On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot <khilman@xxxxxxxxxx>
>>>>> wrote:
>>>>>> Automated DT boot report for various ARM defconfigs.
>>>>>>
>>>>>>
>>>>>> Tree/Branch: next
>>>>>> Git describe: next-20140122
>>>>>> Failed boot tests (console logs at the end)
>>>>>> ===========================================
>>>>>> omap3-tobi,3730storm: FAIL: omap2plus_defconfig
>>>>> [...]
>>>>>> omap3-tobi,3730storm: FAIL: multi_v7_defconfig
>>>>>
>>>>> These OMAP3 failures are new regressions. Full failure boot log
>>>>> attached.
>>>>> Bisected down to:
>>>>>
>>>>> cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit
>>>>> commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39
>>>>> Author: Tero Kristo <t-kristo@xxxxxx>
>>>>> Date: Tue Oct 22 11:53:02 2013 +0300
>>>>>
>>>>> ARM: OMAP2+: io: use new clock init API
>>>>>
>>>>> clk_init is now separated to a common function which gets called
>>>>> for all
>>>>> SoC:s, which initializes the DT clocks and calls the SoC specific
>>>>> clock init.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
>>>>> Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>
>>>>> Signed-off-by: Mike Turquette <mturquette@xxxxxxxxxx>
>>>>>
>>>>> Kevin
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I think this is because the tobi board is including wrong omap3-soc.dtsi
>>>> file (omap34xx.dtsi) through omap3-overo.dtsi.
>>>>
>>>> The board should include omap36xx.dtsi at least based on the boot log:
>>>>
>>>> [ 0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
>>>>
>>>
>>> The problem is that the Overo (processor card on the Tobi extension
>>> board) can have a variety of processor depending on the exact model:
>>>
>>> - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE)
>>> - OMAP 3730
>>> - AM/DM 37xx
>>>
>>> omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first
>>> generation.
>>>
>>>
>>> omap34xx.dtsi
>>> |
>>> -> omap3-overo.dtsi (processor card)
>>> |
>>> -> omap3-tobi.dtsi (expansion board)
>>>
>>>
>>> What is the fundamental incompatibility here? If we have to specifically
>>> include omap36xx for newer Overo, it will become hard to maintain as it
>>> will double the number of Overo / expansion boards possibilities.
>>
>> Well, you get different board declaration inside
>> mach-omap2/board-generic.c for omap34xx vs omap36xx.
>>
>> The clock data issues can be fixed by adding cpu_is_omap34xx() vs.
>> cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is
>> probably for Tony/Kevin to comment whether we can/should do that.
>>
>
> I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing
> the include to omap36xx.dtsi do not fix the issue. I still get the
> external abort on non-linefetch (full log here [1]).
>
So the issue is clearly caused by the hwmod warning just before the
panic I think:
omap_hwmod: usb_tll_hs: enabled state can only be entered from
initialized, idle, or disabled state
usb_tll_hs is thus not enabled, and we get a panic when trying to read
the revision register
ver = usbtll_read(tll->base, OMAP_USBTLL_REVISION);
at drivers/mfd/omap-usb-tll.c:237.
I do not know enough about hwmod to efficiently debug why usb_tll_hs is
not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing
some DT data?
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
