All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
To: George McCollister
	<george.mccollister-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>,
	"open list:OPEN FIRMWARE AND..."
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"moderated list:ARM PORT"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"open list:OMAP DEVICE TREE..."
	<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm
Date: Fri, 14 Nov 2014 19:41:43 -0600	[thread overview]
Message-ID: <20141115014143.GA808@saruman> (raw)
In-Reply-To: <CAFSKS=PvoibYvP8fauFT8J7t_pRDK56-ZbRvOovu=Q5mrw9wpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

Hi,

On Fri, Nov 14, 2014 at 04:47:02PM -0600, George McCollister wrote:
> Felipe,
> 
> Thank you for your reply.

no problem

> >> +     vbat: fixedregulator@0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vbat";
> >> +             regulator-min-microvolt = <5000000>;
> >> +             regulator-max-microvolt = <5000000>;
> >> +             regulator-boot-on;
> >> +     };
> >
> > I suppose this is the 5V on a power jack, or something like that ?
> 
> It comes with one of three different power supplies (24 - 250VDC, 120
> - 240VAC, 12VDC input) all of which ultimately supply a fixed 5V and
> 3.3V.

Alright :-) Thanks. Do you mind adding a comment on this DTS stating
that just so people don't get confused ?

> >
> >> +     vmmcsd_fixed: fixedregulator@0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vmmcsd_fixed";
> >> +             regulator-min-microvolt = <3300000>;
> >> +             regulator-max-microvolt = <3300000>;
> >
> > but this... I know every other board devices this as a fixed regulator,
> > but is it really a fixed regulator or is supplied by one of the LDOs on
> > the PMIC ?
> >
> 
> It's actually fixed (not from TP65910).

Oh, so this 3.3V fixed rail is the same one derived from from the three
possible power supplies you described above ?

