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