[PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

Maxime Ripard maxime.ripard at free-electrons.com
Sat Jun 10 09:17:14 PDT 2017


On Tue, Jun 06, 2017 at 12:45:17PM -0700, Kevin Hilman wrote:
> On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard
> <maxime.ripard at 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 at baylibre.com> wrote:
> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
> >> > <maxime.ripard at 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 at 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.

I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
built-in as well. It can boot fine on my CHIP here.

After looking at your failed boot example (1), I'm a bit
puzzled. Where is supposed to be your filesystem?

You have a ubi rootfs, but we don't have the NAND enabled in mainline,
so that cannot work. And you seem to load an initramfs earlier in
U-Boot, but you don't pass it is your bootz call.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170610/d975ef1e/attachment-0001.sig>


More information about the linux-arm-kernel mailing list