> Update the rtc-rs5c372 driver:
> I suspect the
> issue wasn't that "mode 1" didn't work on that board; the original
> code to fetch the trim was broken. If "mode 1" really won't work,
> that's almost certainly a bug in that board's I2C driver.
It was not related to trim fetching. Yes, it very likely that the boards
i2c controller (i2c-iop3xx) is has a bug, but I'm not competent enough to
find out what it is actually sending out to the wire.
With your patch, the rtc acts like the chip would completely ignore the
"address" transfer, and starts reading from the last (default) register
anyway. Thus all the regs look shifted by one in the driver. With current
git driver results look like:
# cat /proc/driver/rtc ; sleep 1 ; echo one sec gone; cat /proc/driver/rtc
rtc_time : 06:16:55
rtc_date : 2006-12-11
24hr : yes
32.768 KHz
trim : 1
one sec gone
rtc_time : 06:16:56
rtc_date : 2006-12-11
24hr : yes
32.768 KHz
trim : 1
And same after your patch:
rtc_time : 16:23:28
rtc_date : 2012-11-01
alrm_time : **:01:00
alrm_date : ****-**-**
alrm_wakeup : no
alrm_pending : no
24hr : yes
crystal : 32.768 KHz
trim : 10
one sec gone
rtc_time : 16:24:28
rtc_date : 2012-11-01
alrm_time : **:01:00
alrm_date : ****-**-**
alrm_wakeup : no
alrm_pending : no
24hr : yes
crystal : 32.768 KHz
trim : 10
> + /* this implements the first (most portable) reading method
> + * specified in the datasheet.
> */
Why is this method considered more portable? Howabout making the read
method a module parameter?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]