Hi Julian, hi Chen-Yu, >>> On Thu, Jul 28, 2016 at 12:58 AM, Onno Kortmann <[email protected]> wrote: >>>> This adds a sysfs 'clock_source' attribute which can be used to query >>>> and set the clock source of the RTC, either 'internal' or 'external'. >>> >>> Shouldn't this also be a devicetree attribute so we can set this for >>> boards we know have crystals?
This sounds like a very good idea, now I only need to figure out how to implement the devicetree stuff. :D Do you think it makes sense to still have it accessible through sysfs? (I think it is great for debugging and also maybe user-space testing for presence of an external crystal) >>> >>> (Also, is there equivalent functionality for sun6i-rtc?) >> >> Yes there is. I'm more interested in whether boards without crystals >> exist. I looked into the the 'Allwinner A31 user manual' and I found that it is also bit 0 for selecting the external/internal clock source option of the RTC. However, the upper bits 16..31 of LOSC_CTRL_REG are undefined for A31. For A20, you have to write a special key value to those bits to actually switch the oscillator source. Is it safe to assume that they are 'don't care' on A31 (marked as '/'), or should the write logic be adapted for A31 to not touch those bits? As far as I know, I do not own any A31 hardware. There are also other options for the A20. There is some kind of 'auto switch' functionality and those bits can be set and read back. (CLK32K_AUTO_SWT_EN and CLK32K_AUTO_SWT_PEND). Those are in a different register for A31, as far as I can see (LOSC AUTO switch status register). However, to be honest, I have not figured what those bits really do and I wasn't able to trigger automatic switching to the proper external clock with those registers. Assuming they auto switch the clock source to external if available was the first avenue I tried. Furthermore, on the A20, there is another setting: EXT_LOSC_GSM. I think I figured out what this does. It appears to be the ext 32kHz oscillator's gain strength. (so GS == gain strength, M == ? Modifier?) With a scope, I saw the waveform changing to a more rectangular shape when I increased those bits from 0 to 3. My Cubietruck seems to run just fine with the lowest setting. Would adding another devicetree and sysfs attribute for this setting be a good idea? > > Good point, maybe the attribute should indicate that there's no > crystal and have the default be to assume there is one. > > Alternatively, is it possible to detect whether there's a crystal or not? >From the A20 user manual (the only docs I have), I cannot find any indication bit or similar that would tell me 'ext crystal is connected'. The only chance I see is to try switching to external and see whether the clock is wildly off or maybe even not running anymore. I don't think it would make sense to do this in kernel space, especially not during boot up (delays!). I think the better way is to instead have a simple script that's looking at adjtimex values in user space, for the internal vs. external setting through sysfs. Maybe there will also be combinations of temperature and chip manufacturing variations where selecting the EXT OSC will create a signal that is very close to a proper RTC, so such a script would always have at least a small bit of uncertainty in its result. Except for debugging the RTC logic, I even do not see the value of having just an internal R/C oscillator for a RTC. Cheers, Onno -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
