[PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/configs/sunxi_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index da92c25..5cd5dd70 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -87,6 +87,7 @@ CONFIG_THERMAL_OF=y
 CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
+CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_AXP20X_I2C=y
 CONFIG_MFD_AXP20X_RSB=y
@@ -129,6 +130,7 @@ CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_INTF_SYSFS is not set
 # CONFIG_RTC_INTF_PROC is not set
+CONFIG_RTC_DRV_AC100=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_SUNXI=y
 CONFIG_DMADEVICES=y
-- 
2.10.2

[PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/configs/sunxi_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index da92c25..5cd5dd70 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -87,6 +87,7 @@ CONFIG_THERMAL_OF=y
 CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
+CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_AXP20X_I2C=y
 CONFIG_MFD_AXP20X_RSB=y
@@ -129,6 +130,7 @@ CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_INTF_SYSFS is not set
 # CONFIG_RTC_INTF_PROC is not set
+CONFIG_RTC_DRV_AC100=y
 CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_SUNXI=y
 CONFIG_DMADEVICES=y
-- 
2.10.2

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

[Rask Ingemann Lambertsen]

The sunxi RSB bus is used for peripherals like voltage regulators and
real-time clocks which should be available early in the boot process.
As a module, the driver will not be available until the root fs has been
mounted, so build the driver into the kernel.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 028d2b7..ec3a110 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -193,7 +193,7 @@ CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_SIMPLE_PM_BUS=y
-CONFIG_SUNXI_RSB=m
+CONFIG_SUNXI_RSB=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
-- 
2.10.2

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

[Rask Ingemann Lambertsen]

The sunxi RSB bus is used for peripherals like voltage regulators and
real-time clocks which should be available early in the boot process.
As a module, the driver will not be available until the root fs has been
mounted, so build the driver into the kernel.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 028d2b7..ec3a110 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -193,7 +193,7 @@ CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_SIMPLE_PM_BUS=y
-CONFIG_SUNXI_RSB=m
+CONFIG_SUNXI_RSB=y
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
-- 
2.10.2

[PATCH 3/4] ARM: multi_v7_defconfig: Enable AC100 RTC driver

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
---
This patch will have no effect if patch 2/4 is not applied.

 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ec3a110..5868186 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -480,6 +480,7 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_ATMEL_FLEXCOM=y
 CONFIG_MFD_ATMEL_HLCDC=m
 CONFIG_MFD_BCM590XX=y
+CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_AXP20X_I2C=m
 CONFIG_MFD_AXP20X_RSB=m
@@ -749,6 +750,7 @@ CONFIG_EDAC_MM_EDAC=y
 CONFIG_EDAC_HIGHBANK_MC=y
 CONFIG_EDAC_HIGHBANK_L2=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AC100=y
 CONFIG_RTC_DRV_AS3722=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_RTC_DRV_HYM8563=m
-- 
2.10.2

[PATCH 3/4] ARM: multi_v7_defconfig: Enable AC100 RTC driver

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
---
This patch will have no effect if patch 2/4 is not applied.

 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ec3a110..5868186 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -480,6 +480,7 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_ATMEL_FLEXCOM=y
 CONFIG_MFD_ATMEL_HLCDC=m
 CONFIG_MFD_BCM590XX=y
+CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_AXP20X_I2C=m
 CONFIG_MFD_AXP20X_RSB=m
@@ -749,6 +750,7 @@ CONFIG_EDAC_MM_EDAC=y
 CONFIG_EDAC_HIGHBANK_MC=y
 CONFIG_EDAC_HIGHBANK_L2=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AC100=y
 CONFIG_RTC_DRV_AS3722=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_RTC_DRV_HYM8563=m
-- 
2.10.2

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

[Rask Ingemann Lambertsen]

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>
---
This patch will have no effect if patch 2/4 is not applied. It will also
not apply cleanly without patch 3/4.

 arch/arm/configs/multi_v7_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5868186..cc071a0 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -482,8 +482,8 @@ CONFIG_MFD_ATMEL_HLCDC=m
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
-CONFIG_MFD_AXP20X_I2C=m
-CONFIG_MFD_AXP20X_RSB=m
+CONFIG_MFD_AXP20X_I2C=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=m
 CONFIG_MFD_CROS_EC_I2C=m
 CONFIG_MFD_CROS_EC_SPI=m
@@ -512,7 +512,7 @@ CONFIG_REGULATOR_ACT8865=y
 CONFIG_REGULATOR_ANATOP=y
 CONFIG_REGULATOR_AS3711=y
 CONFIG_REGULATOR_AS3722=y
-CONFIG_REGULATOR_AXP20X=m
+CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_BCM590XX=y
 CONFIG_REGULATOR_DA9210=y
 CONFIG_REGULATOR_FAN53555=y
-- 
2.10.2

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

[Rask Ingemann Lambertsen]

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>
---
This patch will have no effect if patch 2/4 is not applied. It will also
not apply cleanly without patch 3/4.

 arch/arm/configs/multi_v7_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5868186..cc071a0 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -482,8 +482,8 @@ CONFIG_MFD_ATMEL_HLCDC=m
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X=y
-CONFIG_MFD_AXP20X_I2C=m
-CONFIG_MFD_AXP20X_RSB=m
+CONFIG_MFD_AXP20X_I2C=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=m
 CONFIG_MFD_CROS_EC_I2C=m
 CONFIG_MFD_CROS_EC_SPI=m
@@ -512,7 +512,7 @@ CONFIG_REGULATOR_ACT8865=y
 CONFIG_REGULATOR_ANATOP=y
 CONFIG_REGULATOR_AS3711=y
 CONFIG_REGULATOR_AS3722=y
-CONFIG_REGULATOR_AXP20X=m
+CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_BCM590XX=y
 CONFIG_REGULATOR_DA9210=y
 CONFIG_REGULATOR_FAN53555=y
-- 
2.10.2

Re: [PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Wed, Feb 08, 2017 at 11:07:15PM +0100, Rask Ingemann Lambertsen wrote:
> Enable the AC100 RTC driver so boards with it can keep track of time.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
> Acked-by: Chen-Yu Tsai <wens@csie.org>

Queued for 4.12.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[Maxime Ripard]

On Wed, Feb 08, 2017 at 11:07:15PM +0100, Rask Ingemann Lambertsen wrote:
> Enable the AC100 RTC driver so boards with it can keep track of time.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
> Acked-by: Chen-Yu Tsai <wens@csie.org>

Queued for 4.12.

Thanks!
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/20170210/7d71da8a/attachment.sig>

Re: [PATCH 2/4] ARM: multi_v7_defconfig: Switch sunxi RSB driver from module to built-in

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Wed, Feb 08, 2017 at 11:08:00PM +0100, Rask Ingemann Lambertsen wrote:
> The sunxi RSB bus is used for peripherals like voltage regulators and
> real-time clocks which should be available early in the boot process.
> As a module, the driver will not be available until the root fs has been
> mounted, so build the driver into the kernel.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>

Queued for 4.12.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

On Wed, Feb 08, 2017 at 11:08:00PM +0100, Rask Ingemann Lambertsen wrote:
> The sunxi RSB bus is used for peripherals like voltage regulators and
> real-time clocks which should be available early in the boot process.
> As a module, the driver will not be available until the root fs has been
> mounted, so build the driver into the kernel.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>

Queued for 4.12.

Thanks!
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/20170210/307b6909/attachment.sig>

Re: [PATCH 3/4] ARM: multi_v7_defconfig: Enable AC100 RTC driver

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

On Wed, Feb 08, 2017 at 11:08:45PM +0100, Rask Ingemann Lambertsen wrote:
> Enable the AC100 RTC driver so boards with it can keep track of time.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>

Queued for 4.12.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[PATCH 3/4] ARM: multi_v7_defconfig: Enable AC100 RTC driver

[Maxime Ripard]

On Wed, Feb 08, 2017 at 11:08:45PM +0100, Rask Ingemann Lambertsen wrote:
> Enable the AC100 RTC driver so boards with it can keep track of time.
> 
> Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>

Queued for 4.12.

Thanks!
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/20170210/031256e1/attachment.sig>

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

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.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

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.

Thanks!
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/20170210/98211d4e/attachment.sig>

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

[Kevin Hilman]

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.

Kevin

[1] https://kernelci.org/boot/id/58c2426759b5144a68645535/
[2]
$ git bisect log
git bisect start
# good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag
'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\
/helgaas/pci
git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563
# bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next
specific files for 20170310
git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201
# good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch
'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\
nel/git/tip/tip
git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db
# good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always
set link->downstream to avoid NULL dereference on remove
git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2
# good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1:
Adapt vsp1_du_setup_lif() interface to use a structure
git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b
# good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove
duplicate inclusion of linux/init.h
git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4
# good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge
remote-tracking branch 'drm/drm-next'
git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284
# bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge
remote-tracking branch 'extcon/extcon-next'
git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb
# bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge
remote-tracking branch 'input/next'
git bisect bad e04b073635205c983891d0d70fb854c7b1871d89
# bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge
remote-tracking branch 'sunxi/sunxi/for-next'
git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab
# good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge
remote-tracking branch 'drm-misc/for-linux-next'
git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef
# good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass
pointer for underlying backend into layer init
git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc
# good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi:
Remove no longer used pinctrl/sun4i-a10.h header
git bisect good 7d55034799cdc9945ce7975d690f944575376e34
# bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches
'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\
r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next
git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c
# good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng:
sun5i: Fix mux width for csi clock
git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4
# bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
multi_v7_defconfig: Switch AXP20x driver from module to built-in
git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1
# good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM:
multi_v7_defconfig: Switch sunxi RSB driver from module to built-in
git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d
# good: [f48a203cc44f26921f05911c047db49d2864c797] ARM:
multi_v7_defconfig: Enable AC100 RTC driver
git bisect good f48a203cc44f26921f05911c047db49d2864c797
# first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
multi_v7_defconfig: Switch AXP20x driver from module to built\
-in

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

[Kevin Hilman]

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.

Kevin

[1] https://kernelci.org/boot/id/58c2426759b5144a68645535/
[2]
$ git bisect log
git bisect start
# good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag
'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\
/helgaas/pci
git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563
# bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next
specific files for 20170310
git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201
# good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch
'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\
nel/git/tip/tip
git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db
# good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always
set link->downstream to avoid NULL dereference on remove
git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2
# good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1:
Adapt vsp1_du_setup_lif() interface to use a structure
git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b
# good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove
duplicate inclusion of linux/init.h
git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4
# good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge
remote-tracking branch 'drm/drm-next'
git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284
# bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge
remote-tracking branch 'extcon/extcon-next'
git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb
# bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge
remote-tracking branch 'input/next'
git bisect bad e04b073635205c983891d0d70fb854c7b1871d89
# bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge
remote-tracking branch 'sunxi/sunxi/for-next'
git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab
# good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge
remote-tracking branch 'drm-misc/for-linux-next'
git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef
# good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass
pointer for underlying backend into layer init
git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc
# good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi:
Remove no longer used pinctrl/sun4i-a10.h header
git bisect good 7d55034799cdc9945ce7975d690f944575376e34
# bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches
'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\
r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next
git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c
# good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng:
sun5i: Fix mux width for csi clock
git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4
# bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
multi_v7_defconfig: Switch AXP20x driver from module to built-in
git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1
# good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM:
multi_v7_defconfig: Switch sunxi RSB driver from module to built-in
git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d
# good: [f48a203cc44f26921f05911c047db49d2864c797] ARM:
multi_v7_defconfig: Enable AC100 RTC driver
git bisect good f48a203cc44f26921f05911c047db49d2864c797
# first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
multi_v7_defconfig: Switch AXP20x driver from module to built\
-in

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

[Kevin Hilman]

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?

Kevin

> [1] https://kernelci.org/boot/id/58c2426759b5144a68645535/
> [2]
> $ git bisect log
> git bisect start
> # good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag
> 'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\
> /helgaas/pci
> git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563
> # bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next
> specific files for 20170310
> git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201
> # good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch
> 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\
> nel/git/tip/tip
> git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db
> # good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always
> set link->downstream to avoid NULL dereference on remove
> git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2
> # good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1:
> Adapt vsp1_du_setup_lif() interface to use a structure
> git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b
> # good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove
> duplicate inclusion of linux/init.h
> git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4
> # good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge
> remote-tracking branch 'drm/drm-next'
> git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284
> # bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge
> remote-tracking branch 'extcon/extcon-next'
> git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb
> # bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge
> remote-tracking branch 'input/next'
> git bisect bad e04b073635205c983891d0d70fb854c7b1871d89
> # bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge
> remote-tracking branch 'sunxi/sunxi/for-next'
> git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab
> # good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge
> remote-tracking branch 'drm-misc/for-linux-next'
> git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef
> # good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass
> pointer for underlying backend into layer init
> git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc
> # good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi:
> Remove no longer used pinctrl/sun4i-a10.h header
> git bisect good 7d55034799cdc9945ce7975d690f944575376e34
> # bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches
> 'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\
> r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next
> git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c
> # good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng:
> sun5i: Fix mux width for csi clock
> git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4
> # bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
> multi_v7_defconfig: Switch AXP20x driver from module to built-in
> git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1
> # good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM:
> multi_v7_defconfig: Switch sunxi RSB driver from module to built-in
> git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d
> # good: [f48a203cc44f26921f05911c047db49d2864c797] ARM:
> multi_v7_defconfig: Enable AC100 RTC driver
> git bisect good f48a203cc44f26921f05911c047db49d2864c797
> # first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
> multi_v7_defconfig: Switch AXP20x driver from module to built\
> -in

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

[Kevin Hilman]

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?

Kevin

> [1] https://kernelci.org/boot/id/58c2426759b5144a68645535/
> [2]
> $ git bisect log
> git bisect start
> # good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag
> 'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\
> /helgaas/pci
> git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563
> # bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next
> specific files for 20170310
> git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201
> # good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch
> 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\
> nel/git/tip/tip
> git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db
> # good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always
> set link->downstream to avoid NULL dereference on remove
> git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2
> # good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1:
> Adapt vsp1_du_setup_lif() interface to use a structure
> git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b
> # good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove
> duplicate inclusion of linux/init.h
> git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4
> # good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge
> remote-tracking branch 'drm/drm-next'
> git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284
> # bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge
> remote-tracking branch 'extcon/extcon-next'
> git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb
> # bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge
> remote-tracking branch 'input/next'
> git bisect bad e04b073635205c983891d0d70fb854c7b1871d89
> # bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge
> remote-tracking branch 'sunxi/sunxi/for-next'
> git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab
> # good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge
> remote-tracking branch 'drm-misc/for-linux-next'
> git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef
> # good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass
> pointer for underlying backend into layer init
> git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc
> # good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi:
> Remove no longer used pinctrl/sun4i-a10.h header
> git bisect good 7d55034799cdc9945ce7975d690f944575376e34
> # bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches
> 'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\
> r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next
> git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c
> # good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng:
> sun5i: Fix mux width for csi clock
> git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4
> # bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
> multi_v7_defconfig: Switch AXP20x driver from module to built-in
> git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1
> # good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM:
> multi_v7_defconfig: Switch sunxi RSB driver from module to built-in
> git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d
> # good: [f48a203cc44f26921f05911c047db49d2864c797] ARM:
> multi_v7_defconfig: Enable AC100 RTC driver
> git bisect good f48a203cc44f26921f05911c047db49d2864c797
> # first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM:
> multi_v7_defconfig: Switch AXP20x driver from module to built\
> -in

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

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.

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/20170522/3d9bd62b/attachment.sig>

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> 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 <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.

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

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> 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 <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.

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

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

[Kevin Hilman]

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

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

[Kevin Hilman]

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

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

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@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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

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@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.

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>

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> writes:

> 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@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.
>
> I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> built-in as well. It can boot fine on my CHIP here.

What about multi_v7_defconfig?

> 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.

Ah, I suppose that isn't terribly clear from the log.

My scripts don't rely on uboot for the ramdisk because because (believe
it or not) many vendor uboots don't enable the ATAGs for initrd in
uboot.

So, I modify the DT to add the linux,initrd-start and linux,initrd-end
properties to the chosen node poining to where the initrd is loaded in
memory.  This also avoids the need to add a uimage header to the ramdisk.

Kevin

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> writes:

> 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@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.
>
> I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> built-in as well. It can boot fine on my CHIP here.

What about multi_v7_defconfig?

> 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.

Ah, I suppose that isn't terribly clear from the log.

My scripts don't rely on uboot for the ramdisk because because (believe
it or not) many vendor uboots don't enable the ATAGs for initrd in
uboot.

So, I modify the DT to add the linux,initrd-start and linux,initrd-end
properties to the chosen node poining to where the initrd is loaded in
memory.  This also avoids the need to add a uimage header to the ramdisk.

Kevin

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4138 bytes --]

