ARM: DRA7: hwmod: add entry for RTCSS
Subsystems (5)
PATCH 1/1 ARM: DRA7: hwmod: add entry for RTCSS
From: Lokesh Vutla <[email protected]>
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.
---
Applies to linux-next of 5th May.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +41 -0
@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = { };/* +* 'rtcss' class +* +*/ +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = { + .sysc_offs =0x0078 , + .sysc_flags =SYSC_HAS_SIDLEMODE , + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +SIDLE_SMART_WKUP ), + .sysc_fields = &omap_hwmod_sysc_type3, +}; + +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = { + .name ="rtcss" , + .sysc = &dra7xx_rtcss_sysc, +}; + +/* rtcss */ +static struct omap_hwmod dra7xx_rtcss_hwmod = { + .name ="rtcss" , + .class = &dra7xx_rtcss_hwmod_class, + .clkdm_name ="rtc_clkdm" , + .main_clk ="sys_32k_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; + +/* * 'sata' class * */
@@ -2354,6 +2386,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per3 -> rtcss */ +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = { + .master = &dra7xx_l4_per3_hwmod, + .slave = &dra7xx_rtcss_hwmod, + .clk ="l4_root_clk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = { { .name ="sysc" ,
@@ -2683,6 +2723,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, &dra7xx_l3_main_1__qspi, + &dra7xx_l4_per3__rtcss, &dra7xx_l4_cfg__sata, &dra7xx_l4_cfg__smartreflex_core, &dra7xx_l4_cfg__smartreflex_mpu,
Signature · 1 line
1.7.10.1
Paul Walmsley
maintainerPATCH 1/1 ARM: DRA7: hwmod: add entry for RTCSS
Hi Sekhar,
Quoted 7 lines · Sekhar Nori
From: Lokesh Vutla <[email protected]>
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>
Sorry for the delay on this patch. Have been corresponding with TI to figure out what to do about DRA7xx/AM43xx patches. I don't have boards or public documentation for these devices, so it's impossible for me to meaningfully review the patches. Looks like boards and/or public docs won't be coming any time soon.
So for my part, here's what I'll need to merge any hwmod patches that involve AM437x or DRA7xx:
1. A Reviewed-by: from one of the following folks (which should come from a different person than who is submitting the patches):
Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren
2. A Tested-by: from one of the following folks (who can be the same as the person who is the same as the person who is submitting the patches):
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren
Once these are in place, I'd be happy to queue it for 3.16.
- Paul
Paul Walmsley
maintainerPATCH 1/1 ARM: DRA7: hwmod: add entry for RTCSS
Quoted 31 lines · Paul Walmsley
Quoted 7 lines · Sekhar Nori
From: Lokesh Vutla <[email protected]>
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Sorry for the delay on this patch. Have been corresponding with TI to figure out what to do about DRA7xx/AM43xx patches. I don't have boards or public documentation for these devices, so it's impossible for me to meaningfully review the patches. Looks like boards and/or public docs won't be coming any time soon.
So for my part, here's what I'll need to merge any hwmod patches that involve AM437x or DRA7xx:
1. A Reviewed-by: from one of the following folks (which should come from a different person than who is submitting the patches):
Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren2. A Tested-by: from one of the following folks (who can be the same as the person who is the same as the person who is submitting the patches):
Quoted 7 lines
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony LindgrenOnce these are in place, I'd be happy to queue it for 3.16.
I've tried to refine this a little bit. More details here:
http://marc.info/?l=linux-omap&m=140280321814330&w=2
- Paul
PATCH 1/1 ARM: DRA7: hwmod: add entry for RTCSS
In reply to Sekhar NoriQuoted 7 lines · Sekhar Nori
From: Lokesh Vutla <[email protected]>
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>
Quoted 2 lines
---
Applies to linux-next of 5th May.
Might need a repost with rebase on the latest mainline.
Quoted 71 lines
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)arch/arm/mach-omap2/omap_hwmod_7xx_data.c +41
-0@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = { };/* +* 'rtcss' class +* +*/ +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = { + .sysc_offs =0x0078 , + .sysc_flags =SYSC_HAS_SIDLEMODE , + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +SIDLE_SMART_WKUP ), + .sysc_fields = &omap_hwmod_sysc_type3, +}; + +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = { + .name ="rtcss" , + .sysc = &dra7xx_rtcss_sysc, +}; + +/* rtcss */ +static struct omap_hwmod dra7xx_rtcss_hwmod = { + .name ="rtcss" , + .class = &dra7xx_rtcss_hwmod_class, + .clkdm_name ="rtc_clkdm" , + .main_clk ="sys_32k_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; + +/* * 'sata' class * */ @@ -2354,6 +2386,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per3 -> rtcss */ +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = { + .master = &dra7xx_l4_per3_hwmod, + .slave = &dra7xx_rtcss_hwmod, + .clk ="l4_root_clk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = { { .name ="sysc" ,@@ -2683,6 +2723,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, &dra7xx_l3_main_1__qspi, + &dra7xx_l4_per3__rtcss, &dra7xx_l4_cfg__sata, &dra7xx_l4_cfg__smartreflex_core, &dra7xx_l4_cfg__smartreflex_mpu,
Paul Walmsley
maintainerPATCH 1/1 ARM: DRA7: hwmod: add entry for RTCSS
Quoted 9 lines · Rajendra Nayak
Quoted 7 lines · Sekhar Nori
From: Lokesh Vutla <[email protected]>
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>
Quoted 6 lines
Reviewed-by Rajendra Nayak <[email protected]>Quoted 2 lines
---
Applies to linux-next of 5th May.Might need a repost with rebase on the latest mainline.
Will queue this as soon as someone sends a Tested-by: & a boot log for it.
- Paul
v2 cover ARM: DRA7: Add RTC hwmod and dt entries
This series adds hwmod entry and dt node for RTC.
Tested on DRA7: logs can be seen here: http://hastebin.com/jaxogatuta.vhdl
Lokesh Vutla (2):
ARM: DRA7: hwmod: Add data for RTC
ARM: dts: DRA7: Add node for RTC
arch/arm/boot/dts/dra7-evm.dts | 1 + arch/arm/boot/dts/dra7.dtsi | 9 +++++++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++++++++++++++++++++++++++++ 3 files changed, 51 insertions(+)
Signature · 1 line
1.7.9.5
PATCH v2 1/2 ARM: DRA7: hwmod: Add data for RTC
Add hwmod data for RTC
---
Changes since V1:
Rebased on top of linux-next 20140708.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
arch/arm/mach-omap2/omap_hwmod_7xx_data.c +41 -0
@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = { };/* +* 'rtcss' class +* +*/ +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = { + .sysc_offs =0x0078 , + .sysc_flags =SYSC_HAS_SIDLEMODE , + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +SIDLE_SMART_WKUP ), + .sysc_fields = &omap_hwmod_sysc_type3, +}; + +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = { + .name ="rtcss" , + .sysc = &dra7xx_rtcss_sysc, +}; + +/* rtcss */ +static struct omap_hwmod dra7xx_rtcss_hwmod = { + .name ="rtcss" , + .class = &dra7xx_rtcss_hwmod_class, + .clkdm_name ="rtc_clkdm" , + .main_clk ="sys_32k_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; + +/* * 'sata' class * */
@@ -2344,6 +2376,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per3 -> rtcss */ +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = { + .master = &dra7xx_l4_per3_hwmod, + .slave = &dra7xx_rtcss_hwmod, + .clk ="l4_root_clk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = { { .name ="sysc" ,
@@ -2673,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, &dra7xx_l3_main_1__qspi, + &dra7xx_l4_per3__rtcss, &dra7xx_l4_cfg__sata, &dra7xx_l4_cfg__smartreflex_core, &dra7xx_l4_cfg__smartreflex_mpu,
Signature · 1 line
1.7.9.5
PATCH v2 1/2 ARM: DRA7: hwmod: Add data for RTC
Hi Paul,
Quoted 5 lines · Lokesh Vutla
Add hwmod data for RTC
Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Reviewed-by Rajendra Nayak <[email protected]>
Can you take this patch. I have submitted logs also.
Thanks and regards,
Lokesh
Quoted 74 lines
---
Changes since V1:
Rebased on top of linux-next 20140708.arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)arch/arm/mach-omap2/omap_hwmod_7xx_data.c +41
-0@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = { };/* +* 'rtcss' class +* +*/ +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = { + .sysc_offs =0x0078 , + .sysc_flags =SYSC_HAS_SIDLEMODE , + .idlemodes = (SIDLE_FORCE |SIDLE_NO |SIDLE_SMART | +SIDLE_SMART_WKUP ), + .sysc_fields = &omap_hwmod_sysc_type3, +}; + +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = { + .name ="rtcss" , + .sysc = &dra7xx_rtcss_sysc, +}; + +/* rtcss */ +static struct omap_hwmod dra7xx_rtcss_hwmod = { + .name ="rtcss" , + .class = &dra7xx_rtcss_hwmod_class, + .clkdm_name ="rtc_clkdm" , + .main_clk ="sys_32k_ck" , + .prcm = { + .omap4 = { + .clkctrl_offs =DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET , + .context_offs =DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET , + .modulemode =MODULEMODE_SWCTRL , + }, + }, +}; + +/* * 'sata' class * */ @@ -2344,6 +2376,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_per3 -> rtcss */ +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = { + .master = &dra7xx_l4_per3_hwmod, + .slave = &dra7xx_rtcss_hwmod, + .clk ="l4_root_clk_div" , + .user =OCP_USER_MPU |OCP_USER_SDMA , +}; +static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = { { .name ="sysc" ,@@ -2673,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { &dra7xx_l4_cfg__mpu, &dra7xx_l4_cfg__ocp2scp1, &dra7xx_l3_main_1__qspi, + &dra7xx_l4_per3__rtcss, &dra7xx_l4_cfg__sata, &dra7xx_l4_cfg__smartreflex_core, &dra7xx_l4_cfg__smartreflex_mpu,
Paul Walmsley
maintainerPATCH v2 1/2 ARM: DRA7: hwmod: Add data for RTC
Quoted 8 lines · Lokesh Vutla
Hi Paul,
Quoted 5 lines · Lokesh Vutla
Add hwmod data for RTC
Signed-off-by Lokesh Vutla <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Reviewed-by Rajendra Nayak <[email protected]>Can you take this patch. I have submitted logs also.
Thanks, queued for 3.17. And thanks for running rtctest in your testlog - that's helpful and gives some extra confidence.
- Paul
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
In reply to Lokesh VutlaAdd node for RTC.
And also making RTC regulator always-on, as RTC should be powered always.
---
This patch depends on the crossbar dt patch series by Sricharan:
https://www.mail-archive.com/linux-omap at vger.kernel.org/msg106910.html
arch/arm/boot/dts/dra7-evm.dts | 1 + arch/arm/boot/dts/dra7.dtsi | 9 +++++++++ 2 files changed, 10 insertions(+)
arch/arm/boot/dts/dra7-evm.dts +1 -0
@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; }; ldoln_reg: ldoln {
arch/arm/boot/dts/dra7.dtsi +9 -0
@@ -828,6 +828,15 @@ ti,hwmods = "sata"; }; + rtcss at 48838000 { + compatible = "ti,am3352-rtc"; + reg = <0x48838000 0x100>; + interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "rtcss"; + clocks = <&sys_32k_ck>; + }; + omap_control_usb2phy1: control-phy at 4a002300 { compatible = "ti,control-phy-usb2"; reg = <0x4a002300 0x4>;
Signature · 1 line
1.7.9.5
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 20 lines · Lokesh Vutla
Add node for RTC.
And also making RTC regulator always-on, as RTC should be powered always.Signed-off-by Lokesh Vutla <[email protected]>[nm at ti.com: update with rtc crossbar number]Signed-off-by Nishanth Menon <[email protected]>---
This patch depends on the crossbar dt patch series by Sricharan:
https://www.mail-archive.com/linux-omap at vger.kernel.org/msg106910.htmlarch/arm/boot/dts/dra7-evm.dts | 1 + arch/arm/boot/dts/dra7.dtsi | 9 +++++++++ 2 files changed, 10 insertions(+)arch/arm/boot/dts/dra7-evm.dts +0
-0
arch/arm/boot/dts/dra7-evm.dts line 254
Quoted 6 lines
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };
Is this regulator really always on?
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Hi Tony,
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Lokesh Vutla
Add node for RTC.
And also making RTC regulator always-on, as RTC should be powered always.Signed-off-by Lokesh Vutla <[email protected]>[nm at ti.com: update with rtc crossbar number]Signed-off-by Nishanth Menon <[email protected]>---
This patch depends on the crossbar dt patch series by Sricharan:
https://www.mail-archive.com/linux-omap at vger.kernel.org/msg106910.htmlarch/arm/boot/dts/dra7-evm.dts | 1 + arch/arm/boot/dts/dra7.dtsi | 9 +++++++++ 2 files changed, 10 insertions(+)
Quoted 12 lines
arch/arm/boot/dts/dra7-evm.dts line 254
Quoted 11 lines
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 4 lines
Regards,
Tony
Regards,
Keerthy
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 12 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
Also adding temporary dts entries just causes more churn on the dts files which is a PITA for everybody.
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 12 lines · Tony Lindgren
Quoted 11 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 5 lines
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.
I guess RTC also needs the supply to be on as long as we want the clock to be ticking.
Quoted 6 lines
Also adding temporary dts entries just causes more churn on the dts files which is a PITA for everybody.
Regards,
Tony
Regards,
Keerthy
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 15 lines · Keerthy
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 7 lines
Quoted 3 lines
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.
Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
Quoted 2 lines
I guess RTC also needs the supply to be on as long as we want the clock to be ticking.
Sure, but if somebody wants shut it off regulator-boot-on is better from driver point of view.
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Keerthy
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
Quoted 9 lines
Quoted 3 lines
I guess RTC also needs the supply to be on as long as we want the clock to be ticking.
Sure, but if somebody wants shut it off regulator-boot-on is better from driver point of view.
Regards,
Tony
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 23 lines · Keerthy
Quoted 22 lines · Tony Lindgren
Quoted 21 lines · Keerthy
Quoted 12 lines · Tony Lindgren
Quoted 11 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 5 lines
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.
Quoted 6 lines
Quoted 2 lines
Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 24 lines · Tony Lindgren
Quoted 23 lines · Keerthy
Quoted 22 lines · Tony Lindgren
Quoted 21 lines · Keerthy
Quoted 12 lines · Tony Lindgren
Quoted 11 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 5 lines
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
Okay.
Quoted 4 lines
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Hi Tony,
Quoted 25 lines · Keerthy
Quoted 24 lines · Tony Lindgren
Quoted 23 lines · Keerthy
Quoted 22 lines · Tony Lindgren
Quoted 21 lines · Keerthy
Quoted 12 lines · Tony Lindgren
Quoted 11 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 5 lines
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
Thanks and regards,
Lokesh
Quoted 8 lines
Okay.
Quoted 4 lines
Regards,
Tony
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 33 lines · Lokesh Vutla
Hi Tony,
Quoted 31 lines · Keerthy
Quoted 30 lines · Tony Lindgren
Quoted 29 lines · Keerthy
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Keerthy
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
Right, then you know you have the right regulator :)
Quoted 3 lines
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
Hmm but sounds like you already proved it can be idled? So the regulator really should be managed by the driver?
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 38 lines · Tony Lindgren
Quoted 29 lines · Lokesh Vutla
Hi Tony,
Quoted 27 lines · Keerthy
Quoted 26 lines · Tony Lindgren
Quoted 25 lines · Keerthy
Quoted 24 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 12 lines · Tony Lindgren
Quoted 11 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
Quoted 7 lines
Right, then you know you have the right regulator :)
Quoted 3 lines
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
Hmm but sounds like you already proved it can be idled? So the regulator really should be managed by the driver?
Tony,
Lokesh and i tried disabling the ldo9 regulator and then re-enabling it post boot via driver as well as through I2C tools. Once we disable and re-enable
we see that we can not access the RTC related registers any further. So we checked with the hardware team and they confirmed that it should never be disabled.
Regards,
Keerthy
Quoted 3 lines
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
In reply to Tony LindgrenHi Tony,
Quoted 34 lines · Tony Lindgren
Quoted 33 lines · Lokesh Vutla
Hi Tony,
Quoted 31 lines · Keerthy
Quoted 30 lines · Tony Lindgren
Quoted 29 lines · Keerthy
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Keerthy
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
Right, then you know you have the right regulator :)
Once we switch it off it is expected, but then if it is *switched on* it is expected that we should be able to access registers. Here there is an abort accessing these registers.
Quoted 7 lines
Quoted 4 lines
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
Hmm but sounds like you already proved it can be idled? So the regulator really should be managed by the driver?
Actually I adapted the driver to support a power regulator. Then I observed that if rtc is loaded as a module there is an abort( which is happening because the regulator is disabled once and re-enabled). So when we checked with the hardware team, they confirmed that ldo9 should not be disabled.
Thanks and regards,
Lokesh
Quoted 5 lines
Regards,
Tony
Tony Lindgren
maintainerPATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
Quoted 11 lines · Lokesh Vutla
Quoted 6 lines · Tony Lindgren
Quoted 3 lines · Lokesh Vutla
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
Right, then you know you have the right regulator :)
Once we switch it off it is expected, but then if it is *switched on* it is expected that we should be able to access registers. Here there is an abort accessing these registers.
Most likely you need to also reconfigure the registers or re-enable the clock or reset it at the interconnect too.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
Quoted 8 lines
Quoted 2 lines
Hmm but sounds like you already proved it can be idled? So the regulator really should be managed by the driver?
Actually I adapted the driver to support a power regulator. Then I observed that if rtc is loaded as a module there is an abort( which is happening because the regulator is disabled once and re-enabled). So when we checked with the hardware team, they confirmed that ldo9 should not be disabled.
Hmm so how is it enabled initially then?
To me it sounds like very standard stuff to reinitialize a driver for any omap device when waking from suspend or returning from off-idle. If the RTC device cannot be reset, idled and re-initialized properly, there's something wrong with the RTC driver, clocks, regulators, or hwmod data for that device.
Regards,
Tony
PATCH v2 2/2 ARM: dts: DRA7: Add node for RTC
In reply to Lokesh VutlaQuoted 33 lines · Lokesh Vutla
Hi Tony,
Quoted 31 lines · Keerthy
Quoted 30 lines · Tony Lindgren
Quoted 29 lines · Keerthy
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Keerthy
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Keerthy
Quoted 10 lines · Tony Lindgren
arch/arm/boot/dts/dra7-evm.dts line 253
Quoted 8 lines · Lokesh Vutla
arch/arm/boot/dts/dra7-evm.dts +1
-0@@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; };Is this regulator really always on?
This feeds on to RTC which is a free running clock. So i guess always on is justified no?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Well the dts entries should describe the hardware. If the regulator can be enabled and disabled, we should not claim it's always on.
From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need to be always on. For Ex: SMPS123 which feeds on to the MPU.Right, and we already have regulator-boot-on for those. Or are you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on. It does not guarantee that it will be on for the rest of the time. The regulator framework can go ahead and disable it if no one has requested for it. In case of RTC we do not want that to happen.
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
That's a bug in the RTC driver then. The driver should request a regulator if it's specified.
In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while accessing RTC registers.
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when SoC is active and expected to be always on.
As confirmed by the PMIC hardware team this regulator should be an always-on regulator.
Quoted 9 lines
Thanks and regards,
LokeshQuoted 5 lines
Okay.
Quoted 3 lines
Regards,
Tony