From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3995C4338F for ; Sun, 1 Aug 2021 08:03:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D0DA61040 for ; Sun, 1 Aug 2021 08:03:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231452AbhHAIEF (ORCPT ); Sun, 1 Aug 2021 04:04:05 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:34252 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230087AbhHAIEE (ORCPT ); Sun, 1 Aug 2021 04:04:04 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 1AD0421FF9; Sun, 1 Aug 2021 08:03:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1627805036; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iUnvT3yBk3Ak2FNUwjA/dYWqqudAaqfeubdq+0me75I=; b=Bz8m1F01OxpMp2gtaAHvBzOJRO0HAy73WEx9xUN92Y/V0shSQYitGik1zp0Pscj/82IJGD wPRJF0usS7ouGAqkZzqy56xr1qh8JY4xXqwp2FQ6bVWRWukcVZONk6sknAXhBZDfazny/n EjYPz12++B1KbP0pNi0DEsb6RjzvbsE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1627805036; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iUnvT3yBk3Ak2FNUwjA/dYWqqudAaqfeubdq+0me75I=; b=qjaqYRQ2CFcwE1tIRHdsUZGIYL0YSKnwYCNppSWb1qukP9Heb67yHuL3zOWdxpIO0esjiA 4SLzjXqMVShi38Bg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 0774FA3BA8; Sun, 1 Aug 2021 08:03:56 +0000 (UTC) Date: Sun, 01 Aug 2021 10:03:55 +0200 Message-ID: From: Takashi Iwai To: Vitaly Rodionov Cc: Jaroslav Kysela , Takashi Iwai , , , , Lucas Tanure , Stefan Binding Subject: Re: [PATCH v3 13/27] ALSA: hda/cs8409: Dont disable I2C clock between consecutive accesses In-Reply-To: <20210730151844.7873-14-vitalyr@opensource.cirrus.com> References: <20210730151844.7873-1-vitalyr@opensource.cirrus.com> <20210730151844.7873-14-vitalyr@opensource.cirrus.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Jul 2021 17:18:30 +0200, Vitaly Rodionov wrote: > > From: Lucas Tanure > > 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 > Signed-off-by: Vitaly Rodionov > Signed-off-by: Stefan Binding > --- > > Changes in v2: > - Improved delayed work start/cancel implementation, and re-worked commit message > adding more explanation why this was required. > > Changes in v3: > - Cancel the disable timer, but do not wait for any running disable functions to finish. > If the disable timer runs out before cancel, the delayed work thread will be blocked, > waiting for the mutex to become unlocked. This mutex will be locked for the duration of > any i2c transaction, so the disable function will run to completion immediately > afterwards in the scenario. The next enable call will re-enable the clock, regardless. This looks almost fine, but just a couple of thoughts: - cancel_delayed_work_sync() means to it might keep the i2c enabled after that point (just cancel the pending work). Would it cause a inconsistency afterwards? - A similar procedure is needed for suspend callback to cancel / flush the work. The shutdown is another question, but usually it's fine to without any special handling as long as the resource is kept. thanks, Takashi