mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: AKASH KUMAR <quic_akakum@quicinc.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jing Leng <jleng@ambarella.com>, Felipe Balbi <balbi@kernel.org>,
	Jack Pham <quic_jackp@quicinc.com>,
	"kernel@quicinc.com" <kernel@quicinc.com>,
	"Wesley Cheng" <quic_wcheng@quicinc.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Scally <dan.scally@ideasonboard.com>,
	Vijayavardhan Vennapusa <quic_vvreddy@quicinc.com>,
	Krishna Kurapati <quic_kriskura@quicinc.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: gadget: Refine the logic for resizing Tx FIFOs
Date: Wed, 4 Sep 2024 16:19:12 +0530	[thread overview]
Message-ID: <b016abbb-7214-4892-b1d2-1bf3ba1b7560@quicinc.com> (raw)
In-Reply-To: <20240903221055.s4gu6actfbrkonmr@synopsys.com>

Hi Thinh,

On 9/4/2024 3:41 AM, Thinh Nguyen wrote:
> On Tue, Sep 03, 2024, Akash Kumar wrote:
>> The current logic is rigid, setting num_fifos to fixed values:
>>
>> 3 for any maxburst greater than 1.
>> tx_fifo_resize_max_num for maxburst greater than 6.
>> Additionally, it did not differentiate much between bulk and
>> isochronous transfers, applying similar logic to both.
>>
>> The new logic is more dynamic and tailored to the specific needs of
>> bulk and isochronous transfers:
>>
>> Bulk Transfers: Ensures that num_fifos is optimized by considering
>> both the maxburst value and the maximum allowed number of FIFOs.
>>
>> Isochronous Transfers: Ensures that num_fifos is sufficient by
>> considering the maxburst value and the maximum packet multiplier.
>>
>> This change aims to optimize the allocation of Tx FIFOs for both bulk
>> and isochronous endpoints, potentially improving data transfer
>> efficiency and overall performance.
>> It also enhances support for all use cases, which can be tweaked
>> with DT parameters and the endpoint’s maxburst and maxpacket.
>>
>> Signed-off-by: Akash Kumar <quic_akakum@quicinc.com>
>> ---
>> Changes for v2:
>> Redefine logic for resizing tx fifos.
>>
>> Changes for v1:
>> Added additional condition to allocate tx fifo for hs isoc eps,
>> keeping the other resize logic same.
>> ---
>>   drivers/usb/dwc3/gadget.c | 15 ++++++---------
>>   1 file changed, 6 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 89fc690fdf34..49809a931104 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -778,15 +778,12 @@ static int dwc3_gadget_resize_tx_fifos(struct dwc3_ep *dep)
>>   
>>   	ram1_depth = DWC3_RAM1_DEPTH(dwc->hwparams.hwparams7);
>>   
>> -	if ((dep->endpoint.maxburst > 1 &&
>> -	     usb_endpoint_xfer_bulk(dep->endpoint.desc)) ||
>> -	    usb_endpoint_xfer_isoc(dep->endpoint.desc))
>> -		num_fifos = 3;
>> -
>> -	if (dep->endpoint.maxburst > 6 &&
>> -	    (usb_endpoint_xfer_bulk(dep->endpoint.desc) ||
>> -	     usb_endpoint_xfer_isoc(dep->endpoint.desc)) && DWC3_IP_IS(DWC31))
>> -		num_fifos = dwc->tx_fifo_resize_max_num;
>> +	if (usb_endpoint_xfer_bulk(dep->endpoint.desc))
>> +		num_fifos = min_t(unsigned int, dep->endpoint.maxburst + 1,
>> +				  dwc->tx_fifo_resize_max_num);
>> +	if (usb_endpoint_xfer_isoc(dep->endpoint.desc))
>> +		num_fifos = max_t(unsigned int, dep->endpoint.maxburst,
>> +				  usb_endpoint_maxp_mult(dep->endpoint.desc));
> No. Don't mix usb_endpoint_maxp_mult with maxburst like this. Check base
> on operating speed. Also, now you're ignoring tx_fifo_resize_max_num for
> isoc.
Sure will add separate check based on speed.

We have to support three versions of CAM support through same dt and image
SS/SS+ capable cam which needs 10k fifo
HS cams which needs 3K
multi UVC cams which needs 1k and 2k fifo

Putting any dependency with tx_fifo_resize_max_num, we can't achieve 1k 
and 10K,
it has to be decided by maxbursts itself which user can configure.
All uvc gadget applications supports configurable maxburst which they 
use while opening,
so it should be better for isoc eps to decide fifo based on maxbursts.

Thanks,
Akash


  reply	other threads:[~2024-09-04 10:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-03 13:29 Akash Kumar
2024-09-03 22:11 ` Thinh Nguyen
2024-09-04 10:49   ` AKASH KUMAR [this message]
2024-09-04 22:06     ` Thinh Nguyen
2024-09-05  8:27       ` AKASH KUMAR
2024-09-05 21:18         ` Thinh Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b016abbb-7214-4892-b1d2-1bf3ba1b7560@quicinc.com \
    --to=quic_akakum@quicinc.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=dan.scally@ideasonboard.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jleng@ambarella.com \
    --cc=kernel@quicinc.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_kriskura@quicinc.com \
    --cc=quic_vvreddy@quicinc.com \
    --cc=quic_wcheng@quicinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®