aboutsummaryrefslogtreecommitdiff
path: root/mm/fadvise.c
diff options
context:
space:
mode:
authorFrank Shew <fshew@geometrics.com>2009-05-19 07:23:49 -0400
committerBen Dooks <ben-linux@fluff.org>2009-06-13 10:39:25 +0100
commit94327d009e3aa20214e9dfa486a1fd14445fe736 (patch)
treebb34db58161a22f60c73bcea08fefbde1db6b5a9 /mm/fadvise.c
parent57a8f32eafa6f36ea3a128e8b13f353c5a3ca9b2 (diff)
i2c: Blackfin TWI: fix transfer errors with repeat start
We have a custom BF537 board with an I2C RTC (MAX DS3231) running uclinux 2007R1 for some time. Recently during migration to 2008R1.5-RC3 we losted access to the RTC. The RTC driver calls 'i2c_transfer()' which in turns calls 'bfin_twi_master_xfer()' in i2c-bfin-twi.c. Compared with 2007R1, it looks like the 2008R1.5 version of i2c-bin-twi.c has a new mode 'TWI_I2C-MODE_REPEAT' which corresponds to the Repeat Start Condition described in the HRM. However, according to the HRM, at XMIT or RECV interrupt and when the data count is 0, not only is the RESTART bit supposed to be set, but MDIR must also be set if the next operation is a receive sequence, and cleared if not. Currently there is no code that looks at the I2C_M_RD bit in the flag from the next cur_msg and set/clear the MDIR flag accordingly at the same time that the RSTART bit is set. Instead, MDIR is set or cleared (by OR'ing with 0?) after the RESTART bit has been cleared during handling of MCOMP interrupt. It appears that this is causing our failure with reading the RTC, as a quick patch to set/clear MDIR when RESTART is set seem to solve our problem. Signed-off-by: Frank Shew <fshew@geometrics.com> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Bryan Wu <cooloney@kernel.org> [ben-linux@fluff.org: shorted subject] Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Diffstat (limited to 'mm/fadvise.c')
0 files changed, 0 insertions, 0 deletions