From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750966AbdEaE01 (ORCPT ); Wed, 31 May 2017 00:26:27 -0400 Received: from mail-pf0-f171.google.com ([209.85.192.171]:34480 "EHLO mail-pf0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750778AbdEaE00 (ORCPT ); Wed, 31 May 2017 00:26:26 -0400 From: Kevin Hilman To: Maxime Ripard 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 Organization: BayLibre References: <937914a68e4e7d6db2d12540cc6253b200978e2d.1486590875.git.rask@formelder.dk> <49ad3e66452bd78da7b9e581129f76633c56e609.1486590875.git.rask@formelder.dk> <20170210084213.uzf25soh7bl73a6g@lukather> <20170522074414.3qz2wpw4cs2btkhv@flea.lan> Date: Tue, 30 May 2017 21:26:20 -0700 In-Reply-To: <20170522074414.3qz2wpw4cs2btkhv@flea.lan> (Maxime Ripard's message of "Mon, 22 May 2017 09:44:14 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (darwin) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Maxime Ripard writes: > 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 Lambertsen 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 the boot loader >> >>> might not have enabled the required regulators, so build their 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 makes my >> > chip board boot again. >> >> FYI... this board is still broken in linux-next (and now in mainline), >> 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 regulators > for the WiFi chip in U-boot, which levels a bit the current over the > boot. How recent of a mainline u-boot do I need? I'm currently running v2016.01. > 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 is. > > 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 through > the 5v input on its header, and not the USB. There's not current > limitation there, so it shouldn't cause any problems anymore. OK, I can look into powering via 5V input also. Just curious: which of the above methods are you using? Kevin