Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon <nm@ti.com>]

On 01/14/2016 04:01 AM, Keerthy wrote:
> 
> 
> On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote:
>> On 01/13/2016 01:40 PM, Tony Lindgren wrote:
>>
>>> Anyways, considering what's been discussed, after the minimal RTC fix
>>> we could also add code to allow the TWL driver optionally configure the
>>> GPIO. This way the TWL driver could also check the GPIO state in case
>>> some out-of-our-control mystery software goes tweak the msecure pin
>>> state.
>>
>> I dont even know how that will work:
>> If you are using MSECURE as it is intended to be, then you'd mux it to
>> msecure, which means that GPIO read is just a waste of time - you dont
>> even mux it to external world. Now, some SoCs like DRA7 has input lines
>> always connected. even assuming this is for such a case:
>> a) when you are running linux, you are already in nonsecure - it needs
>> no read of MSECURE GPIO to figure that out.
>> b)  when you are in secure world, Linux wont be running either.
>>
>> Reading from GPIO is just misguided in my opinion. firewalls are not
>> reconfigured, and muxes are usually done a single time.
>>
>>   Or the RTC driver could just check that the bits really change
>>> after= writing them. Then we would at least know things are not working
>>> right for the TWL related RTC drivers.
>>
>> that is reasonable to check, but just a overhead - anyways, just
>> isolated to palmas-rtc.. fail reason maynot always be issues with
>> MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah -
>> that might give a hint that there is an issue..
>>
> 
> IIRC without configuring the mux mode of gpio234 to msecure mode we were 
> unable to write to the rtc registers. Hence configured it one time at boot.
> 
Looks like you missed the code section that shows that the u-boot
configuration was overridden by kernel as GPIO for the very same reason.!

http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

-- 
Regards,
Nishanth Menon