mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Olof Johansson]

Mainline is bust on OMAP5 uevm:

On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter <build@lixom.net> wrote:
>
> Failed boards:
>
>     omap5uevm    omap2plus_defconfig           :        FAILED  1:46.03
>     omap5uevm    multi_v7_defconfig            :        FAILED  1:54.51
>     omap5uevm    multi_lpae_defconfig          :        FAILED  1:48.83

...

> ========================================================================
>
>         Board omap5uevm-omap2plus_defconfig failure log:
>         -------------------------------------------------
>
> [    2.625639] Key type dns_resolver registered
> [    2.625730] omap_vc_init_channel: No PMIC info for vdd_core
> [    2.625733] omap_vp_init: No PMIC info for vdd_core
> [    2.625742] omap_vc_init_channel: No PMIC info for vdd_mm
> [    2.625744] omap_vp_init: No PMIC info for vdd_mm
> [    2.625753] omap_vc_init_channel: No PMIC info for vdd_mpu
> [    2.625755] omap_vp_init: No PMIC info for vdd_mpu
> [    2.626307] ThumbEE CPU extension supported.
> [    2.626325] Registering SWP/SWPB emulation handler
> [    2.626328] SmartReflex Class3 initialized
> [    2.683943] mmc0: new high speed MMC card at address 0001
> [    2.685575] palmas 0-0048: Irq flag is 0x00000000
> [    2.696066] mmcblk0: mmc0:0001 SEM04G 3.68 GiB
> [    2.701082] mmcblk0boot0: mmc0:0001 SEM04G partition 1 2.00 MiB
> [    2.707860] mmcblk0boot1: mmc0:0001 SEM04G partition 2 2.00 MiB
> [    2.717172]  mmcblk0: unknown partition table
> [    2.723777]  mmcblk0boot1: unknown partition table
> [    2.730652]  mmcblk0boot0: unknown partition table
> [    2.736698] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0
> [    2.786540] smps123: 600 <--> 1500 mV at 1060 mV
> [    2.793524] smps45: 600 <--> 1310 mV at 1030 mV
> [    2.800839] smps6: 1200 mV
> [    2.805538] smps7: 1800 mV
> [    2.810397] smps8: 600 <--> 1310 mV at 1040 mV
> [    2.816920] smps9: failed to get the current voltage
> [    2.822852] palmas-pmic palmas_pmic.9: failed to register palmas_pmic.9 regulator
> [    2.833489] palmas-pmic: probe of palmas_pmic.9 failed with error -22
> [    2.840394] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
> [    2.847386] omap_i2c 4807c000.i2c: bus 4 rev0.12 at 400 kHz
> [    2.853554] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 4809c000[0]'
> [    2.862637] of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/mmc at 4809c000[0]'
> [    2.871980] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517
> [    2.878930] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
> [    2.887507] /home/build/work/batch/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> [    2.896210] sr_init: No PMIC hook to init smartreflex
> [    2.901664] sr_init: platform driver register failed for SR
> [    2.929862] pbias_mmc_omap5: disabling
> [    2.935342] Waiting for root device /dev/mmcblk1p2...
> ~$off
> # PYBOOT: Exception: timeout


This seems to be from palmas registration failing, which in turns
causes vmmc regulator lookup to fail. See the errors about palmas-pmic
above.

I bisected this down to a merge commit:

commit 4c04ef25b8aae6b5a8c4cc5c0235fc5d239209fd
Merge: 2c7a6a3 dbabd62 0ee42bb ab3ca77 0608032 b203e0d
Author:     Mark Brown <broonie@linaro.org>
AuthorDate: Mon Jun 2 17:08:08 2014 +0100
Commit:     Mark Brown <broonie@linaro.org>
CommitDate: Mon Jun 2 17:08:08 2014 +0100

    Merge remote-tracking branches 'regulator/topic/palmas',
'regulator/topic/pbias', 'regulator/topic/pfuze100',
'regulator/topic/s2mpa01' and 'regulator/topic/s2mps11' into
regulator-next


linux-next has been so broken that I didn't notice this as specific
failures, last successful boot there was May 29.


-Olof

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Mark Brown]

On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
> On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter <build@lixom.net> wrote:

> > [    2.816920] smps9: failed to get the current voltage

> This seems to be from palmas registration failing, which in turns
> causes vmmc regulator lookup to fail. See the errors about palmas-pmic
> above.

Always CC maintainers on things.  This is a bug in the driver, it needs
to support retrieving voltages at all times (and would probably run into
trouble anyway).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140604/a695c512/attachment.sig>

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)

[Nishanth Menon]

Minor change in subject, +Keerthy.

