Bug 223642
| Summary: | ds3231 iic driver can't initialise a new device | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Brian Scott <bscott> | ||||
| Component: | arm | Assignee: | Ian Lepore <ian> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | dvwerks, ian | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | 11.1-STABLE | ||||||
| Hardware: | arm | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
I have a ds3231 here, so I'll take this PR and test/commit it, but it may take a few days to get to. I have 3 of these ds3231 on various Arm boards and had the same exact problem. This patch works for me on RPi2. Here is a link to my device for reference: http://hobbycomponents.com/accessories/737-ds3231-rtc-module-for-raspberry-pi A commit references this bug: Author: ian Date: Sun Dec 10 18:55:42 UTC 2017 New revision: 326750 URL: https://svnweb.freebsd.org/changeset/base/326750 Log: Do not give up if writing to the chip's control and status registers fails during startup. When a brand new chip leaves the factory, it is in a special power-saving mode that disables most functions on the chip to save battery power. The chip is stuck in this mode until the first write to the time registers, which automatically clears the special power-saving mode and starts the oscillator. Also, the day-of-week register in this chip counts 1-7, not 0-6, so write the values accordingly. These changes are based on the patch submitted by Brian Scott, but I elimated warnings since this condition is expected, and added some comments, and so in general blame me for any mistakes. PR: 223642 Changes: head/sys/dev/iicbus/ds3231.c Sorry for the slow repsonse on this, finally got it committed. I'll MFC to 11 in a few days. A commit references this bug: Author: ian Date: Sat Jan 6 23:04:14 UTC 2018 New revision: 327653 URL: https://svnweb.freebsd.org/changeset/base/327653 Log: MFC r326750: Do not give up if writing to the chip's control and status registers fails during startup. When a brand new chip leaves the factory, it is in a special power-saving mode that disables most functions on the chip to save battery power. The chip is stuck in this mode until the first write to the time registers, which automatically clears the special power-saving mode and starts the oscillator. Also, the day-of-week register in this chip counts 1-7, not 0-6, so write the values accordingly. These changes are based on the patch submitted by Brian Scott, but I elimated warnings since this condition is expected, and added some comments, and so in general blame me for any mistakes. PR: 223642 Changes: _U stable/11/ stable/11/sys/dev/iicbus/ds3231.c |
Created attachment 187954 [details] Patch to change failures to start the oscillator and acknowledge interrupts to be warnings During initialisation of the ds3231 rtc driver it attempts to enable the oscillator and acknowledge any alarm conditions. For a brand new, never powered device this is rejected until the time has been set, however because these calls fail the device isn't started and the time is never set. Writing a quick and dirty program based on the i2c utility I have initialised the device without using the driver. When loaded, the driver proceeds normally and uses the device as intended. I have patched the driver (sys/dev/iicbus/ds3231.c) to just warn on failures of the two calls mentioned earlier. I haven't found any way to return one of the chips back to pristine condition. Fortunately I had another device that I had purchased but never used that I could use to test the change with and had the device accepted properly (with a few extra warning messages on first boot). It's quite possible that other suppliers actually test these devices before selling them and that normally they have some time setting when first installed. Mine where $2 each from Malaysia with free shipping so I couldn't really expect much. I don't know if other people would experience the same problem. While debugging this, I have also noticed that the device is initialised with a zero based day of week (i.e. 0-6) but the specification for the device is for a value from 1 to 7. The value returned by the device is never used so this shouldn't matter unless some version of the chip in the future enforces the specification for some reason.