DRA76P: Android kernel is not booting due to i2c3 issues?

Hi,

After investigation with pmic lp87565 and buck10 regulator, we detect that :

The vdd_mpu_1/9 is 1.13 V  (real measure) after first power on , then it reboots automatically and we occur this log for the first iteration : 

[ 2.944149] lp87565 2-0060: lp87565_regulator_probe lp87565-q1-regulator regulator

[ 2.952483] lp87565 2-0060: lp87565_buck_get_current_limit regulator

[ 2.959143] buck10: 850 <--> 1250 mV at 1150 mV at 5000 mA
[ 2.965477] lp87565 2-0060: lp87565_buck_get_current_limit regulator
[ 2.972114] buck23: 850 <--> 1250 mV at 1060 mV at 5000 mA

at this level the vdd_mpu_1/9 is  1.222V

and after 2 automatically reboot :

2.964476] lp87565 2-0060: lp87565_regulator_probe lp87565-q1-regulator regulator
[ 2.972833] lp87565 2-0060: lp87565_buck_get_current_limit regulator
[ 2.979494] buck10: 850 <--> 1250 mV at 1250 mV at 5000 mA
[ 2.985851] lp87565 2-0060: lp87565_buck_get_current_limit regulator
[ 2.992488] buck23: 850 <--> 1250 mV at 1060 mV at 5000 mA

but at  this level the vdd_mpu_1/9 is   1.180V

Do you know please, why the vdd_mpu voltage is not same and who is responsible to power-up the buck10 regulator voltage ?

Is it current limitation  or HW  issue ?

Thank you for your support

Regards,

Hi,

When we disable the oppdm_mpu node on dts file 

oppdm_mpu: oppdm@4a003b20 {

compatible = "ti,omap5-oppdm";
#oppdm-cells = <0>;

status = "disabled" ;
vbb-supply = <&abb_mpu>;
reg = <0x4a003b20 0xc>;
ti,efuse-settings = <
/* uV offset */
1060000 0x0
1160000 0x4
1210000 0x8
>;
ti,absolute-max-voltage-uv = <1500000>;
};

//&oppdm_mpu {
//vdd-supply = <&buck10_reg>;
//};

The android boot complete OK and no random reset detected.

So the cpu reset is occurred only when using buck10_reg regulator  with oppdm_mpu enabled..

Any suggestion please,

Thanks,

Regards; 

Hi Chokri,

Could you share the buck10_reg regulator node contents as well?
Is your PMIC connections on custom board exactly same as TI EVM?

Also, share the final generated dtb converted to dts file. Example below for dra76p dtb file.
./scripts/dtc/dtc -I dtb -O dts arch/arm/boot/dts/dra76-evm.dtb -o final.dts

Regards,
Vishal

Hi Vishal,

Thank you !

 buck10_reg regulator node :

lp87565: lp87565@60 {
compatible = "ti,lp87565-q1";
reg = <0x60>;

buck10-in-supply =<&vsys_3v3>;
buck23-in-supply =<&vsys_3v3>;

regulators: regulators {
buck10_reg: buck10 {
/*VDD_MPU*/
regulator-name = "buck10";
regulator-min-microvolt = <850000>;
regulator-max-microvolt = <1250000>;
regulator-always-on;
regulator-boot-on;
};

buck23_reg: buck23 {
/* VDD_GPU*/
regulator-name = "buck23";
regulator-min-microvolt = <850000>;
regulator-max-microvolt = <1250000>;
regulator-boot-on;
regulator-always-on;
};
};
};

&oppdm_mpu {
vdd-supply = <&buck10_reg>;
};

Attached final.dts file : 

final.txt

Thank you for your support,

Regards,

Chokri

Hi Vishal,

Please have a look to this post:

In i2c3 we are seing the same timming.

Best regards.

Note that we found a W/A to skip reset :

on kernel/android-4.4/drivers/regulator/core.c (_regulator_do_set_voltage function)

if (min_uV <= best_val && max_uV >= best_val) {
selector = ret;
- if (old_selector == selector)
+ if (selector > 0)

...

So by getting the new valid selector we avoid _regulator_call_set_voltage_sel call.

Regards,

Chokri

Hi Chokri,

I don't know about the change, these are core kernel driver APIs and should be changed for workarounds.

Regards,
Vishal

Hi Vishal,

Thank you!

But why this module works with EVM using same pmic.

buck10 regulator and mpu is it OK from dts definition?

Any i2c bus tools to validate pmic/mpu connection?

Regards

Chokri

Yes, buck10 regulator definition matches TI EVM.
TI EVM dts for reference --> ti_evm_dra76p_dts.txt

Hi Vishal,

Issue still reproduced when enable  lp87565@60 dts node

Regards

Chokri

Hi Chokri,

One difference I found in your dts compared to TI EVM dts, can you check if this is correct for your board?

On TI EVM,
- We have no Vin supply for regulator-vsys12v0
- regulators vsys5v0 and vsys3v3 have Vin supply as vsys12v0

On your dts,
- regulator vsys12v0 has Vin as vsysvbat
- regulators vsys5v0 and vsys3v3 have Vin supply as vsysvbat

Hi Vishal,

Regarding your question: "Is your PMIC connections on custom board exactly same as TI EVM?" The answer is: nop. In our board, the PMICs (TPS65917 and LP87565) are on I2C3 bus, not on I2C1

Regards,

We've changed our PMICs' I2C, from I2C3 to I2C1, in order to check is this is able to solve the issue but nothing have changed.

Is i2c the only change?
Also, do you have any comments on the difference I pointed to in previous post?

Hi Vishal,

Yes, there difference between DTS files is OK. After our main input (VBAT) we have two branches: a 12V regulator, and the TPS43351 (the same as EVM) to output the 5V & 3.3V.

Hi,

Could you do a test by changing the CPUFreq governor in Kernel to "performance" as default?
This will disable OPP switch from Kernel and stay with one OPP through out.

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE



Regards,
Vishal

Hi Vishal,

Issue still reproduced by enabling CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE.

Regards,

Chokri

Hi Chokri,

Based on the behavior that issue is not seen when you comment out buck10 or oppdm_mpu suggested that the issue could be due to MPU OPP switch done by Linux. When you don't have these entries then there is no OPP switch.

The experiment above was suggested to keep a fixed OPP.

We are discussing further with the team for other suggestions.

Regards,
Vishal

Other suggestion is to probing the voltage and checking if there is any glitch.

Has the VDD_MPU voltage line probed and checked for any glitch?

Yes, VDD_MPU looks OK, we dont see any glitch.

Hi,

Could you try lowering the i2c3 clock frequency to 100 KHz?
This change can be done via kernel dts file. Change clock-frequency to 100000.

&i2c3 {
        status = "okay";
        clock-frequency = <400000>;
};

Regards,
Vishal

Hi Alejandro,

Thank you for having confirmed that lowering the I2C3 frequency to 100 kHz did not improve things.

Could you please probe vdd_mpu along with rstoutn? We would like to see the timing relationship between the changes of vdd_mpu (the various values mentioned in former posts: 1.13 V, 1.222 V, and 1.180 V) and the reset condition? Thank you.

Best regards,
François.

Hello Vishal and François,

Here there are the timming captures (green rstoutn, yellow vdd_mpu)

Best regards.

Our PMIC engineer is not available this week, we will get back to you on Monday.

Hi,

We checked the oscilloscope snapshots and it seems like RST is happening not right after the voltage increase.

Could you please give us the i2c register dump of the PMIC. So that we can check all the settings related to voltage regulator.

Regards,
Vishal

Hi,

Any update on the i2c register dumps?

Regards,
Vishal

Hi Vishal,

Sorry for delay,

Here you can find our pmic i2c registers :

act1000:/ # i2cdump -f -y 2 0x60 ( lp87565)
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 12 22 c6 3c c6 3c c6 3c c6 3c 6b 00 6b 00 59 00 ?"?<?<?<?<k.k.Y.
10: 59 00 10 10 10 10 02 02 00 ca 00 00 00 00 00 8c Y.??????.?.....?
20: 0c 91 01 44 44 00 00 00 ff 86 00 13 d6 57 06 06 ???DD....?.??W??
30: dc 59 4d 9a 53 40 10 03 00 04 51 00 00 00 00 00 ?YM?S@??.?Q.....
40: 0c 36 08 50 61 05 00 00 00 00 00 00 00 00 00 00 ?6?Pa?..........
50: 00 00 06 00 00 25 00 00 00 00 00 00 00 00 00 00 ..?..%..........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 ...........?....
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 2c 1e 04 1c 05 db 00 00 00 00 00 00 00 00 00 00 ,?????..........
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

act1000:/ # i2cdump -f -y 2 0x58 (tps65917)
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 11 00 be 3e 00 00 be 3e 00 00 00 00 11 00 c7 47 ?.?>..?>....?.?G
30: 11 00 00 3e 00 00 00 00 11 00 00 ae 00 00 00 00 ?..>....?..?....
40: 00 00 00 00 10 5b 00 ff 00 00 ff 5a 10 00 00 00 ....?[.....Z?...
50: 11 13 11 13 11 31 00 00 00 00 00 00 00 00 11 31 ?????1........?1
60: 00 00 11 13 00 00 00 00 00 00 00 83 06 00 00 00 ..??.......??...
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 80 80 00 .............??.
80: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 04 07 0f 16 00 07 00 00 70 3c 0c 00 00 00 00 be ????.?..p<?....?
b0: 24 00 00 04 00 01 00 54 00 00 00 00 00 00 00 00 $..?.?.T........
c0: 15 15 15 01 00 00 00 00 00 00 00 00 00 00 00 00 ????............
d0: 00 00 00 00 00 00 15 15 00 00 00 00 00 00 00 00 ......??........
e0: 00 00 00 00 00 00 11 11 00 00 00 00 00 00 00 00 ......??........
f0: 00 00 00 00 44 16 44 00 00 00 cb 36 0f 05 00 00 ....D?D...?6??..

Regards

Chokri

Hi Chokri,

Quick look at the register looks good. We have to do more deeper analysis on the full dump and get back to you.

Regards,
Vishal

Hi Chokri,

The i2c register dump looks OK.

Regards,
Vishal

Hello Roxu,

I am looking at the very first oscilloscope snapshot. VDD_MPU(Yellow) is at around 1V tries to get to 1.2V.
The RST line is going down. Is that during the first power on? How is the yellow line already at 1.0V?

Shouldn't the vdd_mpu be at 0v before power on? I am trying to understand the snapshots
and the behavior or voltage w.r.t rstoutn line.

- Keerthy

Hello Keethy,

.What do you mean with "before power on"? As rstoutn is up, the power is on...

What you are seeing is the error sequence we are facing. When the system power up first time, it starts OK. U-boot works fine and then kernel is launched. Once in kernel, the AVS sytem tries to update vdd_mpu. But when trying it, a reset condition is generated and the CPU resets... The power on vdd_mpu voltage is depending on the last configuration of PMIC, that's why sometimes the reset condition is generated when vdd_mpu rises and some times when goes down. This becomes a infinite loop of restarts.

Best regards.

Hello Roxu,

Okay understood so mostly any interaction with pmic voltage setting is causing a reset.
So that is indeed a behavior not seen on J6 plus which has PMIC on i2c1.

We can try writing that register in u-boot using i2c tools to see if any pmic register write
to the buck10 voltage register triggers off a reset.

from u-boot prompt one can try.

i2c dev n --> Where n should be subsituted by the i2c bus number which hosts the PMIC (which is 2 if you are using i2c3)

i2c mw 0x60 0x0A 0x6B --> Setting VOUT to 1.15V. 
i2c mw 0x60 0x0A 0x79 --> Setting VOUT to 1.22V.

Just to check if the same register writes reboot in u-boot as well.

This could also be tried on a kernel where in you have masked the reboot issue.

using

i2cset -f -y 2 0x60 0xA 0x79

I want to know if that causes reset.

Thanks,
Keerthy

Hi Keerthy,

I confirm board reset issue after setting VOUT to 1.22V from uboot or android side.

===uboot===

=> i2c dev 2
Setting bus to 2
=> i2c mw 0x60 0x0A 0x6B
�> i2c mw 0x60 0x0A 0x79
U-Boot SPL 2016.05 (Feb 18 2020 - 12:12:55)
DRA762-GP ES1.0
no pinctrl for hs200_1_8v
no pinctrl for ddr_1_8v
Trying to boot from SPI

===android===

act1000:/ $
act1000:/ $
act1000:/ $
act1000:/ $ i2cset -f -y 2 0x60 0xA 0x79

U-Boot SPL 2016.05 (Feb 18 2020 - 12:12:55)
DRA762-GP ES1.0
no pinctrl for hs200_1_8v
no pinctrl for ddr_1_8v

Regards,

Chokri

Hello Chokri,

Thanks! That rules out all the issues w.r.t driver in kernel and also explains why
changing governors did not work as well. Any change in that voltage register is triggering
a reset for some reason.

One last thing from u-boot just try a simple i2c write to pmic:

For example let us change the slew rate of buck0:

/* Basically changing the slew to 30 mV/uS */

i2c dev 2
i2c mw 0x60 0x3 0x38

Or

/* Setting the BUCK0_FPWM_MP bit so Forced to multi-phase operation */

i2c mc 0x60 0x2 0xc7

I just want to finally see if any i2c write to PMIC is causing reset or only changing the buck0 voltage is causing the reset.

Thanks,
Keerthy

Hi Keerthy,

Write to PMIC OK and NO reset occurred and only changing the buck0 voltage is causing the reset

=>
=> i2c dev 2
Setting bus to 2
=> i2c mw 0x60 0x3 0x38
=> i2c mw 0x60 0x2 0xc7
=>
=>

Regards,

Chokri

Hi Keerthy,

Just for you to know, that we have also tested PMIC to i2c1 and it has the same behaviour.

Best regards.

Thanks Chokri!

Hi Chokri,

I am checking with the PMIC hardware team. They are suggesting to mask the PGOOD signal.

So if you can try this sequence for setting the voltage in u-boot.

i2c dev 2

/* Mask the PGOOD signal */
 i2c mw 0x60 0x28 0x00

/* Set the BUCK0_VOUT */
 i2c mw 0x60 0x0A 0x79

/* Unmask the PGOOD Signal */

 i2c mw 0x60 0x28 0xFF

Let me know if this still resets the board.

Thanks,
Keerthy

Hi Keerthy,

No reset occurred when using mask/unmask  PGOOD_CTRL1.

=> i2c dev 2
Setting bus to 2
=> i2c mw 0x60 0x28 0x00
=>
=> i2c mw 0x60 0x0A 0x79
=> i2c mw 0x60 0x28 0xFF

=>

Regards

Chokri

Hi Chokri,

Thanks. That is indeed good news. Just for my confirmation can you even
try the same from Linux prompt using i2cset?

i2cset -f -y 0x2 0x28 0x0
i2cset -f -y 0x2 0x0A 0x79
i2cset -f -y 0x2 0x28 0xFF

If this works. I will check with Hardware team on the ideal values
of PGOOD registers.

Best Regards,
Keerthy

Hi Keerthy,

Yes from linux also no reset by setting :

act1000:/ # i2cdetect -r -y 2
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 1e --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- UU UU UU 5b -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU
70: -- -- -- -- -- -- -- --
act1000:/ #
act1000:/ #
act1000:/ # i2cset -f -y 2 0x60 0x28 0x0
act1000:/ # i2cset -f -y 2 0x60 0x0A 0x79
act1000:/ # i2cset -f -y 2 0x60 0x28 0xFF
act1000:/ #

Regards,

Chokri

Hi Keetthy,

I'm the HW designer of this PCB. I confirm that the PORZ pin is controlled (and gated), among other lines, by the PGOOD line of the LP87565.

Regards,

Thanks Chokri for the confirmation.

Thanks AClemotte for the information of PCB design.

Chokri,

I am attaching a linux patch for lp87565 regulator driver to mask/unmask PGOOD source
while setting the voltage. Could you try that patch and let me know if your issue is resolved.

Thanks,
Keerthy 

From f4080a405e0fcc1020db8f05129ce6c4b93fd48e Mon Sep 17 00:00:00 2001
From: Keerthy <j-keerthy@ti.com>
Date: Mon, 24 Feb 2020 16:33:09 +0530
Subject: [PATCH] regulator: lp87565: Mask/unmask PGOOD source before setting
 voltages

Mask/unmask PGOOD source before setting voltages. This is required in case
PORZ pin is controlled (and gated) by the PGOOD line of the LP87565.

Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 drivers/regulator/lp87565-regulator.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/lp87565-regulator.c b/drivers/regulator/lp87565-regulator.c
index 04a76ec9bad8..b65cae8f29bc 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -14,6 +14,8 @@
 
 #include <linux/mfd/lp87565.h>
 
+#define LP87565_PGOOD_CTRL1	0x28
+
 #define LP87565_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, _er, _em, \
 			 _delay, _lr, _cr)				\
 	[_id] = {							\
@@ -135,6 +137,29 @@ static int lp87565_buck_get_current_limit(struct regulator_dev *rdev)
 			lp87565_buck_uA[val] : -EINVAL;
 }
 
+static int lp87565_regulator_set_voltage_time_sel(struct regulator_dev *rdev,
+						  unsigned int os,
+						  unsigned int ns)
+{
+	struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
+	int ret;
+
+	/* mask the PGOOD signal source control */
+	ret = regmap_update_bits(lp87565->regmap, LP87565_PGOOD_CTRL1, 0xFF,
+				 0x00);
+	if (ret)
+		return ret;
+
+	regulator_set_voltage_time_sel(rdev, os, ns);
+	if (ret)
+		return ret;
+
+	/* mask the PGOOD signal source control */
+	regmap_update_bits(lp87565->regmap, LP87565_PGOOD_CTRL1, 0xFF, 0xFF);
+
+	return ret;
+}
+
 /* Operations permitted on BUCK0, BUCK1 */
 static struct regulator_ops lp87565_buck_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -144,7 +169,7 @@ static struct regulator_ops lp87565_buck_ops = {
 	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
-	.set_voltage_time_sel	= regulator_set_voltage_time_sel,
+	.set_voltage_time_sel	= lp87565_regulator_set_voltage_time_sel,
 	.set_ramp_delay		= lp87565_buck_set_ramp_delay,
 	.set_current_limit	= lp87565_buck_set_current_limit,
 	.get_current_limit	= lp87565_buck_get_current_limit,
-- 
2.17.1

Hi Chokri,

Let me know if this solves the reboot problem. I will try to upstream this fix.

Thanks,
Keerthy

Good job Keerthy J! Now that we know the behavior of the PGOOD signal, we will stop connecting this output to the PORZ net.

Regards,

Hi Keerthy,

Thank you ! but the issue still reproduced by by applying the shared patch.

I added also log to check PGOOD ctrl reg:

[ 3.722618] omap_voltage_late_init: Voltage driver support not added
[ 3.729621] Adding alias for supply vdd,cpu0 -> vdd,4a003b20.oppdm
[ 3.735851] Adding alias for supply vbb,cpu0 -> vbb,4a003b20.oppdm
[ 3.742142] buck10: supplied by vsys_3v3
[ 3.746772] Adding alias for supply vdd,cpu0 -> vdd,4a003b20.oppdm
[ 3.752979] Adding alias for supply vbb,cpu0 -> vbb,4a003b20.oppdm
[ 3.759996] lp87565 2-0060: >> mask the PGOOD signal source control
[ 3.766990] lp87565 2-0060: << unmask the PGOOD signal source control
[ 3.774195] Power Management for TI OMAP4+ devices.
[ 3.779388] Registering SWP/SWPB emulation handler
[ 3.784644] registered taskstats version 1

U-Boot SPL 2016.05 (Feb 18 2020 - 12:12:55)
DRA762-GP ES1.0
no pinctrl for hs200_1_8v
no pinctrl for ddr_1_8v

It seems that there are an other regulator_set_voltage call ? what do you think ?

Regards,

Chokri 

Hi Chokri,

You are right that is another entry point.
Can you try this patch on top of already shared one?

- Keerthy

From a71a067939a8d422b22a2082859bbbcaa2c46a56 Mon Sep 17 00:00:00 2001
From: Keerthy <j-keerthy@ti.com>
Date: Tue, 25 Feb 2020 14:53:36 +0530
Subject: [PATCH] Test patch

---
 drivers/regulator/lp87565-regulator.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/lp87565-regulator.c b/drivers/regulator/lp87565-regulator.c
index b65cae8f29bc..8bf16237cd92 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -160,13 +160,35 @@ static int lp87565_regulator_set_voltage_time_sel(struct regulator_dev *rdev,
 	return ret;
 }
 
+static int lp87565_regulator_set_voltage_sel(struct regulator_dev *rdev,
+					     unsigned int selector)
+{
+	struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
+	int ret;
+
+	/* mask the PGOOD signal source control */
+	ret = regmap_update_bits(lp87565->regmap, LP87565_PGOOD_CTRL1, 0xFF,
+				 0x00);
+	if (ret)
+		return ret;
+
+	regulator_set_voltage_sel_regmap(rdev, selector);
+	if (ret)
+		return ret;
+
+	/* mask the PGOOD signal source control */
+	regmap_update_bits(lp87565->regmap, LP87565_PGOOD_CTRL1, 0xFF, 0xFF);
+
+	return ret;
+}
+
 /* Operations permitted on BUCK0, BUCK1 */
 static struct regulator_ops lp87565_buck_ops = {
 	.is_enabled		= regulator_is_enabled_regmap,
 	.enable			= regulator_enable_regmap,
 	.disable		= regulator_disable_regmap,
 	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
-	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
+	.set_voltage_sel	= lp87565_regulator_set_voltage_sel,
 	.list_voltage		= regulator_list_voltage_linear_range,
 	.map_voltage		= regulator_map_voltage_linear_range,
 	.set_voltage_time_sel	= lp87565_regulator_set_voltage_time_sel,
-- 
2.17.1

Hi Keerthy,

Thanks a lot , Now NO reset detected with those patches :

 0001-regulator-lp87565-Mask-unmask-PGOOD-source-before-se.patch.txt

0001-Test-patch.patch.txt

act1000:/ #
act1000:/ # i2cdump -f -y 2 0x60
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 12 22 c6 3c c6 3c c6 3c c6 3c 4e 00 6b 00 59 00 ?"?<?<?<?<N.k.Y.
10: 59 00 10 10 10 10 02 02 00 ca 00 00 00 00 00 0c Y.??????.?.....?
20: 0c 91 01 44 44 00 00 00 ff 86 00 13 d6 57 06 06 ???DD....?.??W??
30: dc 59 4d 9a 53 40 10 03 00 04 51 00 00 00 00 00 ?YM?S@??.?Q.....
40: 0c 36 08 50 61 05 00 00 00 00 00 00 00 00 00 00 ?6?Pa?..........
50: 00 00 06 00 00 25 00 00 00 00 00 00 00 00 00 00 ..?..%..........
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 ...........?....
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 2c 1e 04 1c 05 db 00 00 00 00 00 00 00 00 00 00 ,?????..........
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Regards,

Chokri