Hi Tony, On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote: > * Lokesh Vutla <lokeshvutla@xxxxxx> [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@xxxxxx> [140709 03:59]: >>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote: >>>>>> * Keerthy <a0393675@xxxxxx> [140709 03:39]: >>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote: >>>>>>>> * Keerthy <a0393675@xxxxxx> [140709 02:36]: >>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote: >>>>>>>>>> * Lokesh Vutla <lokeshvutla@xxxxxx> [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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
