From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tero Kristo Subject: Re: next boot: 34 pass, 5 fail (next-20140122) Date: Thu, 23 Jan 2014 11:00:03 +0200 Message-ID: <52E0DA13.9090302@ti.com> References: <52e06652.c103450a.79d7.6517@mx.google.com> <52E0B569.8000809@ti.com> <52E0CF58.5040109@epfl.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:38239 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbaAWJAQ (ORCPT ); Thu, 23 Jan 2014 04:00:16 -0500 In-Reply-To: <52E0CF58.5040109@epfl.ch> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: florian.vaussard@epfl.ch, Kevin Hilman , kernel-build-reports@lists.linaro.org, "linaro-kernel@lists.linaro.org" Cc: Tony Lindgren , Mike Turquette , linux-omap , Olof Johansson , Ash Charles 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 >>> 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 >>> 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 >>> Acked-by: Tony Lindgren >>> Signed-off-by: Mike Turquette >>> >>> 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. -Tero > > Regards, > > Florian >