On Tue, Jun 13, 2017 at 09:14:00AM -0700, Kevin Hilman wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> 
> > 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@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.
> >
> > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> > built-in as well. It can boot fine on my CHIP here.
> 
> What about multi_v7_defconfig?

It seems to work in our farm.

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

> > 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.
> 
> Ah, I suppose that isn't terribly clear from the log.
> 
> My scripts don't rely on uboot for the ramdisk because because (believe
> it or not) many vendor uboots don't enable the ATAGs for initrd in
> uboot.
> 
> So, I modify the DT to add the linux,initrd-start and linux,initrd-end
> properties to the chosen node poining to where the initrd is loaded in
> memory.  This also avoids the need to add a uimage header to the ramdisk.

Ok, good :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

On Tue, Jun 13, 2017 at 09:14:00AM -0700, Kevin Hilman wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> 
> > 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@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.
> >
> > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> > built-in as well. It can boot fine on my CHIP here.
> 
> What about multi_v7_defconfig?

It seems to work in our farm.

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

> > 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.
> 
> Ah, I suppose that isn't terribly clear from the log.
> 
> My scripts don't rely on uboot for the ramdisk because because (believe
> it or not) many vendor uboots don't enable the ATAGs for initrd in
> uboot.
> 
> So, I modify the DT to add the linux,initrd-start and linux,initrd-end
> properties to the chosen node poining to where the initrd is loaded in
> memory.  This also avoids the need to add a uimage header to the ramdisk.

