On Wed, 28 Jul 2021 15:43:54 +0200, Vitaly Rodionov wrote:
From: Lucas Tanure tanureal@opensource.cirrus.com
Only disable I2C clock 25 ms after not being used.
The current implementation enables and disables the I2C clock for each I2C transaction. Each enable/disable call requires two verb transactions. This means each I2C transaction requires a total of four verb transactions to enable and disable the clock. However, if there are multiple consecutive I2C transactions, it is not necessary to enable and disable the clock each time, instead it is more efficient to enable the clock for the first transaction, and disable it after the final transaction, which would improve performance. This is achieved by using a timeout which disables the clock if no request to enable the clock has occurred for 25 ms.
Signed-off-by: Lucas Tanure tanureal@opensource.cirrus.com Signed-off-by: Vitaly Rodionov vitalyr@opensource.cirrus.com Signed-off-by: Stefan Binding sbinding@opensource.cirrus.com
Changes in v2: Improved delayed work start/cancel implementation, and re-worked commit message adding more explanation why this was required.
sound/pci/hda/patch_cs8409.c | 56 +++++++++++++++++++++++++----------- sound/pci/hda/patch_cs8409.h | 4 +++ 2 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/sound/pci/hda/patch_cs8409.c b/sound/pci/hda/patch_cs8409.c index 08205c19698c..fafc0f309e70 100644 --- a/sound/pci/hda/patch_cs8409.c +++ b/sound/pci/hda/patch_cs8409.c @@ -53,7 +53,9 @@ static struct cs8409_spec *cs8409_alloc_spec(struct hda_codec *codec) if (!spec) return NULL; codec->spec = spec;
spec->codec = codec; codec->power_save_node = 1;
INIT_DELAYED_WORK(&spec->i2c_clk_work, cs8409_disable_i2c_clock); snd_hda_gen_spec_init(&spec->gen);
return spec;
@@ -72,21 +74,37 @@ static inline void cs8409_vendor_coef_set(struct hda_codec *codec, unsigned int snd_hda_codec_write(codec, CS8409_PIN_VENDOR_WIDGET, 0, AC_VERB_SET_PROC_COEF, coef); }
-/** +/*
- cs8409_disable_i2c_clock - Worker that disable the I2C Clock after 25ms without use
- */
+static void cs8409_disable_i2c_clock(struct work_struct *work) +{
- struct cs8409_spec *spec = container_of(work, struct cs8409_spec, i2c_clk_work.work);
- mutex_lock(&spec->cs8409_i2c_mux);
- cs8409_vendor_coef_set(spec->codec, 0x0,
cs8409_vendor_coef_get(spec->codec, 0x0) & 0xfffffff7);- spec->i2c_clck_enabled = 0;
- mutex_unlock(&spec->cs8409_i2c_mux);
Here we have a lock in the work, and this would become a problem in the below...
+}
+/*
- cs8409_enable_i2c_clock - Enable I2C clocks
- @codec: the codec instance
- @enable: Enable or disable I2C clocks
- Enable or Disable I2C clocks.
*/
- This must be called when the i2c mutex is locked.
-static void cs8409_enable_i2c_clock(struct hda_codec *codec, unsigned int enable) +static void cs8409_enable_i2c_clock(struct hda_codec *codec) {
- unsigned int retval;
- unsigned int newval;
- struct cs8409_spec *spec = codec->spec;
- cancel_delayed_work_sync(&spec->i2c_clk_work);
Here, cancel_delayed_work_sync(). Since it's called inside the mutex mutex (taken in the caller side), it'll lead to a deadlock.
(I know the i2c mutex lock is moved to this function in a later patch, but this makes harder to review. Given that it's only about the performance, it'd better to apply this kind of change at the end of series, not in the middle.)
In general, making such an async handling really race-free is not that trivial. Even if you call cancel_delayed_work_sync() outside the mutex, it's possible that another task wedges itself between cancel_work() and the mutex lock and re-enables the work.
One easier alternative implementation would be rather to allow enable / disable clock reentrant with refcounting. It accepts the function sequence like:
enable_clock(); i2c_write(); i2c_write(); ... disable_clock();
while another thread calls
enable_clock(); i2c_write(); disable_clock();
at the same time.
thanks,
Takashi