[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240904220632.35b4nvhmngt6akl6@synopsys.com>
Date: Wed, 4 Sep 2024 22:06:40 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: AKASH KUMAR <quic_akakum@...cinc.com>
CC: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jing Leng <jleng@...arella.com>, Felipe Balbi <balbi@...nel.org>,
Jack Pham <quic_jackp@...cinc.com>,
"kernel@...cinc.com" <kernel@...cinc.com>,
Wesley Cheng <quic_wcheng@...cinc.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Daniel Scally <dan.scally@...asonboard.com>,
Vijayavardhan Vennapusa <quic_vvreddy@...cinc.com>,
Krishna Kurapati <quic_kriskura@...cinc.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: gadget: Refine the logic for resizing Tx
FIFOs
On Wed, Sep 04, 2024, AKASH KUMAR wrote:
> 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@...cinc.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,
That doesn't make sense. The tx_fifo_resize_max_num is a configurable
constraint through devicetree property. How can it not work?
> 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.
>
We should not just look at maxburst. It's only applicable to usb3
speeds. How the function driver configures maxp_mult* vs maxbursts is
independent. So let's keep the check separate base on speed for isoc.
Thanks,
Thinh
[*] Let's refer the mouthful "additional transaction opportunities" as
maxp_mult.
Powered by blists - more mailing lists