On 10:01-20140604, Mark Brown wrote:
> On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
> > On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter <build@lixom.net> wrote:
> 
> > > [    2.816920] smps9: failed to get the current voltage
> 
> > This seems to be from palmas registration failing, which in turns
> > causes vmmc regulator lookup to fail. See the errors about palmas-pmic
> > above.
> 
> Always CC maintainers on things.  This is a bug in the driver, it needs
> to support retrieving voltages at all times (and would probably run into
> trouble anyway).
Full thread: http://marc.info/?t=140184538000004&r=1&w=2

Yeah, this does seems to be a regression. The following is based on
next-20140604.

Seems to help my OMAP5uevm.
If this makes sense, I will repost it as a formal patch.

8<----------------
>From 3feaa7f5c749b1673aef3fd26f43b965dd627dc9 Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm@ti.com>
Date: Wed, 4 Jun 2014 14:09:09 -0500
Subject: [PATCH] regulator: palmas: Fix SMPS list for 0V

get_voltage_sel reads from SMPS register - if the read selector value
is 0, the SMPS is actually disabled - So, this is in addition to the
ctrl_register that may also be used to enable/disable the SMPS.

The original logic(prior to commit dbabd624d4eec50b6) used to be:
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
               int min_uV, int max_uV)
<snip>
       if (min_uV == 0)
               return 0;

To handle this scenario, with the transition to regulator_list
implementation, we seem to have missed the data necessary to mark as
one of the valid entries as "0" 'disabled regulator' which results in
0 volts - So, stick with pre-existing logic.

Without this added to the list, palmas regulator driver,
on probe, attempts to setup constraints and in the case of
OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in
regulator_list_voltage_linear_range mapping of '0', and as a fall back
of constraints not being applied, the entire regulator list is not
enumerated due to assumption that something system wide has gone bad
on with the PMIC.

Fixes: dbabd624d4eec50b6 ("regulator: palmas: Reemove open coded functions with helper functions")
Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
 drivers/regulator/palmas-regulator.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index 864ed02..b982f0f 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -37,12 +37,14 @@ struct regs_info {
 };
 
 static const struct regulator_linear_range smps_low_ranges[] = {
+	REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
 	REGULATOR_LINEAR_RANGE(500000, 0x1, 0x6, 0),
 	REGULATOR_LINEAR_RANGE(510000, 0x7, 0x79, 10000),
 	REGULATOR_LINEAR_RANGE(1650000, 0x7A, 0x7f, 0),
 };
 
 static const struct regulator_linear_range smps_high_ranges[] = {
+	REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
 	REGULATOR_LINEAR_RANGE(1000000, 0x1, 0x6, 0),
 	REGULATOR_LINEAR_RANGE(1020000, 0x7, 0x79, 20000),
 	REGULATOR_LINEAR_RANGE(3300000, 0x7A, 0x7f, 0),
-- 
1.7.9.5


-- 
Regards,
Nishanth Menon

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Olof Johansson]

On Wed, Jun 4, 2014 at 2:01 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Jun 03, 2014 at 06:26:14PM -0700, Olof Johansson wrote:
>> On Tue, Jun 3, 2014 at 5:36 PM, Olof's autobooter <build@lixom.net> wrote:
>
>> > [    2.816920] smps9: failed to get the current voltage
>
>> This seems to be from palmas registration failing, which in turns
>> causes vmmc regulator lookup to fail. See the errors about palmas-pmic
>> above.
>
> Always CC maintainers on things.

What maintainer did I not cc? I missed the linux-omap list but I
included you and Tony.


-Olof

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)

[Mark Brown]

On Wed, Jun 04, 2014 at 02:34:31PM -0500, Nishanth Menon wrote:

> Seems to help my OMAP5uevm.
> If this makes sense, I will repost it as a formal patch.

Yes, this makes sense - there was a similar issue with one of the other
drivers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140604/fb7a9e61/attachment.sig>

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8)

[Mark Brown]

On Wed, Jun 04, 2014 at 12:37:52PM -0700, Olof Johansson wrote:
> On Wed, Jun 4, 2014 at 2:01 AM, Mark Brown <broonie@kernel.org> wrote:

> > Always CC maintainers on things.

> What maintainer did I not cc? I missed the linux-omap list but I
> included you and Tony.

Liam mainly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140604/6d943431/attachment.sig>

mainline boot: 37 passed 4 failed (mainline/v3.15-rc8-4569-g3de0ef8) (palmas regression uEVM)

[Mark Brown]

On Wed, Jun 04, 2014 at 02:34:31PM -0500, Nishanth Menon wrote:

> Seems to help my OMAP5uevm.
> If this makes sense, I will repost it as a formal patch.

Actually I just went ahead and applied this - thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140605/0a723184/attachment.sig>