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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 5F51EC6778F for ; Fri, 27 Jul 2018 11:26:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0E6C620899 for ; Fri, 27 Jul 2018 11:26:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E6C620899 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730907AbeG0Mrx (ORCPT ); Fri, 27 Jul 2018 08:47:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:46578 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730654AbeG0Mrx (ORCPT ); Fri, 27 Jul 2018 08:47:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A2D5BAD0A; Fri, 27 Jul 2018 11:26:23 +0000 (UTC) Date: Fri, 27 Jul 2018 13:26:23 +0200 Message-ID: From: Takashi Iwai To: Jorge Cc: , Subject: Re: [alsa-devel] [PATCH 0/4] usb-audio: Add UAC3 Power Domains In-Reply-To: <59bd0814-e41e-667d-62d1-78194e7a8127@codethink.co.uk> References: <20180719112215.4219-1-jorge.sanjuan@codethink.co.uk> <59bd0814-e41e-667d-62d1-78194e7a8127@codethink.co.uk> 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/26 (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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Jul 2018 12:44:18 +0200, Jorge wrote: > > > > On 19/07/18 12:56, Takashi Iwai wrote: > > On Thu, 19 Jul 2018 13:22:11 +0200, > > Jorge Sanjuan wrote: > >> > >> This patchset add support for UAC3 Power Domains. This feature > >> of the USB audio class 3 allows the host to notify the device > >> what it is making use of so power comsumption can be optimized. > >> > >> This proposal implements this feature for Power Domains > >> that include an Input/Output Terminal associated to an > >> audio Streaming interface. This is the main usage of this > >> feature according to the spec. For that reason, the logic > >> for the Power Domain state change has been implemented > >> within the ALSA PCMs logic and the suspend/resume callbacks > >> of the usb_driver. The behaviour would be as follows: > >> > >> * Power Domain State D0: A Power Domain will reach this state > >> only when the audio substream associated to that domain is > >> being used (i,e. Audio playback/capture is happening). > >> * Power Domain State D1: This is the Idle state where the driver > >> is going to always want to be in order to reduce power > >> consumption. > >> * Power Domain State D2: This state is only set when the usb driver > >> asumes the device is not going to be used anymore and hence, it > >> wont care about getting any interrupts from the device. This > >> will only happen when power level is set to "auto" in sysfs > >> so the usb driver gets suspended when the interfaces are not in use. > >> NOTE: The way this has been implemented will always try to put > >> the > >> Power Domain in state D1 if the Power Domain exists so there is not a > >> way a user could disable this feature. It may be worth getting a control > >> exposed to userland that enables/disables this feature (?). > > > > Can it be tied with runtime PM? > > > > Need to read through your patchset at first... > > > > > > thanks, > > > > Takashi > > Hi, > > I just realized I accidentally only replied to alsa-devel.. Sorry > about that. Thanks for resending. > I think it should be possible to tie up the D1 state changes (low > power but still interrupt capable) to runtime PM. Changes to D2 are > already tied to PM in this patchset. Just need to find the way to > cleanly access `dev->power.runtime_auto` before the driver attempts to > set D1 state. We could also let the driver only do D2<->D0 changes for > now. Hm, OK, so the partial coverage looks feasible with the runtime PM framework, at least. > I got some kbuild errors due to missing include. Should I re-send this > patchset or try to go around getting it tied up to runtime PM first? Let's fix the easy issues with kbuild and get them merged. The proper power state support can be implemented later. thanks, Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [alsa-devel] [PATCH 0/4] usb-audio: Add UAC3 Power Domains Date: Fri, 27 Jul 2018 13:26:23 +0200 Message-ID: References: <20180719112215.4219-1-jorge.sanjuan@codethink.co.uk> <59bd0814-e41e-667d-62d1-78194e7a8127@codethink.co.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <59bd0814-e41e-667d-62d1-78194e7a8127@codethink.co.uk> Sender: linux-kernel-owner@vger.kernel.org To: Jorge Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org List-Id: alsa-devel@alsa-project.org On Fri, 27 Jul 2018 12:44:18 +0200, Jorge wrote: > > > > On 19/07/18 12:56, Takashi Iwai wrote: > > On Thu, 19 Jul 2018 13:22:11 +0200, > > Jorge Sanjuan wrote: > >> > >> This patchset add support for UAC3 Power Domains. This feature > >> of the USB audio class 3 allows the host to notify the device > >> what it is making use of so power comsumption can be optimized. > >> > >> This proposal implements this feature for Power Domains > >> that include an Input/Output Terminal associated to an > >> audio Streaming interface. This is the main usage of this > >> feature according to the spec. For that reason, the logic > >> for the Power Domain state change has been implemented > >> within the ALSA PCMs logic and the suspend/resume callbacks > >> of the usb_driver. The behaviour would be as follows: > >> > >> * Power Domain State D0: A Power Domain will reach this state > >> only when the audio substream associated to that domain is > >> being used (i,e. Audio playback/capture is happening). > >> * Power Domain State D1: This is the Idle state where the driver > >> is going to always want to be in order to reduce power > >> consumption. > >> * Power Domain State D2: This state is only set when the usb driver > >> asumes the device is not going to be used anymore and hence, it > >> wont care about getting any interrupts from the device. This > >> will only happen when power level is set to "auto" in sysfs > >> so the usb driver gets suspended when the interfaces are not in use. > >> NOTE: The way this has been implemented will always try to put > >> the > >> Power Domain in state D1 if the Power Domain exists so there is not a > >> way a user could disable this feature. It may be worth getting a control > >> exposed to userland that enables/disables this feature (?). > > > > Can it be tied with runtime PM? > > > > Need to read through your patchset at first... > > > > > > thanks, > > > > Takashi > > Hi, > > I just realized I accidentally only replied to alsa-devel.. Sorry > about that. Thanks for resending. > I think it should be possible to tie up the D1 state changes (low > power but still interrupt capable) to runtime PM. Changes to D2 are > already tied to PM in this patchset. Just need to find the way to > cleanly access `dev->power.runtime_auto` before the driver attempts to > set D1 state. We could also let the driver only do D2<->D0 changes for > now. Hm, OK, so the partial coverage looks feasible with the runtime PM framework, at least. > I got some kbuild errors due to missing include. Should I re-send this > patchset or try to go around getting it tied up to runtime PM first? Let's fix the easy issues with kbuild and get them merged. The proper power state support can be implemented later. thanks, Takashi