lkml.org 
[lkml]   [2017]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in
    On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard
    <maxime.ripard@free-electrons.com> 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 <khilman@baylibre.com> wrote:
    >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
    >> > <maxime.ripard@free-electrons.com> 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 <rask@formelder.dk>
    >> >>
    >> >> 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.
    >
    > 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.

    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.

    Kevin

    \
     
     \ /
      Last update: 2017-06-12 00:54    [W:3.503 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site