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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 49A53D2C567 for ; Tue, 22 Oct 2024 15:05:04 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 6E11D3E8; Tue, 22 Oct 2024 17:04:51 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 6E11D3E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1729609501; bh=QUUBW21t3BimnstQVgGZ0SBenbQzNgaGQZcFRj4mm8Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=GWoEek7PGO8UQjhb0HrcVSG+U0tmJb0JSXJvGqmznROdO22OWHsS1rdwIsvSHTwi1 onIKWVMEax8ZFaFbn/Mifhgwu+hLzOlKy5TQQS9qdqBrzc73OUPwcIZz4gJu2u6tEt IC/sjqxzGheqKdDQILxTNhfhVa930tKP3adHtCKk= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 39E17F805AF; Tue, 22 Oct 2024 17:04:30 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id CF8C5F805AF; Tue, 22 Oct 2024 17:04:29 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2938BF8016C; Tue, 22 Oct 2024 17:04:23 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 9A9D9F80149 for ; Tue, 22 Oct 2024 17:04:19 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 9A9D9F80149 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=lW/WsS7U DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729609462; x=1761145462; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=QUUBW21t3BimnstQVgGZ0SBenbQzNgaGQZcFRj4mm8Y=; b=lW/WsS7UP3Wb3wukhaYqcaZCCXqvOYRLwojwkF+TFtlSCrSvAgFPIcPW jnOK2Xuhq1/A9gW9FFddrXXYz6P1rQoPya+wdB+3aeM0XdSZls0KmvABP d1ucwISbNZsoKrhdtrhkkBsGZH+vBEDolB8HFO9ZNxbaD0DHB1Y8i1ZSv F+CD/kxVIULnnu3TTNRFYyfQWffcVXW/A98sd85sy2cY8Dvoa/sapqqhs Ftm0XZf7AoIPJLyO6jaUYHsaNXzK/yIsG2umVCzs57XB4sEAiDae3j0+X ozzmb2E0LVVYVdLNyYhmJTO7D0UizmtwVUOTQtUpANACytvC+ZSPtACsJ Q==; X-CSE-ConnectionGUID: l3D98gfRTKSstYBjHZIeUg== X-CSE-MsgGUID: FrlON3w6QuS7nCpN26vXpA== X-IronPort-AV: E=McAfee;i="6700,10204,11233"; a="33079484" X-IronPort-AV: E=Sophos;i="6.11,223,1725346800"; d="scan'208";a="33079484" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2024 08:04:17 -0700 X-CSE-ConnectionGUID: t2EfxH96Ts+ZMKuBfhIFQA== X-CSE-MsgGUID: JAHYnJKXTd6WFkKNAaIiYw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,223,1725346800"; d="scan'208";a="80072066" Received: from aslawinx-mobl.ger.corp.intel.com (HELO [10.94.0.53]) ([10.94.0.53]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Oct 2024 08:04:10 -0700 Message-ID: <8795c4ad-e3ac-47aa-92dd-f899042cefc0@linux.intel.com> Date: Tue, 22 Oct 2024 17:04:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v29 01/33] xhci: support setting interrupt moderation IMOD for secondary interrupters To: Greg KH , Takashi Iwai Cc: Wesley Cheng , srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, conor+dt@kernel.org, dmitry.torokhov@gmail.com, corbet@lwn.net, lgirdwood@gmail.com, tiwai@suse.com, krzk+dt@kernel.org, pierre-louis.bossart@linux.intel.com, Thinh.Nguyen@synopsys.com, broonie@kernel.org, bgoswami@quicinc.com, robh@kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-sound@vger.kernel.org, linux-input@vger.kernel.org, linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org, alsa-devel@alsa-project.org, Mathias Nyman References: <20241015212915.1206789-1-quic_wcheng@quicinc.com> <20241015212915.1206789-2-quic_wcheng@quicinc.com> <2024101747-defog-squiggly-ef54@gregkh> <5847c380-75ce-492a-9a30-0899b7ebe98c@quicinc.com> <2024101824-hammock-elastic-8d38@gregkh> <87wmi02qcj.wl-tiwai@suse.de> <2024102240-gag-famished-245c@gregkh> Content-Language: en-US From: =?UTF-8?Q?Amadeusz_S=C5=82awi=C5=84ski?= In-Reply-To: <2024102240-gag-famished-245c@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: UW76LIY36DSTDDJR27AYAK6QHGUAXP5H X-Message-ID-Hash: UW76LIY36DSTDDJR27AYAK6QHGUAXP5H X-MailFrom: amadeuszx.slawinski@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 10/22/2024 4:02 PM, Greg KH wrote: > On Tue, Oct 22, 2024 at 03:56:44PM +0200, Takashi Iwai wrote: >> On Fri, 18 Oct 2024 07:52:35 +0200, >> Greg KH wrote: >>> >>> On Thu, Oct 17, 2024 at 05:07:12PM -0700, Wesley Cheng wrote: >>>> Hi Greg, >>>> >>>> On 10/16/2024 11:40 PM, Greg KH wrote: >>>>> On Tue, Oct 15, 2024 at 02:28:43PM -0700, Wesley Cheng wrote: >>>>>> From: Mathias Nyman >>>>>> >>>>>> Allow creators of xHCI secondary interrupters to specify the interrupt >>>>>> moderation interval value in nanoseconds when creating the interrupter. >>>>>> >>>>>> If not sure what value to use then use the xhci driver default >>>>>> xhci->imod_interval >>>>>> >>>>>> Suggested-by: Wesley Cheng >>>>>> Signed-off-by: Mathias Nyman >>>>>> Link: https://lore.kernel.org/r/20240905143300.1959279-13-mathias.nyman@linux.intel.com >>>>>> Signed-off-by: Greg Kroah-Hartman >>>>>> --- >>>>>> drivers/usb/host/xhci-mem.c | 8 +++++++- >>>>>> drivers/usb/host/xhci.c | 4 ++-- >>>>>> drivers/usb/host/xhci.h | 5 ++++- >>>>>> 3 files changed, 13 insertions(+), 4 deletions(-) >>>>> This is already in 6.12-rc1, which makes me confused as to what tree you >>>>> made this series against. >>>> >>>> Sorry, I didn't fetch the latest changes from usb-next. >>> >>> It wasn't even usb-next, it was 6.12-rc1, so I don't know what tree you >>> based this on :( >>> >>>> In this case, should I rebase and resbumit? >>> >>> As the series can't be applied as-is, probably. But I think you might >>> want to collect some acks from the sound people and xhci developers, as >>> I can't do anything with this until they look at the changes. >> >> Honestly speaking, I couldn't follow fully the discussions about the >> fundamental design -- IIRC, Pierre and others had concerns to the way >> to manage the offload device via kcontrols. Did we get consensus? > > I don't think so. > >> I believe that's the biggest obstacle in the audio side, i.e. what's >> visible to users. The kernel internals can be corrected at any time >> later. > > I would like to see that agreed on before I even look at the usb side. My main concern is still that one USB audio device can be accessed via two different cards exposed in userspace. Usual USB one, and the one from device which does "offload". Suggested implementation achieves it by adding additional controls, which need to be set in specific way to achieve offload. Overall while I understand the mechanism, I'm not exactly convinced that it is the best way from end user point of view. "Implementation" part in Documentation added in patch 19 shows how it looks in userspace now. If you don't mind two sound cards being used to access same piece of HW, current implementation looks ok to me. See also: https://lore.kernel.org/linux-sound/75ffde3a-7fef-4c15-bfc8-87756e1c3f11@linux.intel.com/ where I described how I would prefer it to look.