Hello Krzysztof,

On Sat, Aug 29, 2015 at 11:55 AM, Krzysztof Kozlowski
[off-list ref] wrote:

2015-08-29 18:33 GMT+09:00 Javier Martinez Canillas [off-list ref]:

quoted

Hello Krzysztof,

On 08/29/2015 11:01 AM, Krzysztof Kozlowski wrote:

quoted

W dniu 28.08.2015 o 17:16, Javier Martinez Canillas pisze:

quoted

Some Exynos big.LITTLE boards (i.e: Exynos5420 and Exynos5800 based
Chromebooks) have proper firmware that allow the big.LITTLE CPUidle
driver to work correctly, so enable support for this.

Signed-off-by: Javier Martinez Canillas <redacted>

---
Kukjin and Krzysztof,

As you know there are other boards like the Exynos5422 based Odroid XU{3,4}
whose firmware is broken due leaving CCI in secure mode which means that the
kernel MCPM support can't properly manage CCI.

So if you pick this patch, it should be tested in kernelci before appearing
in linux-next to prevent any boot issues.

But if that happens, I believe that is better to do a fix / workaround in
those broken platforms since nothing prevents users to enable this option
anyways. For example the CCI device node could be disabled in the DTS.

 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

On Odroid XU3L (next-20150828, Hardkernel u-boot) boot hangs just after:

Thanks for testing, I was expecting that is just that I don't have a
Odroid XU{3,4} board for test here, I guess I should get one.

quoted

[    2.568650] dwmmc_exynos 12200000.mmc: num-slots property not found,
assuming 1 slot is available

... so no. NACK :). First the boards, firmware, bootloader or kernel

Agreed with the nack :)

quoted

code have to be fixed.

Or disable CCI, could you please test the following patch [0] so I
can post it properly?

It fixes the boot hang but causes other issues. Not all CPUs boot (I

Thanks for testing.

tested it on Chanho Park's patch for fixing CPU boot with SWRESET):
[    0.010781] CPU0: update cpu_capacity 448
[    0.010839] CPU0: thread -1, cpu 0, socket 1, mpidr 80000100
[    0.011098] Setting up static identity map for 0x40008280 - 0x400082d8
[    0.056329] CPU1: update cpu_capacity 448
[    0.056337] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.071100] CPU2: update cpu_capacity 448
[    0.071107] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.086103] CPU3: update cpu_capacity 448
[    0.086111] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.101100] CPU4: update cpu_capacity 1535
[    0.101108] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
[    1.115009] CPU5: failed to boot: -110
[    2.130019] CPU6: failed to boot: -110
[    3.145049] CPU7: failed to boot: -110
[    3.145151] Brought up 5 CPUs
[    3.145196] SMP: Total of 5 processors activated (240.00 BogoMIPS).
[    3.145251] CPU: WARNING: CPU(s) started in wrong/inconsistent
modes (primary CPU mode 0x13)
[    3.145327] CPU: This may indicate a broken bootloader or firmware.
[    3.149347] devtmpfs: initialized

Sigh, such an inconsistent behavior between Exynos5420/5422/5800 boards :-/

Any ideas? I agree that the b.L CPUidle support shouldn't be enabled
by default in exynos_defconfig but as I said nothing prevents the user
to enable that option and make the board to hang on boot.

Best regards,
Krzysztof

Best regards,
Javier