aboutsummaryrefslogtreecommitdiff
path: root/drivers/media/platform/s5p-mfc/s5p_mfc.c
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <m.chehab@samsung.com>2013-12-13 10:35:03 -0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2014-02-13 13:48:02 -0800
commit549ac1ac8cf1e7c696501ed8e53956f6c64b217e (patch)
tree298b9df3a50701f03510ec9a6d0b1a3e710fd203 /drivers/media/platform/s5p-mfc/s5p_mfc.c
parent8bed1b8f616b58441801d0f0fb277099b467c055 (diff)
downloadlinaro-lsk-549ac1ac8cf1e7c696501ed8e53956f6c64b217e.tar.gz
dib8000: make 32 bits read atomic
commit 5ac64ba12aca3bef18e61c866583155a3bbf81c4 upstream. As the dvb-frontend kthread can be called anytime, it can race with some get status ioctl. So, it seems better to avoid one to race with the other while reading a 32 bits register. I can't see any other reason for having a mutex there at I2C, except to provide such kind of protection, as the I2C core already has a mutex to protect I2C transfers. Note: instead of this approach, it could eventually remove the dib8000 specific mutex for it, and either group the 4 ops into one xfer or to manually control the I2C mutex. The main advantage of the current approach is that the changes are smaller and more puntual. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/media/platform/s5p-mfc/s5p_mfc.c')
0 files changed, 0 insertions, 0 deletions