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 -- 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