> >> +&am33xx_pinmux {
> >> +     mmc1_pins: pinmux_mmc1_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat3 */
> >> +                     0xf4 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat2 */
> >> +                     0xf8 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat1 */
> >> +                     0xfc (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat0 */
> >> +                     0x100 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_clk */
> >> +                     0x104 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_cmd */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c0_pins: pinmux_i2c0_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x188 (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_sda.i2c0_sda */
> >> +                     0x18c (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_scl.i2c0_scl */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c2_pins: pinmux_i2c2_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x178 (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_ctsn.i2c2_sda */
> >> +                     0x17c (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_rtsn.i2c2_scl */
> >
> > on thing to keep in mind, if you already have external pullups, you
> > might not want to add internal pullups as you'd end up with both
> > resistors in parallel. For I2C the danger is minimal (unless you have a
> > ton of bus capacitance, then it changes high/low time), but it's best to
> > write a more "pristine" DTS. (and sure, I know pretty much every board
> > makes this mistake, but it's best if we don't proliferate the error)
> 
> I'll make sure this is correct and include any required changes in the
> next version of the patch series.

cool, thanks

> >> +&i2c0 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&i2c0_pins>;
> >> +
> >> +     status = "okay";
> >> +     clock-frequency = <400000>;
> >> +
> >> +     serial_config1: serial_config1@20 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x20>;
> >> +     };
> >> +
> >> +     serial_config2: serial_config2@21 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x21>;
> >> +     };
> >> +
> >> +     tps: tps@2d {
> >> +             reg = <0x2d>;
> >
> > which TPS device ? no compatible ?
> >
> >> +/include/ "tps65910.dtsi"
> >
> > oh... okay.
> 
> I'm assuming that means you're okay with this (if not please elaborate
> on how to improve it).

sure, i'm okay. But it's still nice to add a compatible to that tps
node, then again, it's added to tps65910.dtsi so that would be a very
minor nit.

> >> +&tps {
> >> +     vcc1-supply = <&vbat>;
> >> +     vcc2-supply = <&vbat>;
> >> +     vcc3-supply = <&vbat>;
> >> +     vcc4-supply = <&vbat>;
> >> +     vcc5-supply = <&vbat>;
> >> +     vcc6-supply = <&vbat>;
> >> +     vcc7-supply = <&vbat>;
> >> +     vccio-supply = <&vbat>;
> >> +
> >> +     regulators {
> >> +             vrtc_reg: regulator@0 {
> >> +                     regulator-always-on;
> >
> > this should not be always on, you want to pass this as supply to the RTC
> > module so it can manage it. It's also best to give names to all
> > regulators, so people know what they're used for.
> 
> I think we may actually be able to turn this one and possibly two
> others off, I will investigate.
> 
> I've come up with names for all of the regulators being used and will
> include the changes in the next version of the patch series.

Thanks, that helps reviewing the validity of your DTS binding too.

> >> +             };
> >> +
> >> +             vio_reg: regulator@1 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd1_reg: regulator@2 {
> >> +                     regulator-name = "vdd_mpu";
> >> +                     regulator-min-microvolt = <600000>;
> >> +                     regulator-max-microvolt = <1500000>;
> >> +                     regulator-boot-on;
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd2_reg: regulator@3 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd3_reg: regulator@4 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig1_reg: regulator@5 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig2_reg: regulator@6 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vpll_reg: regulator@7 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdac_reg: regulator@8 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux1_reg: regulator@9 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux2_reg: regulator@10 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux33_reg: regulator@11 {
> >
> > isn't this the supply to the other MMC slot ?
> 
> no, it's actually being used for the USB PHY. As I said above I will
> name all regulators being used.

cool, thanks

> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vmmc_reg: regulator@12 {
> >> +                     regulator-min-microvolt = <3300000>;
> >> +                     regulator-max-microvolt = <3300000>;
> >> +                     regulator-always-on;
> >> +             };
> >> +     };
> >> +};
> >> +
> >> +&sham {
> >> +     status = "okay";
> >> +};
> >> +
> >> +&aes {
> >> +     status = "okay";
> >> +};
> >
> > just making sure, are you really using them ?
> 
> We may need them at some point, I'd like to keep them enabled.

fair enough.

> >> +&mmc1 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&mmc1_pins>;
> >> +     bus-width = <4>;
> >> +     status = "okay";
> >> +     vmmc-supply = <&vmmc_reg>;
> >> +     ti,vcc-aux-disable-is-sleep;
> >
> > this binding isn't documented anywhere. What was it supposed to do ?
> 
> I mentioned in the commit message that there is a micro SD slot.

Sure, that's fine. My comment is regarding
"ti,vcc-aux-disable-is-sleep", it's not documentated or used anywhere
:-)

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm
Date: Fri, 14 Nov 2014 19:41:43 -0600	[thread overview]
Message-ID: <20141115014143.GA808@saruman> (raw)
In-Reply-To: <CAFSKS=PvoibYvP8fauFT8J7t_pRDK56-ZbRvOovu=Q5mrw9wpA@mail.gmail.com>

Hi,

On Fri, Nov 14, 2014 at 04:47:02PM -0600, George McCollister wrote:
> Felipe,
> 
> Thank you for your reply.

no problem

> >> +     vbat: fixedregulator at 0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vbat";
> >> +             regulator-min-microvolt = <5000000>;
> >> +             regulator-max-microvolt = <5000000>;
> >> +             regulator-boot-on;
> >> +     };
> >
> > I suppose this is the 5V on a power jack, or something like that ?
> 
> It comes with one of three different power supplies (24 - 250VDC, 120
> - 240VAC, 12VDC input) all of which ultimately supply a fixed 5V and
> 3.3V.

Alright :-) Thanks. Do you mind adding a comment on this DTS stating
that just so people don't get confused ?

> >
> >> +     vmmcsd_fixed: fixedregulator at 0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vmmcsd_fixed";
> >> +             regulator-min-microvolt = <3300000>;
> >> +             regulator-max-microvolt = <3300000>;
> >
> > but this... I know every other board devices this as a fixed regulator,
> > but is it really a fixed regulator or is supplied by one of the LDOs on
> > the PMIC ?
> >
> 
> It's actually fixed (not from TP65910).

Oh, so this 3.3V fixed rail is the same one derived from from the three
possible power supplies you described above ?

> >> +&am33xx_pinmux {
> >> +     mmc1_pins: pinmux_mmc1_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat3 */
> >> +                     0xf4 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat2 */
> >> +                     0xf8 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat1 */
> >> +                     0xfc (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat0 */
> >> +                     0x100 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_clk */
> >> +                     0x104 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_cmd */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c0_pins: pinmux_i2c0_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x188 (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_sda.i2c0_sda */
> >> +                     0x18c (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_scl.i2c0_scl */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c2_pins: pinmux_i2c2_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x178 (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_ctsn.i2c2_sda */
> >> +                     0x17c (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_rtsn.i2c2_scl */
> >
> > on thing to keep in mind, if you already have external pullups, you
> > might not want to add internal pullups as you'd end up with both
> > resistors in parallel. For I2C the danger is minimal (unless you have a
> > ton of bus capacitance, then it changes high/low time), but it's best to
> > write a more "pristine" DTS. (and sure, I know pretty much every board
> > makes this mistake, but it's best if we don't proliferate the error)
> 
> I'll make sure this is correct and include any required changes in the
> next version of the patch series.

cool, thanks

> >> +&i2c0 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&i2c0_pins>;
> >> +
> >> +     status = "okay";
> >> +     clock-frequency = <400000>;
> >> +
> >> +     serial_config1: serial_config1 at 20 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x20>;
> >> +     };
> >> +
> >> +     serial_config2: serial_config2 at 21 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x21>;
> >> +     };
> >> +
> >> +     tps: tps at 2d {
> >> +             reg = <0x2d>;
> >
> > which TPS device ? no compatible ?
> >
> >> +/include/ "tps65910.dtsi"
> >
> > oh... okay.
> 
> I'm assuming that means you're okay with this (if not please elaborate
> on how to improve it).

sure, i'm okay. But it's still nice to add a compatible to that tps
node, then again, it's added to tps65910.dtsi so that would be a very
minor nit.

> >> +&tps {
> >> +     vcc1-supply = <&vbat>;
> >> +     vcc2-supply = <&vbat>;
> >> +     vcc3-supply = <&vbat>;
> >> +     vcc4-supply = <&vbat>;
> >> +     vcc5-supply = <&vbat>;
> >> +     vcc6-supply = <&vbat>;
> >> +     vcc7-supply = <&vbat>;
> >> +     vccio-supply = <&vbat>;
> >> +
> >> +     regulators {
> >> +             vrtc_reg: regulator at 0 {
> >> +                     regulator-always-on;
> >
> > this should not be always on, you want to pass this as supply to the RTC
> > module so it can manage it. It's also best to give names to all
> > regulators, so people know what they're used for.
> 
> I think we may actually be able to turn this one and possibly two
> others off, I will investigate.
> 
> I've come up with names for all of the regulators being used and will
> include the changes in the next version of the patch series.

Thanks, that helps reviewing the validity of your DTS binding too.

> >> +             };
> >> +
> >> +             vio_reg: regulator at 1 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd1_reg: regulator at 2 {
> >> +                     regulator-name = "vdd_mpu";
> >> +                     regulator-min-microvolt = <600000>;
> >> +                     regulator-max-microvolt = <1500000>;
> >> +                     regulator-boot-on;
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd2_reg: regulator at 3 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd3_reg: regulator at 4 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig1_reg: regulator at 5 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig2_reg: regulator at 6 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vpll_reg: regulator at 7 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdac_reg: regulator at 8 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux1_reg: regulator at 9 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux2_reg: regulator at 10 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux33_reg: regulator at 11 {
> >
> > isn't this the supply to the other MMC slot ?
> 
> no, it's actually being used for the USB PHY. As I said above I will
> name all regulators being used.

cool, thanks

> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vmmc_reg: regulator at 12 {
> >> +                     regulator-min-microvolt = <3300000>;
> >> +                     regulator-max-microvolt = <3300000>;
> >> +                     regulator-always-on;
> >> +             };
> >> +     };
> >> +};
> >> +
> >> +&sham {
> >> +     status = "okay";
> >> +};
> >> +
> >> +&aes {
> >> +     status = "okay";
> >> +};
> >
> > just making sure, are you really using them ?
> 
> We may need them at some point, I'd like to keep them enabled.

fair enough.

> >> +&mmc1 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&mmc1_pins>;
> >> +     bus-width = <4>;
> >> +     status = "okay";
> >> +     vmmc-supply = <&vmmc_reg>;
> >> +     ti,vcc-aux-disable-is-sleep;
> >
> > this binding isn't documented anywhere. What was it supposed to do ?
> 
> I mentioned in the commit message that there is a micro SD slot.

Sure, that's fine. My comment is regarding
"ti,vcc-aux-disable-is-sleep", it's not documentated or used anywhere
:-)

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141114/7c2dbf7f/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: George McCollister <george.mccollister@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>,
	"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
	"open list:OMAP DEVICE TREE..." <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm
Date: Fri, 14 Nov 2014 19:41:43 -0600	[thread overview]
Message-ID: <20141115014143.GA808@saruman> (raw)
In-Reply-To: <CAFSKS=PvoibYvP8fauFT8J7t_pRDK56-ZbRvOovu=Q5mrw9wpA@mail.gmail.com>

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

Hi,

On Fri, Nov 14, 2014 at 04:47:02PM -0600, George McCollister wrote:
> Felipe,
> 
> Thank you for your reply.

no problem

> >> +     vbat: fixedregulator@0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vbat";
> >> +             regulator-min-microvolt = <5000000>;
> >> +             regulator-max-microvolt = <5000000>;
> >> +             regulator-boot-on;
> >> +     };
> >
> > I suppose this is the 5V on a power jack, or something like that ?
> 
> It comes with one of three different power supplies (24 - 250VDC, 120
> - 240VAC, 12VDC input) all of which ultimately supply a fixed 5V and
> 3.3V.

Alright :-) Thanks. Do you mind adding a comment on this DTS stating
that just so people don't get confused ?

> >
> >> +     vmmcsd_fixed: fixedregulator@0 {
> >> +             compatible = "regulator-fixed";
> >> +             regulator-name = "vmmcsd_fixed";
> >> +             regulator-min-microvolt = <3300000>;
> >> +             regulator-max-microvolt = <3300000>;
> >
> > but this... I know every other board devices this as a fixed regulator,
> > but is it really a fixed regulator or is supplied by one of the LDOs on
> > the PMIC ?
> >
> 
> It's actually fixed (not from TP65910).

Oh, so this 3.3V fixed rail is the same one derived from from the three
possible power supplies you described above ?

> >> +&am33xx_pinmux {
> >> +     mmc1_pins: pinmux_mmc1_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat3 */
> >> +                     0xf4 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat2 */
> >> +                     0xf8 (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat1 */
> >> +                     0xfc (PIN_INPUT_PULLUP | MUX_MODE0)     /* mmc0_dat0 */
> >> +                     0x100 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_clk */
> >> +                     0x104 (PIN_INPUT_PULLUP | MUX_MODE0)    /* mmc0_cmd */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c0_pins: pinmux_i2c0_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x188 (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_sda.i2c0_sda */
> >> +                     0x18c (PIN_INPUT_PULLUP | MUX_MODE0)    /* i2c0_scl.i2c0_scl */
> >> +             >;
> >> +     };
> >> +
> >> +     i2c2_pins: pinmux_i2c2_pins {
> >> +             pinctrl-single,pins = <
> >> +                     0x178 (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_ctsn.i2c2_sda */
> >> +                     0x17c (PIN_INPUT_PULLUP | MUX_MODE3)    /* uart1_rtsn.i2c2_scl */
> >
> > on thing to keep in mind, if you already have external pullups, you
> > might not want to add internal pullups as you'd end up with both
> > resistors in parallel. For I2C the danger is minimal (unless you have a
> > ton of bus capacitance, then it changes high/low time), but it's best to
> > write a more "pristine" DTS. (and sure, I know pretty much every board
> > makes this mistake, but it's best if we don't proliferate the error)
> 
> I'll make sure this is correct and include any required changes in the
> next version of the patch series.

cool, thanks

> >> +&i2c0 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&i2c0_pins>;
> >> +
> >> +     status = "okay";
> >> +     clock-frequency = <400000>;
> >> +
> >> +     serial_config1: serial_config1@20 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x20>;
> >> +     };
> >> +
> >> +     serial_config2: serial_config2@21 {
> >> +             compatible = "nxp,pca9539";
> >> +             reg = <0x21>;
> >> +     };
> >> +
> >> +     tps: tps@2d {
> >> +             reg = <0x2d>;
> >
> > which TPS device ? no compatible ?
> >
> >> +/include/ "tps65910.dtsi"
> >
> > oh... okay.
> 
> I'm assuming that means you're okay with this (if not please elaborate
> on how to improve it).

sure, i'm okay. But it's still nice to add a compatible to that tps
node, then again, it's added to tps65910.dtsi so that would be a very
minor nit.

> >> +&tps {
> >> +     vcc1-supply = <&vbat>;
> >> +     vcc2-supply = <&vbat>;
> >> +     vcc3-supply = <&vbat>;
> >> +     vcc4-supply = <&vbat>;
> >> +     vcc5-supply = <&vbat>;
> >> +     vcc6-supply = <&vbat>;
> >> +     vcc7-supply = <&vbat>;
> >> +     vccio-supply = <&vbat>;
> >> +
> >> +     regulators {
> >> +             vrtc_reg: regulator@0 {
> >> +                     regulator-always-on;
> >
> > this should not be always on, you want to pass this as supply to the RTC
> > module so it can manage it. It's also best to give names to all
> > regulators, so people know what they're used for.
> 
> I think we may actually be able to turn this one and possibly two
> others off, I will investigate.
> 
> I've come up with names for all of the regulators being used and will
> include the changes in the next version of the patch series.

Thanks, that helps reviewing the validity of your DTS binding too.

> >> +             };
> >> +
> >> +             vio_reg: regulator@1 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd1_reg: regulator@2 {
> >> +                     regulator-name = "vdd_mpu";
> >> +                     regulator-min-microvolt = <600000>;
> >> +                     regulator-max-microvolt = <1500000>;
> >> +                     regulator-boot-on;
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd2_reg: regulator@3 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdd3_reg: regulator@4 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig1_reg: regulator@5 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdig2_reg: regulator@6 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vpll_reg: regulator@7 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vdac_reg: regulator@8 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux1_reg: regulator@9 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux2_reg: regulator@10 {
> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vaux33_reg: regulator@11 {
> >
> > isn't this the supply to the other MMC slot ?
> 
> no, it's actually being used for the USB PHY. As I said above I will
> name all regulators being used.

cool, thanks

> >> +                     regulator-always-on;
> >> +             };
> >> +
> >> +             vmmc_reg: regulator@12 {
> >> +                     regulator-min-microvolt = <3300000>;
> >> +                     regulator-max-microvolt = <3300000>;
> >> +                     regulator-always-on;
> >> +             };
> >> +     };
> >> +};
> >> +
> >> +&sham {
> >> +     status = "okay";
> >> +};
> >> +
> >> +&aes {
> >> +     status = "okay";
> >> +};
> >
> > just making sure, are you really using them ?
> 
> We may need them at some point, I'd like to keep them enabled.

fair enough.

> >> +&mmc1 {
> >> +     pinctrl-names = "default";
> >> +     pinctrl-0 = <&mmc1_pins>;
> >> +     bus-width = <4>;
> >> +     status = "okay";
> >> +     vmmc-supply = <&vmmc_reg>;
> >> +     ti,vcc-aux-disable-is-sleep;
> >
> > this binding isn't documented anywhere. What was it supposed to do ?
> 
> I mentioned in the commit message that there is a micro SD slot.

Sure, that's fine. My comment is regarding
"ti,vcc-aux-disable-is-sleep", it's not documentated or used anywhere
:-)

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2014-11-15  1:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12 22:41 [PATCH 1/2] of: Add vendor prefix for NovaTech LLC George McCollister
2014-11-12 22:41 ` George McCollister
2014-11-12 22:41 ` [PATCH 2/2] ARM: dts: Add devicetree for NovaTech OrionLXm George McCollister
2014-11-12 22:41   ` George McCollister
2014-11-12 22:41   ` George McCollister
     [not found]   ` <1415832094-20991-2-git-send-email-george.mccollister-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-13  0:59     ` Felipe Balbi
2014-11-13  0:59       ` Felipe Balbi
2014-11-13  0:59       ` Felipe Balbi
2014-11-14 22:47       ` George McCollister
2014-11-14 22:47         ` George McCollister
2014-11-14 22:47         ` George McCollister
     [not found]         ` <CAFSKS=PvoibYvP8fauFT8J7t_pRDK56-ZbRvOovu=Q5mrw9wpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-15  1:41           ` Felipe Balbi [this message]
2014-11-15  1:41             ` Felipe Balbi
2014-11-15  1:41             ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141115014143.GA808@saruman \
    --to=balbi-l0cymroini0@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=george.mccollister-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.