| Message ID | 1404894932-26677-3-git-send-email-lokeshvutla@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: > Add node for RTC. > And also making RTC regulator always-on, as RTC should be powered > always. > > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> > [nm@ti.com: update with rtc crossbar number] > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > This patch depends on the crossbar dt patch series by Sricharan: > https://www.mail-archive.com/linux-omap@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(+) > > diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts > index 4adc280..bca6d4a 100644 > --- a/arch/arm/boot/dts/dra7-evm.dts > +++ b/arch/arm/boot/dts/dra7-evm.dts > @@ -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 -- 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
Hi Tony, On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: > * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >> Add node for RTC. >> And also making RTC regulator always-on, as RTC should be powered >> always. >> >> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> >> [nm@ti.com: update with rtc crossbar number] >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> This patch depends on the crossbar dt patch series by Sricharan: >> https://www.mail-archive.com/linux-omap@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(+) >> >> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts >> index 4adc280..bca6d4a 100644 >> --- a/arch/arm/boot/dts/dra7-evm.dts >> +++ b/arch/arm/boot/dts/dra7-evm.dts >> @@ -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? > > Regards, > > Tony Regards, Keerthy -- 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
* Keerthy <a0393675@ti.com> [140709 02:36]: > On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: > >* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: > >>--- a/arch/arm/boot/dts/dra7-evm.dts > >>+++ b/arch/arm/boot/dts/dra7-evm.dts > >>@@ -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? 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 -- 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 Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: > * Keerthy <a0393675@ti.com> [140709 02:36]: >> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>> @@ -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? > 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. > Also adding temporary dts entries just causes more churn on the > dts files which is a PITA for everybody. > > Regards, > > Tony Regards, Keerthy -- 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
* Keerthy <a0393675@ti.com> [140709 03:39]: > On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: > >* Keerthy <a0393675@ti.com> [140709 02:36]: > >>On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: > >>>* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: > >>>>--- a/arch/arm/boot/dts/dra7-evm.dts > >>>>+++ b/arch/arm/boot/dts/dra7-evm.dts > >>>>@@ -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? > >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? > 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 -- 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 Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: > * Keerthy <a0393675@ti.com> [140709 03:39]: >> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>> @@ -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? >>> 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. > >> 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 -- 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
* Keerthy <a0393675@ti.com> [140709 03:59]: > On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: > >* Keerthy <a0393675@ti.com> [140709 03:39]: > >>On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: > >>>* Keerthy <a0393675@ti.com> [140709 02:36]: > >>>>On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: > >>>>>* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: > >>>>>>--- a/arch/arm/boot/dts/dra7-evm.dts > >>>>>>+++ b/arch/arm/boot/dts/dra7-evm.dts > >>>>>>@@ -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? > >>>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. That's a bug in the RTC driver then. The driver should request a regulator if it's specified. Regards, Tony -- 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 Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: > * Keerthy <a0393675@ti.com> [140709 03:59]: >> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>> * Keerthy <a0393675@ti.com> [140709 03:39]: >>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>>>> @@ -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? >>>>> 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. > That's a bug in the RTC driver then. The driver should request a > regulator if it's specified. Okay. > > Regards, > > Tony -- 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
Hi Tony, On Wednesday 09 July 2014 04:36 PM, Keerthy wrote: > On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: >> * Keerthy <a0393675@ti.com> [140709 03:59]: >>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>>> * Keerthy <a0393675@ti.com> [140709 03:39]: >>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>> @@ -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? >>>>>> 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. >> 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 > > Okay. > >> >> Regards, >> >> Tony > -- 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
* Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]: > Hi Tony, > On Wednesday 09 July 2014 04:36 PM, Keerthy wrote: > > On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: > >> * Keerthy <a0393675@ti.com> [140709 03:59]: > >>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: > >>>> * Keerthy <a0393675@ti.com> [140709 03:39]: > >>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: > >>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: > >>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: > >>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: > >>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts > >>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts > >>>>>>>>> @@ -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? > >>>>>> 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. > >> 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 :) > 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 -- 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 Monday 14 July 2014 08:15 PM, Lokesh Vutla wrote: > Hi Tony, > On Wednesday 09 July 2014 04:36 PM, Keerthy wrote: >> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: >>> * Keerthy <a0393675@ti.com> [140709 03:59]: >>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>>>> * Keerthy <a0393675@ti.com> [140709 03:39]: >>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>> @@ -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? >>>>>>> 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. >>> 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. Acked-by: Keerthy <j-keerthy@ti.com> > > Thanks and regards, > Lokesh > >> Okay. >> >>> Regards, >>> >>> Tony -- 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 Monday 14 July 2014 09:53 PM, Tony Lindgren wrote: > * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]: >> Hi Tony, >> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote: >>> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: >>>> * Keerthy <a0393675@ti.com> [140709 03:59]: >>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>>>>> * Keerthy <a0393675@ti.com> [140709 03:39]: >>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>>> @@ -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? >>>>>>>> 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. >>>> 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 :) > >> 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 > Regards, > > Tony -- 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
Hi Tony, On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote: > * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]: >> Hi Tony, >> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote: >>> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote: >>>> * Keerthy <a0393675@ti.com> [140709 03:59]: >>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>>>>> * Keerthy <a0393675@ti.com> [140709 03:39]: >>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]: >>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]: >>>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts >>>>>>>>>>> @@ -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? >>>>>>>> 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. >>>> 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. > >> 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 > > Regards, > > Tony > -- 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
* Lokesh Vutla <lokeshvutla@ti.com> [140714 21:09]: > On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote: > > * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]: > >> > >> 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. > >> 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. 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 -- 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/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..bca6d4a 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -249,6 +249,7 @@ regulator-min-microvolt = <1050000>; regulator-max-microvolt = <1050000>; regulator-boot-on; + regulator-always-on; }; ldoln_reg: ldoln { diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 55a6cd4..46779197 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -828,6 +828,15 @@ ti,hwmods = "sata"; }; + rtcss@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@4a002300 { compatible = "ti,control-phy-usb2"; reg = <0x4a002300 0x4>;