On 01/23/2014 01:27 PM, Tero Kristo wrote: > On 01/23/2014 11:41 AM, Florian Vaussard wrote: >> >> >> 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? > > The problem is the point before this one, uart4_fck lookup fails. This > causes the hwmod code to bail out early and not init anything after it. > > I guess you are still mapping wrong clock init as it fails with uart4. > Give the attached patch a shot and see how it behaves. > Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-( Regards, 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
