On i.MX6UL 14x14 EVK board, sensors' power are controlled
by GPIO5_IO02, add GPIO regulator for sensors to manage
their power.
Signed-off-by: Anson Huang <[email protected]>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index c2a9dd5..4074570 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -30,6 +30,16 @@
enable-active-high;
};
+ reg_sensors: regulator-sensors {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sensors_reg>;
+ regulator-name = "sensors-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio5 2 GPIO_ACTIVE_LOW>;
+ };
+
reg_can_3v3: regulator-can-3v3 {
compatible = "regulator-fixed";
regulator-name = "can-3v3";
@@ -448,6 +458,12 @@
>;
};
+ pinctrl_sensors_reg: sensorsreggrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0
+ >;
+ };
+
pinctrl_pwm1: pwm1grp {
fsl,pins = <
MX6UL_PAD_GPIO1_IO08__PWM1_OUT 0x110b0
--
2.7.4
Node name is supposed to be generic, use "magnetometer" instead
of "mag3110" for magnetometer node.
Signed-off-by: Anson Huang <[email protected]>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 4074570..c74ba60 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -190,7 +190,7 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- mag3110@e {
+ magnetometer@e {
compatible = "fsl,mag3110";
reg = <0x0e>;
};
--
2.7.4
On i.MX6UL 14x14 EVK board, mag3110's power is controlled by
sensor regulator, assign power supplies for mag3110 driver
to do power management.
Signed-off-by: Anson Huang <[email protected]>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index c74ba60..7b155ed 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -193,6 +193,8 @@
magnetometer@e {
compatible = "fsl,mag3110";
reg = <0x0e>;
+ vdd-supply = <®_sensors>;
+ vddio-supply = <®_sensors>;
};
};
--
2.7.4
On 24.10.2019 11:51, Anson Huang wrote:
> On i.MX6UL 14x14 EVK board, sensors' power are controlled
> by GPIO5_IO02, add GPIO regulator for sensors to manage
> their power.
>
> Signed-off-by: Anson Huang <[email protected]>
For me this breaks network boot on imx6ul evk, relevant log snippet is this:
fec 20b4000.ethernet eth0: Unable to connect to phy
IP-Config: Failed to open eth0
Looking at schematics (SPF-28616_C2.pdf) I see that SNVS_TAMPER2 pin is
connected to PERI_PWREN which controls VPERI_3V3 which is used across
the board:
* Sensors (VSENSOR_3V3)
* Ethernet (VENET_3V3)
* Bluetooth
* CAN
* Arduino header
* Camera
Maybe there are board revision differences? As far as I can tell this
regulator is not specific to sensors so it should be always on.
> ---
> arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
> index c2a9dd5..4074570 100644
> --- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
> +++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
> @@ -30,6 +30,16 @@
> enable-active-high;
> };
>
> + reg_sensors: regulator-sensors {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sensors_reg>;
> + regulator-name = "sensors-supply";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio5 2 GPIO_ACTIVE_LOW>;
> + };
> +
> reg_can_3v3: regulator-can-3v3 {
> compatible = "regulator-fixed";
> regulator-name = "can-3v3";
> @@ -448,6 +458,12 @@
> >;
> };
>
> + pinctrl_sensors_reg: sensorsreggrp {
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0
> + >;
> + };
> +
> pinctrl_pwm1: pwm1grp {
> fsl,pins = <
> MX6UL_PAD_GPIO1_IO08__PWM1_OUT 0x110b0
>
> Subject: Re: [PATCH 1/3] ARM: dts: imx6ul-14x14-evk: Add sensors' GPIO
> regulator
>
> On 24.10.2019 11:51, Anson Huang wrote:
> > On i.MX6UL 14x14 EVK board, sensors' power are controlled by
> > GPIO5_IO02, add GPIO regulator for sensors to manage their power.
> >
> > Signed-off-by: Anson Huang <[email protected]>
>
> For me this breaks network boot on imx6ul evk, relevant log snippet is this:
>
> fec 20b4000.ethernet eth0: Unable to connect to phy
> IP-Config: Failed to open eth0
>
> Looking at schematics (SPF-28616_C2.pdf) I see that SNVS_TAMPER2 pin is
> connected to PERI_PWREN which controls VPERI_3V3 which is used across
> the board:
> * Sensors (VSENSOR_3V3)
> * Ethernet (VENET_3V3)
> * Bluetooth
> * CAN
> * Arduino header
> * Camera
>
> Maybe there are board revision differences? As far as I can tell this regulator
> is not specific to sensors so it should be always on.
You are correct, this regulator controls many other peripherals, I should make it always ON for now
to make sure NOT break other peripheral, and after all other peripherals controlled
by this regulator have added this regulator management, then the always ON can be
removed.
Thanks,
Anson
On 19-12-11 01:06, Anson Huang wrote:
>
>
> > Subject: Re: [PATCH 1/3] ARM: dts: imx6ul-14x14-evk: Add sensors' GPIO
> > regulator
> >
> > On 24.10.2019 11:51, Anson Huang wrote:
> > > On i.MX6UL 14x14 EVK board, sensors' power are controlled by
> > > GPIO5_IO02, add GPIO regulator for sensors to manage their power.
> > >
> > > Signed-off-by: Anson Huang <[email protected]>
> >
> > For me this breaks network boot on imx6ul evk, relevant log snippet is this:
> >
> > fec 20b4000.ethernet eth0: Unable to connect to phy
> > IP-Config: Failed to open eth0
> >
> > Looking at schematics (SPF-28616_C2.pdf) I see that SNVS_TAMPER2 pin is
> > connected to PERI_PWREN which controls VPERI_3V3 which is used across
> > the board:
> > * Sensors (VSENSOR_3V3)
> > * Ethernet (VENET_3V3)
> > * Bluetooth
> > * CAN
> > * Arduino header
> > * Camera
> >
> > Maybe there are board revision differences? As far as I can tell this regulator
> > is not specific to sensors so it should be always on.
>
> You are correct, this regulator controls many other peripherals, I should make it always ON for now
> to make sure NOT break other peripheral, and after all other peripherals controlled
> by this regulator have added this regulator management, then the always ON can be
> removed.
IMHO marking the regulator as always on shouldn't be the fix. Is it to
much work to add all required regulators? At least please add a comment
which describes the need of the always-on property.
Regards,
Marco
> Thanks,
> Anson
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 2019-12-11 9:27 AM, Marco Felsch wrote:
> On 19-12-11 01:06, Anson Huang wrote:
>>> Subject: Re: [PATCH 1/3] ARM: dts: imx6ul-14x14-evk: Add sensors' GPIO
>>> regulator
>>>
>>> On 24.10.2019 11:51, Anson Huang wrote:
>>>> On i.MX6UL 14x14 EVK board, sensors' power are controlled by
>>>> GPIO5_IO02, add GPIO regulator for sensors to manage their power.
>>>>
>>>> Signed-off-by: Anson Huang <[email protected]>
>>>
>>> For me this breaks network boot on imx6ul evk, relevant log snippet is this:
>>>
>>> fec 20b4000.ethernet eth0: Unable to connect to phy
>>> IP-Config: Failed to open eth0
>>>
>>> Looking at schematics (SPF-28616_C2.pdf) I see that SNVS_TAMPER2 pin is
>>> connected to PERI_PWREN which controls VPERI_3V3 which is used across
>>> the board:
>>> * Sensors (VSENSOR_3V3)
>>> * Ethernet (VENET_3V3)
>>> * Bluetooth
>>> * CAN
>>> * Arduino header
>>> * Camera
>>>
>>> Maybe there are board revision differences? As far as I can tell this regulator
>>> is not specific to sensors so it should be always on.
>>
>> You are correct, this regulator controls many other peripherals, I should make it always ON for now
>> to make sure NOT break other peripheral, and after all other peripherals controlled
>> by this regulator have added this regulator management, then the always ON can be
>> removed.
>
> IMHO marking the regulator as always on shouldn't be the fix. Is it to
> much work to add all required regulators? At least please add a comment
> which describes the need of the always-on property.
I don't have the hardware to test all affected peripherals on hand and
no familiarity with stuff like CAN.
Renaming reg_sensor and adding a comment makes sense.
--
Regards,
Leonard