Re: [PATCH V2 2/2] ARM: dts: DRA7: Add node for RTC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux