summaryrefslogtreecommitdiffstats
path: root/drivers/i2c/muxes
diff options
context:
space:
mode:
authorDaniel Kurtz <djkurtz@chromium.org>2012-11-15 17:43:30 +0530
committerWolfram Sang <w.sang@pengutronix.de>2012-11-16 13:08:48 +0100
commit9bcd04bfbbd5599de011176b846ed00ac15a234c (patch)
treecdf492904dc6b6a457f01d0e268cb55a3cba2002 /drivers/i2c/muxes
parent2693ac69880a33d4d9df6f128415b65e745f00ba (diff)
downloadop-kernel-dev-9bcd04bfbbd5599de011176b846ed00ac15a234c.zip
op-kernel-dev-9bcd04bfbbd5599de011176b846ed00ac15a234c.tar.gz
i2c: s3c2410: grab adapter lock while changing i2c clock
We probably don't want to change I2C frequency while a transfer is in progress. The current implementation grabs a spinlock, but that only protected the writes to IICCON when starting a message, it didn't protect against clock changes in the middle of a transaction. Note: The i2c-core already grabs the adapter lock before calling s3c24xx_i2c_doxfer(), which ensures that only one caller is issuing a xfer at a time. This means it is not necessary to disable interrupts (spin_lock_irqsave) when changing frequencies, since there won't be any i2c interrupts if there is no on-going xfer. Lastly, i2c_lock_adapter() may cause the cpufreq_transition to sleep if if a xfer is in progress, but this is ok since cpufreq notifiers are called in a kernel thread, and there are already cases where it could sleep, such as when using i2c to update the output of a voltage regulator. Note: the cpufreq part of this change has no functional affect on exynos, where the i2c clock is independent of the cpufreq. But, there is a slight perfomance boost since we no longer need to lock/unlock an additional spinlock. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Diffstat (limited to 'drivers/i2c/muxes')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud