All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Jack Pham <jackp@codeaurora.org>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Wesley Cheng <wcheng@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: gadget: Skip resizing EP's TX FIFO if already resized
Date: Wed, 20 Oct 2021 00:27:38 +0000	[thread overview]
Message-ID: <539dca19-c900-e13e-5af1-a06a53901fb5@synopsys.com> (raw)
In-Reply-To: <20211019053848.GC16586@jackp-linux.qualcomm.com>

Jack Pham wrote:
> On Tue, Oct 19, 2021 at 02:38:30AM +0000, Thinh Nguyen wrote:
>> Jack Pham wrote:
>>> On Fri, Oct 15, 2021 at 10:20:48PM +0000, Thinh Nguyen wrote:
>>>> TX endpoints should have non-zero GTXFIFOSIZ. Using the register as a
>>>> flag to check whether it's been resized is not ok. Also, what happened
>>>> after resizing the txfifo? Do you restore its previous default value?
>>>
>>> The choice to use the resizing algorithm is a fixed setting determined
>>> by device property.  So if it is enabled for a particular platform
>>> instance, it means we don't intend to use any of the default values.
>>> All the registers will get cleared to 0 upon every Set Configuration so
>>> that each EP enable call thereafter will be starting from a clean slate.
>>
>> Some fields of GTXFIFOSIZ may not get cleared. Depends on the controller
>> version, we introduce different fields (as the case for DWC32 and
>> DWC31). So this may not apply for all the time. I just noticed that the
>> entire GTXFIFOSIZ was written with 0. Please only write to the specific
>> fields with proper macros.
> 
> Hmm, I thought Wesley's original change already takes care to do that:
> 

I was referring to the field such as TXFRAMNUM that the check "if
(GTXFIFOSIZ)" may not work because this field may be non-zero by default.

> void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
> {
> ...
> 	/* Clear existing TXFIFO for all IN eps except ep0 */
> 	for (num = 3; num < min_t(int, dwc->num_eps, DWC3_ENDPOINTS_NUM);
>              num += 2) {
> 		dep = dwc->eps[num];
> 		/* Don't change TXFRAMNUM on usb31 version */
> 		size = DWC3_IP_IS(DWC3) ? 0 :
> 			dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(num >> 1)) &
>                 		DWC31_GTXFIFOSIZ_TXFRAMNUM;

I think it's better to use masks such as below since it's
self-documented, but it's probably fine as is.

size &= ~(DWC3x_GTXFIFOSIZ_TXFSADDR(~0) | DWC3x_GTXFIFOSIZ_TXFDEP(~0));

> 
> 		dwc3_writel(dwc->regs, DWC3_GTXFIFOSIZ(num >> 1), size);
> 		dep->flags &= ~DWC3_EP_TXFIFO_RESIZED;
> 	}
> 	dwc->num_ep_resized = 0;
> }
> 
> Just before the write, the read is masked with the TXFRAMNUM bit in case
> of !DWC3, i.e. DWC31 or DWC32.  The rest would be 0'ed out.  Sorry if my
> previous reply implied the entire register was written as 0.
> 

For DWC32, the field TXFRAMNUM is replaced with something else, but the
TXFSADDR and TXFDEP are unchanged since DWC31. Check that we don't
unintentionally overwrite bit(15) of GTXFIFOSIZ for DWC32 and DWC31 when
updating txfifo.

Thanks,
Thinh

      reply	other threads:[~2021-10-20  0:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09  8:31 [PATCH] usb: dwc3: gadget: Skip resizing EP's TX FIFO if already resized Jack Pham
2021-09-09  8:41 ` Felipe Balbi
2021-09-09 17:02   ` Jack Pham
2021-09-10  5:17     ` Felipe Balbi
2021-09-10 17:20       ` Jack Pham
2021-09-10  1:15 ` Thinh Nguyen
2021-09-11  1:29   ` Wesley Cheng
2021-09-11  3:08     ` Thinh Nguyen
2021-09-14  2:01       ` Wesley Cheng
2021-10-08  0:07         ` Thinh Nguyen
2021-10-15  0:51           ` Jack Pham
2021-10-15 22:20             ` Thinh Nguyen
2021-10-15 23:52               ` Thinh Nguyen
2021-10-15 23:55               ` Thinh Nguyen
2021-10-18  7:28               ` Jack Pham
2021-10-19  2:38                 ` Thinh Nguyen
2021-10-19  5:38                   ` Jack Pham
2021-10-20  0:27                     ` Thinh Nguyen [this message]

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=539dca19-c900-e13e-5af1-a06a53901fb5@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jackp@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=wcheng@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.