Received-SPF: pass (google.com: domain of linux-kernel+bounces-172020-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <518a046b-1056-287b-f505-149958ad9c9c@quicinc.com>
Date: Tue, 7 May 2024 11:57:36 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH] usb: dwc3: gadget: create per ep interrupts
To: Michael Grzeschik <m.grzeschik@pengutronix.de>,
        Thinh Nguyen
	<Thinh.Nguyen@synopsys.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: <michael.riesch@wolfvision.net>, <kernel@pengutronix.de>,
        <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20240507-dwc3_per_ep_irqthread-v1-1-f14dec6de19f@pengutronix.de>
Content-Language: en-US
From: Wesley Cheng <quic_wcheng@quicinc.com>
In-Reply-To: <20240507-dwc3_per_ep_irqthread-v1-1-f14dec6de19f@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michael,

On 5/6/2024 4:06 PM, Michael Grzeschik wrote:
> This patch is splitting up the interrupt event handling from one
> interrupt thread to separate per endpoint interrupt threads.
> 

I assume that the incentive from doing this is to improve overall 
throughput numbers.  Would you be able to share some data on the 
benefits of moving to per EP event management?

> To achieve this we create a new dwc3 interrupt domain in which
> we map all claimed interrupts to individual interrupt threads.
> 
> Although the gadget layer is preparing the claimed parameter
> of each usb_ep which could be checked if the endpoint is
> to used or not, the claimed value was 0 for each ep in gadget_start.
> This was tested when describing some composite gadget using configfs.
> 

yeah... the claimed flag is cleared by the USB gadget, ie USB configfs 
(not sure if you're using this) whenever it adds a USB config.  This is 
to handle multi config situations, so subsequent USB configs can be 
assigned (resuse) endpoints, since only one config is active at a time 
for a USB device.

This was a struggle for me as well when adding the TXFIFO resizing 
logic.  We won't actually know which EPs are going to be used until the 
host issues the set configuration packet to select a config, and the 
set_alt() callback issues usb_ep_enable().  So the implementation 
(TXFIFO resizing) is currently based on the maximum potential endpoints 
used by any USB configuration.

Not sure if having 31 (potentially) different IRQ entries would be ok, 
but maybe it would be simpler to just to request IRQ for dwc->num_eps 
always?

Have you tried this on a multi config device?

Thanks
Wesley Cheng