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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 E8B35C48BCF for ; Sun, 13 Jun 2021 07:26:46 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 94ECC611C0 for ; Sun, 13 Jun 2021 07:26:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94ECC611C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 4571E1760; Sun, 13 Jun 2021 09:25:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4571E1760 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1623569202; bh=2M9tFT5iXQ8N3Xy7VxmV3aP9Q5UvpMHF9rXrmeSrr2M=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lo8rCiXw7VvC9uygRZBh9BPfmdsEgcc3zbKeR3RkrpvfrYl5KrqX0KhxgoDz17yb4 WZXHpkSOJTzL7P0YR2YbxDksjcoHRvb/b5JlIGihuTCWlnEKn/Bp7CxiFHhWiR1l+j Li5fRTPkeYnMD7CTqZc7S1FxRRxg1lvEJGSOXbbo= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id C742FF800FB; Sun, 13 Jun 2021 09:25:51 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 10CDCF80165; Sun, 13 Jun 2021 09:25:49 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 3FE7EF800FA for ; Sun, 13 Jun 2021 09:25:45 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 3FE7EF800FA Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="alCQ1BCQ"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="bj9qLA4R" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 1CC5E21973; Sun, 13 Jun 2021 07:25:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623569144; 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=QL8lJxnyNxv+tWk9n8Z0jhoFlWg5bg43DAOyxNRkubQ=; b=alCQ1BCQoTAH5lqnhsmg5hzrzhEgvmJVceVf8hO0/Bjpdectmh00E/oNZZTwJL3CiePyoP G5JaWuIOa//8XbPikdU9ll+iuU+CEsSXZVcTjJqYdgU88dLl4AsM9CaL9Je+yNt2kSQc++ TzxF5Spwqb35CFAUzNJKaBXzaLsIhHI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623569144; 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=QL8lJxnyNxv+tWk9n8Z0jhoFlWg5bg43DAOyxNRkubQ=; b=bj9qLA4RA8Ep+f0LQvXFKDWZDkXkqxBi/0fasBtPfzdeSyB8rdJfsIIpj6pmKktCCKwY6q 2sVt1PuhPQb7ieAg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 04351A3B83; Sun, 13 Jun 2021 07:25:43 +0000 (UTC) Date: Sun, 13 Jun 2021 09:25:43 +0200 Message-ID: From: Takashi Iwai To: Pierre-Louis Bossart Subject: Re: [PATCH 0/8] ASoC: SOF: power optimizations for HDaudio platforms In-Reply-To: <6f8c8799-2602-a5a2-cf38-cc6a11eac593@linux.intel.com> References: <20210610205326.1176400-1-pierre-louis.bossart@linux.intel.com> <482fc9a8-3a27-2e5d-f280-c891832eb467@perex.cz> <1f71ec67-041e-d2fc-3527-5542d8982e00@perex.cz> <6f8c8799-2602-a5a2-cf38-cc6a11eac593@linux.intel.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 Cc: alsa-devel@alsa-project.org, Mark Brown X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Fri, 11 Jun 2021 18:30:53 +0200, Pierre-Louis Bossart wrote: > > > > Perhaps, it may be acceptable to add a global control enum (to the control > > API) for the ALSA card which may modify the driver behaviour / settings at > > runtime (normal operation, battery saving operation etc.). This control can be > > set in the UCM config. In this way, we don't need to touch the PCM API for the > > user space at all. > > If there was a mechanism based on ALSA controls for an application to > query capabilities and set what it want to disable that would be > fine. hwdep would be fine as well. > > I don't get though how this could be 'set in the UCM config', > different apps might have different needs. UCM files don't currently > make assumptions on which application uses them, do they? I also came to the idea of kcontrol instead of module parameter, and hit to the differentiating via UCM, too. Maybe we may provide two different profiles and let apps choose. But, this reaches to the question: how to tell applications what is for. It's also the question if we extend the API. Namely, the driver may inform user-space or the user-space may inform the driver whether to allow (or to use) the rewind. But, it doesn't explain what cost it would need. And that's a difficult task to generalize it. I can think of some API providing a preset per scenario, e.g. power-saving, large buffer, etc. But in this case, if rewind is allowed, what would it mean practically? Then, this also led me a question: what happens if you disable tsched on PA? It'll be essentially equivalent behavior like pipewire, and this would be better? Note that the latest kernel already dropped the buffer pre-allocation for HD-audio, hence PA will take a large buffer (for one second) per default. I suppose that the influence of no rewind becomes noticeable, or would it still be OK with tsched? If tsched=0 mode works reasonably well in case of no rewind, it can be done simply by setting SNDRV_PCM_INFO_BATCH together. Even with this change, we can keep the module parameter as a kill switch in case significant regression is found. thanks, Takashi