| Message ID | 1369423702-31501-1-git-send-email-khilman@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 12:28-20130524, Kevin Hilman wrote: > Earlier commits ensured proper muxing of pins related to proper > TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure > sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: > OMAP4: TWL: mux sys_drm_msecure as output for PMIC). > > However these only fixed legacy boot and not DT boot. For DT boot, > the default mux values need to be set properly in DT. > > Cc: Tony Lindgren <tony@atomide.com> > Signed-off-by: Kevin Hilman <khilman@linaro.org> > --- > Applies on v3.10-rc2 > > arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ > arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ > 2 files changed, 16 insertions(+) > > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi > index 03bd60d..a7a9bc0 100644 > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi > @@ -59,6 +59,7 @@ > &omap4_pmx_core { > pinctrl-names = "default"; > pinctrl-0 = < > + &twl6030_pins > &twl6040_pins > &mcpdm_pins > &mcbsp1_pins > @@ -66,6 +67,13 @@ > &tpd12s015_pins > >; > > + twl6030_pins: pinmux_twl6030_pins { > + pinctrl-single,pins = < > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ I can understand this - IRQ request comes here. verified on OMAP4460 Panda-ES. # omapconf read 0x4A10019C 4118011B > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ I do not understand this. OMAP4460 TRM: Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ omapconf read 0x4A31E054 010F010F I do not understand this configuration. mux modes for FREF_CLK0_OUT_MUXMODE: 0x0: Select fref_clk0_out 0x1: Select fref_clk1_req 0x2: Reserved 0x3: Select gpio_wk6 0x5: Select sdmmc2_dat7 0x6: Select hw_dbg6 0x7: Select safe_mode Why are we setting mode 0(clk out) here? > + >; > + }; > + > twl6040_pins: pinmux_twl6040_pins { > pinctrl-single,pins = < > 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */ > diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts > index a35d9cd..5ad0c10 100644 > --- a/arch/arm/boot/dts/omap4-sdp.dts > +++ b/arch/arm/boot/dts/omap4-sdp.dts > @@ -145,6 +145,7 @@ > &omap4_pmx_core { > pinctrl-names = "default"; > pinctrl-0 = < > + &twl6030_pins > &twl6040_pins > &mcpdm_pins > &dmic_pins > @@ -179,6 +180,13 @@ > >; > }; > > + twl6030_pins: pinmux_twl6030_pins { > + pinctrl-single,pins = < > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ > + >; > + }; > + > twl6040_pins: pinmux_twl6040_pins { > pinctrl-single,pins = < > 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */ > -- > 1.8.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15:09-20130524, Nishanth Menon wrote: > On 12:28-20130524, Kevin Hilman wrote: > > Earlier commits ensured proper muxing of pins related to proper > > TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure > > sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: > > OMAP4: TWL: mux sys_drm_msecure as output for PMIC). > > > > However these only fixed legacy boot and not DT boot. For DT boot, > > the default mux values need to be set properly in DT. > > > > Cc: Tony Lindgren <tony@atomide.com> > > Signed-off-by: Kevin Hilman <khilman@linaro.org> > > --- > > Applies on v3.10-rc2 > > > > arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ > > arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ > > 2 files changed, 16 insertions(+) > > > > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi > > index 03bd60d..a7a9bc0 100644 > > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi > > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi > > @@ -59,6 +59,7 @@ > > &omap4_pmx_core { > > pinctrl-names = "default"; > > pinctrl-0 = < > > + &twl6030_pins > > &twl6040_pins > > &mcpdm_pins > > &mcbsp1_pins > > @@ -66,6 +67,13 @@ > > &tpd12s015_pins > > >; > > > > + twl6030_pins: pinmux_twl6030_pins { > > + pinctrl-single,pins = < > > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ > I can understand this - IRQ request comes here. > verified on OMAP4460 Panda-ES. > # omapconf read 0x4A10019C > 4118011B > > > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ > I do not understand this. > OMAP4460 TRM: > Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ > omapconf read 0x4A31E054 > 010F010F > > I do not understand this configuration. mux modes for > FREF_CLK0_OUT_MUXMODE: > 0x0: Select fref_clk0_out > 0x1: Select fref_clk1_req > 0x2: Reserved > 0x3: Select gpio_wk6 > 0x5: Select sdmmc2_dat7 > 0x6: Select hw_dbg6 > 0x7: Select safe_mode > > Why are we setting mode 0(clk out) here? I did a bit more research into this: MSECURE line needs to be set for us to set anything with TWL6030 RTC. PandaBoard ES(4460) = this is on OMAP PIN AD4 PandaBoard (4430) = this is on OMAP PIN AD2 translating this back, PandaBoard ES OMAp4460 pin AD4: FREF_CLK3_OUT/FREF_CLK2_REQ/SYS_SECURE_INDICATOR/GPIO_WK31/C2C_WAKEREQOUT/SDMMC2_DAT5/ATTILA_HW_DBG8/SAFE_MODE This is at register 0x4A31E054(higher 16 bits) - however since we are GP device, SYS_SECURE_INDICATOR(mode 2) is reserved. PandaBoard OMAP4430 pin AD2: FREF_CLK0_OUT/FREF_CLK1_REQ/SYS_DRM_MSECURE/GPIO_WK6/SDMMC2_DAT7/ATTILA_HW_DBG6/SAFE_MOD This is at register 0x4A31E054(lower 16 bits) - however since we are GP device, SYS_DRM_MSECURE(mode 2) is reserved. To use RTC, we will have to use GPIO. on pandaboard ES, we need GPIO31 and PandaBoard, 6. Further the pinctrl offsets will vary as well between the same. IMHO, we need GPIO support and pinmux appropritate to the same to allow RTC to work. > > + >; > > + }; > > + > > twl6040_pins: pinmux_twl6040_pins { > > pinctrl-single,pins = < > > 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */ > > diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts > > index a35d9cd..5ad0c10 100644 > > --- a/arch/arm/boot/dts/omap4-sdp.dts > > +++ b/arch/arm/boot/dts/omap4-sdp.dts > > @@ -145,6 +145,7 @@ > > &omap4_pmx_core { > > pinctrl-names = "default"; > > pinctrl-0 = < > > + &twl6030_pins > > &twl6040_pins > > &mcpdm_pins > > &dmic_pins > > @@ -179,6 +180,13 @@ > > >; > > }; > > > > + twl6030_pins: pinmux_twl6030_pins { > > + pinctrl-single,pins = < > > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ > > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ > > + >; > > + }; > > + > > twl6040_pins: pinmux_twl6040_pins { > > pinctrl-single,pins = < > > 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */ > > -- > > 1.8.2 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Regards, > Nishanth Menon > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Nishanth Menon <nm@ti.com> writes: > On 15:09-20130524, Nishanth Menon wrote: >> On 12:28-20130524, Kevin Hilman wrote: >> > Earlier commits ensured proper muxing of pins related to proper >> > TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure >> > sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: >> > OMAP4: TWL: mux sys_drm_msecure as output for PMIC). >> > >> > However these only fixed legacy boot and not DT boot. For DT boot, >> > the default mux values need to be set properly in DT. >> > >> > Cc: Tony Lindgren <tony@atomide.com> >> > Signed-off-by: Kevin Hilman <khilman@linaro.org> >> > --- >> > Applies on v3.10-rc2 >> > >> > arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ >> > arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ >> > 2 files changed, 16 insertions(+) >> > >> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi >> > index 03bd60d..a7a9bc0 100644 >> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi >> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi >> > @@ -59,6 +59,7 @@ >> > &omap4_pmx_core { >> > pinctrl-names = "default"; >> > pinctrl-0 = < >> > + &twl6030_pins >> > &twl6040_pins >> > &mcpdm_pins >> > &mcbsp1_pins >> > @@ -66,6 +67,13 @@ >> > &tpd12s015_pins >> > >; >> > >> > + twl6030_pins: pinmux_twl6030_pins { >> > + pinctrl-single,pins = < >> > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ >> I can understand this - IRQ request comes here. >> verified on OMAP4460 Panda-ES. >> # omapconf read 0x4A10019C >> 4118011B >> >> > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ >> I do not understand this. >> OMAP4460 TRM: >> Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ >> omapconf read 0x4A31E054 >> 010F010F >> >> I do not understand this configuration. mux modes for >> FREF_CLK0_OUT_MUXMODE: >> 0x0: Select fref_clk0_out >> 0x1: Select fref_clk1_req >> 0x2: Reserved >> 0x3: Select gpio_wk6 >> 0x5: Select sdmmc2_dat7 >> 0x6: Select hw_dbg6 >> 0x7: Select safe_mode >> >> Why are we setting mode 0(clk out) here? > > I did a bit more research into this: > MSECURE line needs to be set for us to set anything with TWL6030 RTC. Yes, the commit referenced in the changelog described that in detail. > PandaBoard ES(4460) = this is on OMAP PIN AD4 > PandaBoard (4430) = this is on OMAP PIN AD2 > > translating this back, > PandaBoard ES OMAp4460 pin AD4: > FREF_CLK3_OUT/FREF_CLK2_REQ/SYS_SECURE_INDICATOR/GPIO_WK31/C2C_WAKEREQOUT/SDMMC2_DAT5/ATTILA_HW_DBG8/SAFE_MODE > This is at register 0x4A31E054(higher 16 bits) - however since we are GP device, > SYS_SECURE_INDICATOR(mode 2) is reserved. > PandaBoard OMAP4430 pin AD2: > FREF_CLK0_OUT/FREF_CLK1_REQ/SYS_DRM_MSECURE/GPIO_WK6/SDMMC2_DAT7/ATTILA_HW_DBG6/SAFE_MOD > This is at register 0x4A31E054(lower 16 bits) - however since we are GP device, > SYS_DRM_MSECURE(mode 2) is reserved. > > To use RTC, we will have to use GPIO. > on pandaboard ES, we need GPIO31 and PandaBoard, 6. > > Further the pinctrl offsets will vary as well between the same. > > IMHO, we need GPIO support and pinmux appropritate to the same to allow > RTC to work. I don't follow at all what you're trying to say. The current settings are working fine and have been tested on both 4430/Panda and 4460/Panda-ES. The goal of this patch is to make default mux settings for twl6030 for DT boot match current legacy boot in mainline. The commits referenced in the changelog setup some default muxing for twl6030 (see changelogs referenced and mux calls in twl-common.c:omap4_pmic_init()) Without those mux settings, RTC wakeup on legacy boot does not work (tested on 4430/panda, 4460/Panda with recent u-boot v2013.04 where most of the old mux setup is gone.) With those settings, RTC wakeup works. Yes, the TRM has some mode bits marked as reserved, but that doesn't mean they don't work. It just means the documentation is squirreled away in the secure TRM addendum. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 24, 2013 at 4:19 PM, Kevin Hilman <khilman@linaro.org> wrote: > Nishanth Menon <nm@ti.com> writes: > >> On 15:09-20130524, Nishanth Menon wrote: >>> On 12:28-20130524, Kevin Hilman wrote: >>> > Earlier commits ensured proper muxing of pins related to proper >>> > TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure >>> > sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: >>> > OMAP4: TWL: mux sys_drm_msecure as output for PMIC). >>> > >>> > However these only fixed legacy boot and not DT boot. For DT boot, >>> > the default mux values need to be set properly in DT. >>> > >>> > Cc: Tony Lindgren <tony@atomide.com> >>> > Signed-off-by: Kevin Hilman <khilman@linaro.org> >>> > --- >>> > Applies on v3.10-rc2 >>> > >>> > arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ >>> > arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ >>> > 2 files changed, 16 insertions(+) >>> > >>> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi >>> > index 03bd60d..a7a9bc0 100644 >>> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi >>> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi >>> > @@ -59,6 +59,7 @@ >>> > &omap4_pmx_core { >>> > pinctrl-names = "default"; >>> > pinctrl-0 = < >>> > + &twl6030_pins >>> > &twl6040_pins >>> > &mcpdm_pins >>> > &mcbsp1_pins >>> > @@ -66,6 +67,13 @@ >>> > &tpd12s015_pins >>> > >; >>> > >>> > + twl6030_pins: pinmux_twl6030_pins { >>> > + pinctrl-single,pins = < >>> > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ >>> I can understand this - IRQ request comes here. >>> verified on OMAP4460 Panda-ES. >>> # omapconf read 0x4A10019C >>> 4118011B >>> >>> > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ >>> I do not understand this. >>> OMAP4460 TRM: >>> Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ >>> omapconf read 0x4A31E054 >>> 010F010F >>> >>> I do not understand this configuration. mux modes for >>> FREF_CLK0_OUT_MUXMODE: >>> 0x0: Select fref_clk0_out >>> 0x1: Select fref_clk1_req >>> 0x2: Reserved >>> 0x3: Select gpio_wk6 >>> 0x5: Select sdmmc2_dat7 >>> 0x6: Select hw_dbg6 >>> 0x7: Select safe_mode >>> >>> Why are we setting mode 0(clk out) here? >> >> I did a bit more research into this: >> MSECURE line needs to be set for us to set anything with TWL6030 RTC. > > Yes, the commit referenced in the changelog described that in detail. > >> PandaBoard ES(4460) = this is on OMAP PIN AD4 >> PandaBoard (4430) = this is on OMAP PIN AD2 >> >> translating this back, >> PandaBoard ES OMAp4460 pin AD4: >> FREF_CLK3_OUT/FREF_CLK2_REQ/SYS_SECURE_INDICATOR/GPIO_WK31/C2C_WAKEREQOUT/SDMMC2_DAT5/ATTILA_HW_DBG8/SAFE_MODE >> This is at register 0x4A31E054(higher 16 bits) - however since we are GP device, >> SYS_SECURE_INDICATOR(mode 2) is reserved. >> PandaBoard OMAP4430 pin AD2: >> FREF_CLK0_OUT/FREF_CLK1_REQ/SYS_DRM_MSECURE/GPIO_WK6/SDMMC2_DAT7/ATTILA_HW_DBG6/SAFE_MOD >> This is at register 0x4A31E054(lower 16 bits) - however since we are GP device, >> SYS_DRM_MSECURE(mode 2) is reserved. >> >> To use RTC, we will have to use GPIO. >> on pandaboard ES, we need GPIO31 and PandaBoard, 6. >> >> Further the pinctrl offsets will vary as well between the same. >> >> IMHO, we need GPIO support and pinmux appropritate to the same to allow >> RTC to work. > > I don't follow at all what you're trying to say. The current settings > are working fine and have been tested on both 4430/Panda and 4460/Panda-ES. > > The goal of this patch is to make default mux settings for twl6030 for > DT boot match current legacy boot in mainline. > > The commits referenced in the changelog setup some default muxing for > twl6030 (see changelogs referenced and mux calls in > twl-common.c:omap4_pmic_init()) > > Without those mux settings, RTC wakeup on legacy boot does not work > (tested on 4430/panda, 4460/Panda with recent u-boot v2013.04 where most > of the old mux setup is gone.) With those settings, RTC wakeup works. > > Yes, the TRM has some mode bits marked as reserved, but that doesn't > mean they don't work. It just means the documentation is squirreled > away in the secure TRM addendum. > Actually 2 things: a) patch seems to do the wrong thing for 4460 - 0x18 offset should have been used instead of 0x14 which is correct for 4430? b) yes, I understand, the current settings we did worked, but the mode(0) we are setting to is real weird - we are setting it up for clk0 out - I cant even think why it is even working in the first place :( - is it because we are pumping out sysclkout and as a result we are lucky that msecure is being sampled at the right point by twl6030 allowing rtc access? either way, IMHO, the configuration is wrong. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nishanth Menon <nm@ti.com> writes: > On Fri, May 24, 2013 at 4:19 PM, Kevin Hilman <khilman@linaro.org> wrote: >> Nishanth Menon <nm@ti.com> writes: >> >>> On 15:09-20130524, Nishanth Menon wrote: >>>> On 12:28-20130524, Kevin Hilman wrote: >>>> > Earlier commits ensured proper muxing of pins related to proper >>>> > TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure >>>> > sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: >>>> > OMAP4: TWL: mux sys_drm_msecure as output for PMIC). >>>> > >>>> > However these only fixed legacy boot and not DT boot. For DT boot, >>>> > the default mux values need to be set properly in DT. >>>> > >>>> > Cc: Tony Lindgren <tony@atomide.com> >>>> > Signed-off-by: Kevin Hilman <khilman@linaro.org> >>>> > --- >>>> > Applies on v3.10-rc2 >>>> > >>>> > arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ >>>> > arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ >>>> > 2 files changed, 16 insertions(+) >>>> > >>>> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi >>>> > index 03bd60d..a7a9bc0 100644 >>>> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi >>>> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi >>>> > @@ -59,6 +59,7 @@ >>>> > &omap4_pmx_core { >>>> > pinctrl-names = "default"; >>>> > pinctrl-0 = < >>>> > + &twl6030_pins >>>> > &twl6040_pins >>>> > &mcpdm_pins >>>> > &mcbsp1_pins >>>> > @@ -66,6 +67,13 @@ >>>> > &tpd12s015_pins >>>> > >; >>>> > >>>> > + twl6030_pins: pinmux_twl6030_pins { >>>> > + pinctrl-single,pins = < >>>> > + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ >>>> I can understand this - IRQ request comes here. >>>> verified on OMAP4460 Panda-ES. >>>> # omapconf read 0x4A10019C >>>> 4118011B >>>> >>>> > + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ >>>> I do not understand this. >>>> OMAP4460 TRM: >>>> Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ >>>> omapconf read 0x4A31E054 >>>> 010F010F >>>> >>>> I do not understand this configuration. mux modes for >>>> FREF_CLK0_OUT_MUXMODE: >>>> 0x0: Select fref_clk0_out >>>> 0x1: Select fref_clk1_req >>>> 0x2: Reserved >>>> 0x3: Select gpio_wk6 >>>> 0x5: Select sdmmc2_dat7 >>>> 0x6: Select hw_dbg6 >>>> 0x7: Select safe_mode >>>> >>>> Why are we setting mode 0(clk out) here? >>> >>> I did a bit more research into this: >>> MSECURE line needs to be set for us to set anything with TWL6030 RTC. >> >> Yes, the commit referenced in the changelog described that in detail. >> >>> PandaBoard ES(4460) = this is on OMAP PIN AD4 >>> PandaBoard (4430) = this is on OMAP PIN AD2 >>> >>> translating this back, >>> PandaBoard ES OMAp4460 pin AD4: >>> FREF_CLK3_OUT/FREF_CLK2_REQ/SYS_SECURE_INDICATOR/GPIO_WK31/C2C_WAKEREQOUT/SDMMC2_DAT5/ATTILA_HW_DBG8/SAFE_MODE >>> This is at register 0x4A31E054(higher 16 bits) - however since we are GP device, >>> SYS_SECURE_INDICATOR(mode 2) is reserved. >>> PandaBoard OMAP4430 pin AD2: >>> FREF_CLK0_OUT/FREF_CLK1_REQ/SYS_DRM_MSECURE/GPIO_WK6/SDMMC2_DAT7/ATTILA_HW_DBG6/SAFE_MOD >>> This is at register 0x4A31E054(lower 16 bits) - however since we are GP device, >>> SYS_DRM_MSECURE(mode 2) is reserved. >>> >>> To use RTC, we will have to use GPIO. >>> on pandaboard ES, we need GPIO31 and PandaBoard, 6. >>> >>> Further the pinctrl offsets will vary as well between the same. >>> >>> IMHO, we need GPIO support and pinmux appropritate to the same to allow >>> RTC to work. >> >> I don't follow at all what you're trying to say. The current settings >> are working fine and have been tested on both 4430/Panda and 4460/Panda-ES. >> >> The goal of this patch is to make default mux settings for twl6030 for >> DT boot match current legacy boot in mainline. >> >> The commits referenced in the changelog setup some default muxing for >> twl6030 (see changelogs referenced and mux calls in >> twl-common.c:omap4_pmic_init()) >> >> Without those mux settings, RTC wakeup on legacy boot does not work >> (tested on 4430/panda, 4460/Panda with recent u-boot v2013.04 where most >> of the old mux setup is gone.) With those settings, RTC wakeup works. >> >> Yes, the TRM has some mode bits marked as reserved, but that doesn't >> mean they don't work. It just means the documentation is squirreled >> away in the secure TRM addendum. >> > Actually 2 things: > > a) patch seems to do the wrong thing for 4460 - 0x18 offset should > have been used instead of 0x14 which is correct for 4430? I see, thanks. I'll double check the TRMs. > b) yes, I understand, the current settings we did worked, but the > mode(0) we are setting to is real weird - we are setting it up for > clk0 out - I cant even think why it is even working in the first place > :( - is it because we are pumping out sysclkout and as a result we are > lucky that msecure is being sampled at the right point by twl6030 > allowing rtc access? either way, IMHO, the configuration is wrong. Ah, yes. Mode zero is definitely wrong. When I did the original patch for legacy mode, I just duplicated the settings u-boot was using. Guess it's a fluke that it works. Yet another thing wrong with my patch: the fref_clk0 pad is in the WKUP padconf section, and I put it at offset 0x14 in the CORE section, which is yet another wrong place. Let me respin this after some more doc reading. Thanks for the detailed review, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin Hilman <khilman@linaro.org> writes: > Nishanth Menon <nm@ti.com> writes: [...] >> Actually 2 things: >> >> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >> have been used instead of 0x14 which is correct for 4430? > > I see, thanks. I'll double check the TRMs. > >> b) yes, I understand, the current settings we did worked, but the >> mode(0) we are setting to is real weird - we are setting it up for >> clk0 out - I cant even think why it is even working in the first place >> :( - is it because we are pumping out sysclkout and as a result we are >> lucky that msecure is being sampled at the right point by twl6030 >> allowing rtc access? either way, IMHO, the configuration is wrong. > > Ah, yes. Mode zero is definitely wrong. When I did the original patch > for legacy mode, I just duplicated the settings u-boot was using. Guess > it's a fluke that it works. Actually, for legacy mode, it's set correctly in mode 2. This line: omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); does the right thing based on the signal name. But for DT boot, I defintely screwed it up by setting it to mode (and putting it in the wrong padconf section.) Also, are you *really* sure about the offset difference between 4430 and 4460 here? I don't have access to NDA docs anymore, so I cannot double check this. What I do know is that the legacy code is using 0x54 for both, and if I simply comment out that 'sys_drm_msecure' line above, RTC wake stops working (legacy boot) on both 4430 and 4460, so that seems like pretty stront evidence that it's the same offset on both. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote: > Kevin Hilman <khilman@linaro.org> writes: > >> Nishanth Menon <nm@ti.com> writes: > > [...] > >>> Actually 2 things: >>> >>> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >>> have been used instead of 0x14 which is correct for 4430? >> >> I see, thanks. I'll double check the TRMs. >> >>> b) yes, I understand, the current settings we did worked, but the >>> mode(0) we are setting to is real weird - we are setting it up for >>> clk0 out - I cant even think why it is even working in the first place >>> :( - is it because we are pumping out sysclkout and as a result we are >>> lucky that msecure is being sampled at the right point by twl6030 >>> allowing rtc access? either way, IMHO, the configuration is wrong. >> >> Ah, yes. Mode zero is definitely wrong. When I did the original patch >> for legacy mode, I just duplicated the settings u-boot was using. Guess >> it's a fluke that it works. > > Actually, for legacy mode, it's set correctly in mode 2. This line: > > omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); > > does the right thing based on the signal name. But for DT boot, I > defintely screwed it up by setting it to mode (and putting it in the > wrong padconf section.) > > Also, are you *really* sure about the offset difference between 4430 and > 4460 here? I don't have access to NDA docs anymore, so I cannot double > check this. > > What I do know is that the legacy code is using 0x54 for both, and if I > simply comment out that 'sys_drm_msecure' line above, RTC wake stops > working (legacy boot) on both 4430 and 4460, so that seems like pretty > stront evidence that it's the same offset on both. Schematics are public for PandaBoard ES and PandaBoard - as you can see from that the registers connected are definitely different. The control pad information should be present in public TRM as well - the "secure" angle was public, but in this case, it does not really matter. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nishanth Menon <nm@ti.com> writes: > On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote: >> Kevin Hilman <khilman@linaro.org> writes: >> >>> Nishanth Menon <nm@ti.com> writes: >> >> [...] >> >>>> Actually 2 things: >>>> >>>> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >>>> have been used instead of 0x14 which is correct for 4430? >>> >>> I see, thanks. I'll double check the TRMs. >>> >>>> b) yes, I understand, the current settings we did worked, but the >>>> mode(0) we are setting to is real weird - we are setting it up for >>>> clk0 out - I cant even think why it is even working in the first place >>>> :( - is it because we are pumping out sysclkout and as a result we are >>>> lucky that msecure is being sampled at the right point by twl6030 >>>> allowing rtc access? either way, IMHO, the configuration is wrong. >>> >>> Ah, yes. Mode zero is definitely wrong. When I did the original patch >>> for legacy mode, I just duplicated the settings u-boot was using. Guess >>> it's a fluke that it works. >> >> Actually, for legacy mode, it's set correctly in mode 2. This line: >> >> omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); >> >> does the right thing based on the signal name. But for DT boot, I >> defintely screwed it up by setting it to mode (and putting it in the >> wrong padconf section.) >> >> Also, are you *really* sure about the offset difference between 4430 and >> 4460 here? I don't have access to NDA docs anymore, so I cannot double >> check this. >> >> What I do know is that the legacy code is using 0x54 for both, and if I >> simply comment out that 'sys_drm_msecure' line above, RTC wake stops >> working (legacy boot) on both 4430 and 4460, so that seems like pretty >> stront evidence that it's the same offset on both. > Schematics are public for PandaBoard ES and PandaBoard - as you can > see from that the registers connected are definitely different. What I see from both schematics is that SYS_DRM_MSECURE is available on a few different pads, but on both 4430 and 4460, one of the places is in mode 2 of FREF_CLK0_OUT, which is at offset 0x54 on both SoCs. Based on that reading, and the fact that not correctly muxing that pad to mode 2 on *both* 4430 and 4460 makes the RTC work, I'm rather convinced that the offset should be the same for 4430 and 4460. What am I missing? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/28/2013 09:33 PM, Kevin Hilman wrote: > Nishanth Menon <nm@ti.com> writes: > >> On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> Kevin Hilman <khilman@linaro.org> writes: >>> >>>> Nishanth Menon <nm@ti.com> writes: >>> [...] >>> >>>>> Actually 2 things: >>>>> >>>>> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >>>>> have been used instead of 0x14 which is correct for 4430? >>>> I see, thanks. I'll double check the TRMs. >>>> >>>>> b) yes, I understand, the current settings we did worked, but the >>>>> mode(0) we are setting to is real weird - we are setting it up for >>>>> clk0 out - I cant even think why it is even working in the first place >>>>> :( - is it because we are pumping out sysclkout and as a result we are >>>>> lucky that msecure is being sampled at the right point by twl6030 >>>>> allowing rtc access? either way, IMHO, the configuration is wrong. >>>> Ah, yes. Mode zero is definitely wrong. When I did the original patch >>>> for legacy mode, I just duplicated the settings u-boot was using. Guess >>>> it's a fluke that it works. >>> Actually, for legacy mode, it's set correctly in mode 2. This line: >>> >>> omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); >>> >>> does the right thing based on the signal name. But for DT boot, I >>> defintely screwed it up by setting it to mode (and putting it in the >>> wrong padconf section.) >>> >>> Also, are you *really* sure about the offset difference between 4430 and >>> 4460 here? I don't have access to NDA docs anymore, so I cannot double >>> check this. >>> >>> What I do know is that the legacy code is using 0x54 for both, and if I >>> simply comment out that 'sys_drm_msecure' line above, RTC wake stops >>> working (legacy boot) on both 4430 and 4460, so that seems like pretty >>> stront evidence that it's the same offset on both. >> Schematics are public for PandaBoard ES and PandaBoard - as you can >> see from that the registers connected are definitely different. > What I see from both schematics is that SYS_DRM_MSECURE is available on > a few different pads, but on both 4430 and 4460, one of the places is in > mode 2 of FREF_CLK0_OUT, which is at offset 0x54 on both SoCs. > > Based on that reading, and the fact that not correctly muxing that pad > to mode 2 on *both* 4430 and 4460 makes the RTC work, I'm rather > convinced that the offset should be the same for 4430 and 4460. > > What am I missing? Hi Kevin, I've rechecked it too. According to: Panda ES: http://pandaboard.org/sites/default/files/board_reference/ES/750-2170-002-sch_revb.pdf Panda: http://pandaboard.org/sites/default/files/board_reference/pandaboard-a/panda-a-schematic.pdf AD2 (FREF_CLK0_OUT) is used for on both boards as H_SYS_DRM_MSEC - so, valid offset is 0x14 CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ lowest 16 bit FYI: in Android K3.0 and K3.4 this pin configured to "gpio_wk6" as following omap_mux_init_signal("fref_clk0_out.gpio_wk6", OMAP_PIN_OUTPUT); gpio_request(6, "msecure"); gpio_direction_output(6, 1); http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=262669aebf4af4044a25e8292f0e27986e18445a Regards, Grygorii > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Salut Kevin, On 5/28/2013 8:33 PM, Kevin Hilman wrote: > Nishanth Menon <nm@ti.com> writes: > >> On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> Kevin Hilman <khilman@linaro.org> writes: >>> >>>> Nishanth Menon <nm@ti.com> writes: >>> >>> [...] >>> >>>>> Actually 2 things: >>>>> >>>>> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >>>>> have been used instead of 0x14 which is correct for 4430? >>>> >>>> I see, thanks. I'll double check the TRMs. >>>> >>>>> b) yes, I understand, the current settings we did worked, but the >>>>> mode(0) we are setting to is real weird - we are setting it up for >>>>> clk0 out - I cant even think why it is even working in the first place >>>>> :( - is it because we are pumping out sysclkout and as a result we are >>>>> lucky that msecure is being sampled at the right point by twl6030 >>>>> allowing rtc access? either way, IMHO, the configuration is wrong. >>>> >>>> Ah, yes. Mode zero is definitely wrong. When I did the original patch >>>> for legacy mode, I just duplicated the settings u-boot was using. Guess >>>> it's a fluke that it works. >>> >>> Actually, for legacy mode, it's set correctly in mode 2. This line: >>> >>> omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); >>> >>> does the right thing based on the signal name. But for DT boot, I >>> defintely screwed it up by setting it to mode (and putting it in the >>> wrong padconf section.) >>> >>> Also, are you *really* sure about the offset difference between 4430 and >>> 4460 here? I don't have access to NDA docs anymore, so I cannot double >>> check this. >>> >>> What I do know is that the legacy code is using 0x54 for both, and if I >>> simply comment out that 'sys_drm_msecure' line above, RTC wake stops >>> working (legacy boot) on both 4430 and 4460, so that seems like pretty >>> stront evidence that it's the same offset on both. >> Schematics are public for PandaBoard ES and PandaBoard - as you can >> see from that the registers connected are definitely different. > > What I see from both schematics is that SYS_DRM_MSECURE is available on > a few different pads, but on both 4430 and 4460, one of the places is in > mode 2 of FREF_CLK0_OUT, which is at offset 0x54 on both SoCs. > > Based on that reading, and the fact that not correctly muxing that pad > to mode 2 on *both* 4430 and 4460 makes the RTC work, I'm rather > convinced that the offset should be the same for 4430 and 4460. > > What am I missing? I've just checked both specs and schematics and in the two cases the exact same ball (AD2) is connected to the exact same signal (mod2=sys_drm_msecure) and the registers offset inside the control_module are the same as well. Nishanth, AD4 ball in both cases is used for USBB1_PHY_REFCLK signal. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/24/2013 11:51 PM, Kevin Hilman wrote: > Nishanth Menon <nm@ti.com> writes: > >> On Fri, May 24, 2013 at 4:19 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> Nishanth Menon <nm@ti.com> writes: >>> >>>> On 15:09-20130524, Nishanth Menon wrote: >>>>> On 12:28-20130524, Kevin Hilman wrote: >>>>>> Earlier commits ensured proper muxing of pins related to proper >>>>>> TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure >>>>>> sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: >>>>>> OMAP4: TWL: mux sys_drm_msecure as output for PMIC). >>>>>> >>>>>> However these only fixed legacy boot and not DT boot. For DT boot, >>>>>> the default mux values need to be set properly in DT. >>>>>> >>>>>> Cc: Tony Lindgren <tony@atomide.com> >>>>>> Signed-off-by: Kevin Hilman <khilman@linaro.org> >>>>>> --- >>>>>> Applies on v3.10-rc2 >>>>>> >>>>>> arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ >>>>>> arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ >>>>>> 2 files changed, 16 insertions(+) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi >>>>>> index 03bd60d..a7a9bc0 100644 >>>>>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi >>>>>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi >>>>>> @@ -59,6 +59,7 @@ >>>>>> &omap4_pmx_core { >>>>>> pinctrl-names = "default"; >>>>>> pinctrl-0 = < >>>>>> + &twl6030_pins >>>>>> &twl6040_pins >>>>>> &mcpdm_pins >>>>>> &mcbsp1_pins >>>>>> @@ -66,6 +67,13 @@ >>>>>> &tpd12s015_pins >>>>>> >; >>>>>> >>>>>> + twl6030_pins: pinmux_twl6030_pins { >>>>>> + pinctrl-single,pins = < >>>>>> + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ >>>>> I can understand this - IRQ request comes here. >>>>> verified on OMAP4460 Panda-ES. >>>>> # omapconf read 0x4A10019C >>>>> 4118011B >>>>> >>>>>> + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ >>>>> I do not understand this. >>>>> OMAP4460 TRM: >>>>> Register: CONTROL_WKUP_PAD0_FREF_CLK0_OUT_PAD1_FREF_CLK3_REQ >>>>> omapconf read 0x4A31E054 >>>>> 010F010F >>>>> >>>>> I do not understand this configuration. mux modes for >>>>> FREF_CLK0_OUT_MUXMODE: >>>>> 0x0: Select fref_clk0_out >>>>> 0x1: Select fref_clk1_req >>>>> 0x2: Reserved >>>>> 0x3: Select gpio_wk6 >>>>> 0x5: Select sdmmc2_dat7 >>>>> 0x6: Select hw_dbg6 >>>>> 0x7: Select safe_mode >>>>> >>>>> Why are we setting mode 0(clk out) here? >>>> >>>> I did a bit more research into this: >>>> MSECURE line needs to be set for us to set anything with TWL6030 RTC. >>> >>> Yes, the commit referenced in the changelog described that in detail. >>> >>>> PandaBoard ES(4460) = this is on OMAP PIN AD4 >>>> PandaBoard (4430) = this is on OMAP PIN AD2 >>>> >>>> translating this back, >>>> PandaBoard ES OMAp4460 pin AD4: >>>> FREF_CLK3_OUT/FREF_CLK2_REQ/SYS_SECURE_INDICATOR/GPIO_WK31/C2C_WAKEREQOUT/SDMMC2_DAT5/ATTILA_HW_DBG8/SAFE_MODE >>>> This is at register 0x4A31E054(higher 16 bits) - however since we are GP device, >>>> SYS_SECURE_INDICATOR(mode 2) is reserved. >>>> PandaBoard OMAP4430 pin AD2: >>>> FREF_CLK0_OUT/FREF_CLK1_REQ/SYS_DRM_MSECURE/GPIO_WK6/SDMMC2_DAT7/ATTILA_HW_DBG6/SAFE_MOD >>>> This is at register 0x4A31E054(lower 16 bits) - however since we are GP device, >>>> SYS_DRM_MSECURE(mode 2) is reserved. >>>> >>>> To use RTC, we will have to use GPIO. >>>> on pandaboard ES, we need GPIO31 and PandaBoard, 6. >>>> >>>> Further the pinctrl offsets will vary as well between the same. >>>> >>>> IMHO, we need GPIO support and pinmux appropritate to the same to allow >>>> RTC to work. >>> >>> I don't follow at all what you're trying to say. The current settings >>> are working fine and have been tested on both 4430/Panda and 4460/Panda-ES. >>> >>> The goal of this patch is to make default mux settings for twl6030 for >>> DT boot match current legacy boot in mainline. >>> >>> The commits referenced in the changelog setup some default muxing for >>> twl6030 (see changelogs referenced and mux calls in >>> twl-common.c:omap4_pmic_init()) >>> >>> Without those mux settings, RTC wakeup on legacy boot does not work >>> (tested on 4430/panda, 4460/Panda with recent u-boot v2013.04 where most >>> of the old mux setup is gone.) With those settings, RTC wakeup works. >>> >>> Yes, the TRM has some mode bits marked as reserved, but that doesn't >>> mean they don't work. It just means the documentation is squirreled >>> away in the secure TRM addendum. >>> >> Actually 2 things: >> >> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >> have been used instead of 0x14 which is correct for 4430? > > I see, thanks. I'll double check the TRMs. > >> b) yes, I understand, the current settings we did worked, but the >> mode(0) we are setting to is real weird - we are setting it up for >> clk0 out - I cant even think why it is even working in the first place >> :( - is it because we are pumping out sysclkout and as a result we are >> lucky that msecure is being sampled at the right point by twl6030 >> allowing rtc access? either way, IMHO, the configuration is wrong. > > Ah, yes. Mode zero is definitely wrong. When I did the original patch > for legacy mode, I just duplicated the settings u-boot was using. Guess > it's a fluke that it works. > > Yet another thing wrong with my patch: the fref_clk0 pad is in the WKUP > padconf section, and I put it at offset 0x14 in the CORE section, which > is yet another wrong place. > > Let me respin this after some more doc reading. Did you re-spin it already? Beside that mode0 typo, it looks good to me. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Cousson, Benoit" <b-cousson@ti.com> writes: [...] >> >> Let me respin this after some more doc reading. > > Did you re-spin it already? Yes, v2 is here. http://marc.info/?l=linux-omap&m=136944147521955&w=2 It also needed a rework because the fref_clk0_out pin is also in the wkup section of the padconf, not core. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/29/2013 4:03 PM, Kevin Hilman wrote: > "Cousson, Benoit" <b-cousson@ti.com> writes: > > [...] > >>> >>> Let me respin this after some more doc reading. >> >> Did you re-spin it already? > > Yes, v2 is here. > > http://marc.info/?l=linux-omap&m=136944147521955&w=2 > > It also needed a rework because the fref_clk0_out pin is also in the > wkup section of the padconf, not core. OK, I'll wait for the v3 then :-) Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/29/2013 5:29 PM, Kevin Hilman wrote: > > On May 29, 2013 8:06 AM, "Cousson, Benoit" <b-cousson@ti.com > <mailto:b-cousson@ti.com>> wrote: > > > > On 5/29/2013 4:03 PM, Kevin Hilman wrote: > >> > >> "Cousson, Benoit" <b-cousson@ti.com <mailto:b-cousson@ti.com>> writes: > >> > >> [...] > >> > >>>> > >>>> Let me respin this after some more doc reading. > >>> > >>> > >>> Did you re-spin it already? > >> > >> > >> Yes, v2 is here. > >> > >> http://marc.info/?l=linux-omap&m=136944147521955&w=2 > >> > >> It also needed a rework because the fref_clk0_out pin is also in the > >> wkup section of the padconf, not core. > > > > > > OK, I'll wait for the v3 then :-) > > > > Hmm, why? v2 has the wkup changes included. Why? Because of my bad understanding of English :-) I understood: It also needs a rework... Sorry, I'll merge it. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Grygorii Strashko <grygorii.strashko@ti.com> writes: > On 05/28/2013 09:33 PM, Kevin Hilman wrote: >> Nishanth Menon <nm@ti.com> writes: >> >>> On Fri, May 24, 2013 at 5:15 PM, Kevin Hilman <khilman@linaro.org> wrote: >>>> Kevin Hilman <khilman@linaro.org> writes: >>>> >>>>> Nishanth Menon <nm@ti.com> writes: >>>> [...] >>>> >>>>>> Actually 2 things: >>>>>> >>>>>> a) patch seems to do the wrong thing for 4460 - 0x18 offset should >>>>>> have been used instead of 0x14 which is correct for 4430? >>>>> I see, thanks. I'll double check the TRMs. >>>>> >>>>>> b) yes, I understand, the current settings we did worked, but the >>>>>> mode(0) we are setting to is real weird - we are setting it up for >>>>>> clk0 out - I cant even think why it is even working in the first place >>>>>> :( - is it because we are pumping out sysclkout and as a result we are >>>>>> lucky that msecure is being sampled at the right point by twl6030 >>>>>> allowing rtc access? either way, IMHO, the configuration is wrong. >>>>> Ah, yes. Mode zero is definitely wrong. When I did the original patch >>>>> for legacy mode, I just duplicated the settings u-boot was using. Guess >>>>> it's a fluke that it works. >>>> Actually, for legacy mode, it's set correctly in mode 2. This line: >>>> >>>> omap_mux_init_signal("fref_clk0_out.sys_drm_msecure", OMAP_PIN_OUTPUT); >>>> >>>> does the right thing based on the signal name. But for DT boot, I >>>> defintely screwed it up by setting it to mode (and putting it in the >>>> wrong padconf section.) >>>> >>>> Also, are you *really* sure about the offset difference between 4430 and >>>> 4460 here? I don't have access to NDA docs anymore, so I cannot double >>>> check this. >>>> >>>> What I do know is that the legacy code is using 0x54 for both, and if I >>>> simply comment out that 'sys_drm_msecure' line above, RTC wake stops >>>> working (legacy boot) on both 4430 and 4460, so that seems like pretty >>>> stront evidence that it's the same offset on both. >>> Schematics are public for PandaBoard ES and PandaBoard - as you can >>> see from that the registers connected are definitely different. >> What I see from both schematics is that SYS_DRM_MSECURE is available on >> a few different pads, but on both 4430 and 4460, one of the places is in >> mode 2 of FREF_CLK0_OUT, which is at offset 0x54 on both SoCs. >> >> Based on that reading, and the fact that not correctly muxing that pad >> to mode 2 on *both* 4430 and 4460 makes the RTC work, I'm rather >> convinced that the offset should be the same for 4430 and 4460. >> >> What am I missing? > Hi Kevin, > > I've rechecked it too. Thanks for checking, I'll take this as an Acked-by. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Cousson, Benoit" <b-cousson@ti.com> writes: > On 5/29/2013 5:29 PM, Kevin Hilman wrote: >> >> On May 29, 2013 8:06 AM, "Cousson, Benoit" <b-cousson@ti.com >> <mailto:b-cousson@ti.com>> wrote: >> > >> > On 5/29/2013 4:03 PM, Kevin Hilman wrote: >> >> >> >> "Cousson, Benoit" <b-cousson@ti.com <mailto:b-cousson@ti.com>> writes: >> >> >> >> [...] >> >> >> >>>> >> >>>> Let me respin this after some more doc reading. >> >>> >> >>> >> >>> Did you re-spin it already? >> >> >> >> >> >> Yes, v2 is here. >> >> >> >> http://marc.info/?l=linux-omap&m=136944147521955&w=2 >> >> >> >> It also needed a rework because the fref_clk0_out pin is also in the >> >> wkup section of the padconf, not core. >> > >> > >> > OK, I'll wait for the v3 then :-) >> > >> >> Hmm, why? v2 has the wkup changes included. > > Why? Because of my bad understanding of English :-) > I understood: It also needs a rework... Re-reading, I wasn't terribly clear. Sorry for the confusion. > Sorry, I'll merge it. I was hoping for an Ack from Nishanth since he had some questions about it, but with the double checking from you and Grygorii, I think it should go in for the -rc cycle. (also, please add an Ack from Grygorii.) Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/29/2013 06:13 PM, Kevin Hilman wrote: > "Cousson, Benoit" <b-cousson@ti.com> writes: > >> On 5/29/2013 5:29 PM, Kevin Hilman wrote: >>> >>> On May 29, 2013 8:06 AM, "Cousson, Benoit" <b-cousson@ti.com >>> <mailto:b-cousson@ti.com>> wrote: >>> > >>> > On 5/29/2013 4:03 PM, Kevin Hilman wrote: >>> >> >>> >> "Cousson, Benoit" <b-cousson@ti.com <mailto:b-cousson@ti.com>> writes: >>> >> >>> >> [...] >>> >> >>> >>>> >>> >>>> Let me respin this after some more doc reading. >>> >>> >>> >>> >>> >>> Did you re-spin it already? >>> >> >>> >> >>> >> Yes, v2 is here. >>> >> >>> >> http://marc.info/?l=linux-omap&m=136944147521955&w=2 >>> >> >>> >> It also needed a rework because the fref_clk0_out pin is also in the >>> >> wkup section of the padconf, not core. >>> > >>> > >>> > OK, I'll wait for the v3 then :-) >>> > >>> >>> Hmm, why? v2 has the wkup changes included. >> >> Why? Because of my bad understanding of English :-) >> I understood: It also needs a rework... > > Re-reading, I wasn't terribly clear. Sorry for the confusion. > >> Sorry, I'll merge it. > > I was hoping for an Ack from Nishanth since he had some questions about > it, but with the double checking from you and Grygorii, I think it > should go in for the -rc cycle. (also, please add an Ack from Grygorii.) OK, I'll push the fix to Tony ASAP. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 03bd60d..a7a9bc0 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -59,6 +59,7 @@ &omap4_pmx_core { pinctrl-names = "default"; pinctrl-0 = < + &twl6030_pins &twl6040_pins &mcpdm_pins &mcbsp1_pins @@ -66,6 +67,13 @@ &tpd12s015_pins >; + twl6030_pins: pinmux_twl6030_pins { + pinctrl-single,pins = < + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ + >; + }; + twl6040_pins: pinmux_twl6040_pins { pinctrl-single,pins = < 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */ diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts index a35d9cd..5ad0c10 100644 --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -145,6 +145,7 @@ &omap4_pmx_core { pinctrl-names = "default"; pinctrl-0 = < + &twl6030_pins &twl6040_pins &mcpdm_pins &dmic_pins @@ -179,6 +180,13 @@ >; }; + twl6030_pins: pinmux_twl6030_pins { + pinctrl-single,pins = < + 0x15e 0x4118 /* sys_nirq1.sys_nirq1 OMAP_WAKEUP_EN | INPUT_PULLUP | MODE0 */ + 0x14 0x0 /* fref_clk0_out.sys_drm_msecure OUTPUT */ + >; + }; + twl6040_pins: pinmux_twl6040_pins { pinctrl-single,pins = < 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */
Earlier commits ensured proper muxing of pins related to proper TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC). However these only fixed legacy boot and not DT boot. For DT boot, the default mux values need to be set properly in DT. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Kevin Hilman <khilman@linaro.org> --- Applies on v3.10-rc2 arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++++++++ arch/arm/boot/dts/omap4-sdp.dts | 8 ++++++++ 2 files changed, 16 insertions(+)