From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754026AbdGUORX (ORCPT ); Fri, 21 Jul 2017 10:17:23 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:43393 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbdGUORV (ORCPT ); Fri, 21 Jul 2017 10:17:21 -0400 Date: Fri, 21 Jul 2017 16:17:19 +0200 From: Maxime Ripard To: Kevin Hilman Cc: Rask Ingemann Lambertsen , Chen-Yu Tsai , Russell King , linux-arm-kernel , lkml Subject: Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in Message-ID: <20170721141719.7quea4zf64q6xeqk@flea> References: <937914a68e4e7d6db2d12540cc6253b200978e2d.1486590875.git.rask@formelder.dk> <49ad3e66452bd78da7b9e581129f76633c56e609.1486590875.git.rask@formelder.dk> <20170210084213.uzf25soh7bl73a6g@lukather> <20170522074414.3qz2wpw4cs2btkhv@flea.lan> <20170610161714.wiztqlnwz5qu73fz@flea.home> <20170614070712.yos54lelz5adrlq6@flea.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="erjugq4osd2ol357" Content-Disposition: inline In-Reply-To: <20170614070712.yos54lelz5adrlq6@flea.lan> User-Agent: NeoMutt/20170714 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --erjugq4osd2ol357 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 14, 2017 at 09:07:12AM +0200, Maxime Ripard wrote: > On Tue, Jun 13, 2017 at 09:14:00AM -0700, Kevin Hilman wrote: > > Maxime Ripard writes: > >=20 > > > On Tue, Jun 06, 2017 at 12:45:17PM -0700, Kevin Hilman wrote: > > >> On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard > > >> wrote: > > >> > Hi Kevin, > > >> > > > >> > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote: > > >> >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman wrote: > > >> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard > > >> >> > wrote: > > >> >> >> On Wed, Feb 08, 2017 at 11:09:31PM +0100, Rask Ingemann Lamber= tsen wrote: > > >> >> >>> The AXP20X regulator support is currently built as a module, = which means > > >> >> >>> it's not available until the root fs has been mounted, but th= e boot loader > > >> >> >>> might not have enabled the required regulators, so build thei= r drivers > > >> >> >>> into the kernel. > > >> >> >>> > > >> >> >>> Signed-off-by: Rask Ingemann Lambertsen > > >> >> >> > > >> >> >> Queued for 4.12. > > >> >> > > > >> >> > Hello, kernelci.org is reporting boot failures on sun5i-r8-chip= in > > >> >> > linux-next[1] for a few days and with a variety of defconfigs.= I > > >> >> > bisected it[2] down to this patch. > > >> >> > > > >> >> > I verified that reverting this patch on top of next-20170310 ma= kes my > > >> >> > chip board boot again. > > >> >> > > >> >> FYI... this board is still broken in linux-next (and now in mainl= ine), > > >> >> and reverting $SUBJECT patch still makes it work. > > >> >> > > >> >> Is nobody else using mainline on this board? > > >> > > > >> > I thought about that during the weekend, and it might just be a > > >> > symptom. > > >> > > > >> > The CHIP has brown out issues, especially when you enable the WiFi > > >> > chip, which should happen around the time of the failure when the = PMIC > > >> > regulator support is compiled as a module. > > >> > > > >> > We mitigate that in upstream's U-Boot by enabling the two regulato= rs > > >> > for the WiFi chip in U-boot, which levels a bit the current over t= he > > >> > boot. > > >> > > > >> > You have a few ways to prevent that from happening. Having a better > > >> > power supply / cable will help, I'm not sure how reasonable that i= s. > > >> > > > >> > Another thing that can work is, if your USB plugs can take it, to > > >> > increase the overcurrent trigger in the PMIC, ideally in U-Boot. > > >> > > > >> > The last, and probably cleaner one, would be to just power it thro= ugh > > >> > the 5v input on its header, and not the USB. There's not current > > >> > limitation there, so it shouldn't cause any problems anymore. > > >>=20 > > >> I'm now powering the board via the header (5V to the CHG-IN pin) and > > >> it doesn't change anything. Still fails in the same way, and > > >> reverting $SUBJECT defconfig patch makes it work again. > > > > > > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR > > > built-in as well. It can boot fine on my CHIP here. > >=20 > > What about multi_v7_defconfig? >=20 > It seems to work in our farm. >=20 > It's lagging behind at the moment, so it hasn't been published yet, > but here is the last multi_v7 boot. > http://code.bulix.org/a43kkf-147625?raw A bit of an update for that. It turned out that our farm also had this issue. We tried to power it through the 5V plug, and it didn't change anything. After wasting way too much time on this, we started digging into it today with Chen-Yu. We found out after enabling DEBUG_DRIVER that the last line was always a cpufreq rate change. Removing the handle on the CPU regulator wasn't changing anything, which left us with the other option: the clocks. It turns out that in 4.12 we also switched to a new clock framework for the sun5i family. A few printk down the line, the clock calculation were not propagated to the PLL, resulting in a CPU crash. Now, you might ask why it was crashing in multi_v7, and not in sunxi_defconfig. The default governor in multi_v7 is ondemand, the one in sunxi is performance, and therefore it never changes the CPU clock rate. And I guess reverting the regulator option patch just prevented the cpufreq-dt from probing since it was missing the CPU regulator described in DT. I'll send a patch addressing this, cc'd to stable. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --erjugq4osd2ol357 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZcgzvAAoJEBx+YmzsjxAgWkIP/jAzlBWSiT592G8V+qJUjTiY XzLsaGolRwFVd5+rlPEnF2W6ioOu3wCsulyhO3TGUMyYIMF9d5OhEEhIxDWKlx2i 2Jxgda3FYLWPBGKqXdWnoxiQ4nst41WpYgsSTIIPlMkItzyvKN5W8MJAzCUq45nq EoKhm0uqOdlsxpFMaGibZtqjK9YacJRMOC08HjM6JVRJT0U2WNBUdC6t2Hney/nh UPKXd+gwrtrat0A3LrXg8RlwLkk0ulG7V+iNJlH3pmK7lqk62JlqyXvz2b2J9PUI OlPU8LC2jcoHYV6Z/sVDhyyimG5FwC0mE/0tra7UuHIPIbWgX4c86kbpo7pEIwwE nrWOildpfBZcDEB/9Nm0mJpZ6SbWfS7cTKaqMZXUNdzCCkBCsPCaJioqWrjAbP6P 5SEuYuN99Y4LR78zV6n2TsuBTkitHa4kiZqt7ERqcdwxacPVu65afMKJQxnuSl3v /l6+2TzUx5ugEzWKshfN4OcownBZ7nWS8iwkiW1eNSTBAn9PHSm6To3Td3uVpPVH KUMLpmKfK8j5jgXUPFX7ISJYDIuqGFU6TDnydnDKRqStGkZhu7aPrbCuWxk9KIC5 VnZXc2m5wFsS//bQfYIhsZT3oZ6WbahWV1OI5pOUTkbXTuTyg/3Q2BPqlR4i+frx c/XG2Wa5AXQ0EUWKoy0l =GA5M -----END PGP SIGNATURE----- --erjugq4osd2ol357--