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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53B08C4167B for ; Wed, 28 Dec 2022 15:46:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234022AbiL1PqQ (ORCPT ); Wed, 28 Dec 2022 10:46:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234015AbiL1PqP (ORCPT ); Wed, 28 Dec 2022 10:46:15 -0500 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8947614D27; Wed, 28 Dec 2022 07:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672242373; x=1703778373; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=SB1x38s3dv6Gdzi7eiwaN7LwRGEtLuEFsZIEzhZwdls=; b=UBGqbU5V0c0n6bGCc03FYH4wSOXmVytfP7hOBWhgEvMoeakXOeHgXye/ 1UVzWNvVQX4SjM/i7kVfGDDo60mc2NIN3/yb2y2U93Wd2flct+JbcPz7y In508AxydbVsy1R5WG7xulsQo0GythLWrg3omyiPmbcInouCAZRe8UFgg SOCj2FMdzP6medUMzDI/MQxthO9LM25JBt/4opvIYB0ciIzXA73Q5y+3A ABkj6j3WY/FLy58jn6m8NzzqulbNu63Us+AsOGEcyyRA0kKr5zbngx3QJ ZVEm2ebkJyzuz40afva9gx7DJZgtQr/CLVKXPGPpu4xcgchJKsi83MypU w==; X-IronPort-AV: E=McAfee;i="6500,9779,10574"; a="304388687" X-IronPort-AV: E=Sophos;i="5.96,281,1665471600"; d="scan'208";a="304388687" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Dec 2022 07:46:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10574"; a="982118992" X-IronPort-AV: E=Sophos;i="5.96,281,1665471600"; d="scan'208";a="982118992" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by fmsmga005.fm.intel.com with ESMTP; 28 Dec 2022 07:46:07 -0800 Message-ID: <7dfe215b-4cc7-f95f-17c3-563c0120151a@linux.intel.com> Date: Wed, 28 Dec 2022 17:47:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 To: Wesley Cheng , srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, broonie@kernel.org, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com References: <20221223233200.26089-1-quic_wcheng@quicinc.com> <20221223233200.26089-8-quic_wcheng@quicinc.com> Content-Language: en-US From: Mathias Nyman Subject: Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support In-Reply-To: <20221223233200.26089-8-quic_wcheng@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 24.12.2022 1.31, Wesley Cheng wrote: > Implement the XHCI operations for allocating and requesting for a secondary > interrupter. The secondary interrupter can allow for events for a > particular endpoint to be routed to a separate event ring. The event > routing is defined when submitting a transfer descriptor to the USB HW. > There is a specific field which denotes which interrupter ring to route the > event to when the transfer is completed. > > An example use case, such as audio packet offloading can utilize a separate > event ring, so that these events can be routed to a different processor > within the system. The processor would be able to independently submit > transfers and handle its completions without intervention from the main > processor. > Adding support for more xHCI interrupters than just the primary one make sense for both the offloading and virtualization cases. xHCI support for several interrupters was probably added to support virtualization, to hand over usb devices to virtual machines and give them their own event ring and MSI/MSI-X vector. In this offloading case you probably want to avoid xHC interrupts from this device completely, making sure it doesn't wake up the main CPU unnecessarily. So is the idea here to let xhci driver set up the new interrupter, its event ring, and the endpoint transfer rings. Then pass the address of the endpoint transfer rings and the new event ring to the separate processor. This separate processor then both polls the event ring for new events, sets its dequeue pointer, clears EHB bit, and queues new TRBs on the transfer ring. so xhci driver does not handle any events for the audio part, and no audio data URBs are sent to usb core? How about the control part? Is the control endpoint for this device still handled normally by usb core/xhci? For the xhci parts I think we should start start by adding generic support for several interrupters, then add parts needed for offloading. Thanks Mathias 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 5BE78C3DA7A for ; Wed, 28 Dec 2022 15:47:15 +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 8BBD35311; Wed, 28 Dec 2022 16:46:20 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 8BBD35311 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1672242430; bh=SB1x38s3dv6Gdzi7eiwaN7LwRGEtLuEFsZIEzhZwdls=; h=Date:To:References:From:Subject:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=aVpNdpJmwFlRSfRjzO1iAswNydyPHHJRjvJWE+xJ455E3qhcOIFRPBd/NBu0ZNddl EFL6VeH3rTdw9aneX2RuBjvbTnM4nlsWi1CuM/d6gblCMT+lfKpZigiOkCl51VLpbm E/TIE27RicphMWcMk8fsJRvqXz2YlcijZs12sPTc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 29A99F80424; Wed, 28 Dec 2022 16:46:20 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 74788F800F0; Wed, 28 Dec 2022 16:46:18 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 8E8EDF800F0 for ; Wed, 28 Dec 2022 16:46:15 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8E8EDF800F0 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=DHPWjgQf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672242376; x=1703778376; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=SB1x38s3dv6Gdzi7eiwaN7LwRGEtLuEFsZIEzhZwdls=; b=DHPWjgQf8kIF01kPTtS51OjBt6N2vbLDjNv32V9l+BG9MbwodfcQ9MSd 9EXFoRhtjY+Vs5SzRjDuoIwZBQYQ29t9W2gRSC1Ov5DbQmE13BM7loGpp n4Gv7ti1tQquSC9qGMFwWV/wqIuooUADtVCV38Ujmk3szm8RiFGDKhPU6 eSbFd8EJSPbobJo2qrI76pcEJ+4JjzNp7RiSKGI4RcveCLrR7DeJTnLjW HX1ph3aqnQi9P0ODx0TUxcevYw0MbpgkMhN6hr4yIPcK5MrtN6ks7Vqcu 2uZBWm3qtD82tBzICm2rw247TXSDoFgRBJs2g0xC+Y9474G2MMNQHcvhX w==; X-IronPort-AV: E=McAfee;i="6500,9779,10574"; a="304388693" X-IronPort-AV: E=Sophos;i="5.96,281,1665471600"; d="scan'208";a="304388693" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Dec 2022 07:46:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10574"; a="982118992" X-IronPort-AV: E=Sophos;i="5.96,281,1665471600"; d="scan'208";a="982118992" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by fmsmga005.fm.intel.com with ESMTP; 28 Dec 2022 07:46:07 -0800 Message-ID: <7dfe215b-4cc7-f95f-17c3-563c0120151a@linux.intel.com> Date: Wed, 28 Dec 2022 17:47:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 To: Wesley Cheng , srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, broonie@kernel.org, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org References: <20221223233200.26089-1-quic_wcheng@quicinc.com> <20221223233200.26089-8-quic_wcheng@quicinc.com> Content-Language: en-US From: Mathias Nyman Subject: Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support In-Reply-To: <20221223233200.26089-8-quic_wcheng@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 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: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On 24.12.2022 1.31, Wesley Cheng wrote: > Implement the XHCI operations for allocating and requesting for a secondary > interrupter. The secondary interrupter can allow for events for a > particular endpoint to be routed to a separate event ring. The event > routing is defined when submitting a transfer descriptor to the USB HW. > There is a specific field which denotes which interrupter ring to route the > event to when the transfer is completed. > > An example use case, such as audio packet offloading can utilize a separate > event ring, so that these events can be routed to a different processor > within the system. The processor would be able to independently submit > transfers and handle its completions without intervention from the main > processor. > Adding support for more xHCI interrupters than just the primary one make sense for both the offloading and virtualization cases. xHCI support for several interrupters was probably added to support virtualization, to hand over usb devices to virtual machines and give them their own event ring and MSI/MSI-X vector. In this offloading case you probably want to avoid xHC interrupts from this device completely, making sure it doesn't wake up the main CPU unnecessarily. So is the idea here to let xhci driver set up the new interrupter, its event ring, and the endpoint transfer rings. Then pass the address of the endpoint transfer rings and the new event ring to the separate processor. This separate processor then both polls the event ring for new events, sets its dequeue pointer, clears EHB bit, and queues new TRBs on the transfer ring. so xhci driver does not handle any events for the audio part, and no audio data URBs are sent to usb core? How about the control part? Is the control endpoint for this device still handled normally by usb core/xhci? For the xhci parts I think we should start start by adding generic support for several interrupters, then add parts needed for offloading. Thanks Mathias