On 06/08/2015 at 07:39:52 +0530, Keerthy wrote : > On Wednesday 05 August 2015 06:05 PM, Alexandre Belloni wrote: > >On 05/08/2015 at 17:31:22 +0530, Keerthy wrote : > >>This is a special one where in the enable bit is present in the rtc register > >>space and not in the prcm register space. Since there was a concern on the > >>external clock not being present i added a board dts flag. > >> > > > >So you mean this external clock is coming internally from the SoC? > > No what i meant is external clock is coming from Oscillator OSC1 @32.768KHz > but the controlling bits are part of rtc register space. > > TRM: http://www.ti.com/lit/ug/spruhl7c/spruhl7c.pdf > > Section: 19.4.3.2 Clock Source Page 2836 > > Also register details: > 19.4.5.19 RTCSS_OSC_REG Register (offset = 54h) [reset = 10h] > > Page 2865. > This confirms what I'm saying. Your issue here is that the driver is not properly taking the clocks so when the PRCM is disabling CLK_32KHZ, you end up without any clock. You can use the clocks property in the device tree and pass two clocks, the prcm one and the external crystal/external oscillator. In the driver, you get both clock, clk_get_rate on the external one will help you know whether it is populated or not (this will be 0 or 32768). It is is populated, use it by writing 32KCLK_SEL. Bonus points if you use the clock-accuracy and decide to switch between PRCM and the external clock when going to suspend and resuming. I guess an external RC oscillator is quite bad versus the PRCM. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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