Ok, good :)

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/20170614/2e9aa581/attachment-0001.sig>

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4646 bytes --]

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 <maxime.ripard@free-electrons.com> writes:
> > 
> > > 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@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.
> > >
> > > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> > > built-in as well. It can boot fine on my CHIP here.
> > 
> > What about multi_v7_defconfig?
> 
> It seems to work in our farm.
> 
> 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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Maxime Ripard]

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 <maxime.ripard@free-electrons.com> writes:
> > 
> > > 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@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.
> > >
> > > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> > > built-in as well. It can boot fine on my CHIP here.
> > 
> > What about multi_v7_defconfig?
> 
> It seems to work in our farm.
> 
> 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

-- 
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/20170721/844f4343/attachment.sig>

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> writes:

> 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 <maxime.ripard@free-electrons.com> writes:
>> > 
>> > > 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@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.
>> > >
>> > > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
>> > > built-in as well. It can boot fine on my CHIP here.
>> > 
>> > What about multi_v7_defconfig?
>> 
>> It seems to work in our farm.
>> 
>> 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.

Yay, thanks spending the extra time to dig into it.

Kevin

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

[Kevin Hilman]

Maxime Ripard <maxime.ripard@free-electrons.com> writes:

> 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 <maxime.ripard@free-electrons.com> writes:
>> > 
>> > > 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@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.
>> > >
>> > > I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
>> > > built-in as well. It can boot fine on my CHIP here.
>> > 
>> > What about multi_v7_defconfig?
>> 
>> It seems to work in our farm.
>> 
>> 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.

Yay, thanks spending the extra time to dig into it.

Kevin