From: Felipe Balbi <balbi@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>,
Wesley Cheng <wcheng@codeaurora.org>
Cc: agross@kernel.org, bjorn.andersson@linaro.org,
robh+dt@kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, jackp@codeaurora.org,
Thinh.Nguyen@synopsys.com
Subject: Re: [PATCH v9 0/5] Re-introduce TX FIFO resize for larger EP bursting
Date: Fri, 04 Jun 2021 17:18:16 +0300 [thread overview]
Message-ID: <87k0n9btnb.fsf@kernel.org> (raw)
In-Reply-To: <YLoUiO8tpRpmvcyU@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]
Hi,
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, May 19, 2021 at 12:49:16AM -0700, Wesley Cheng wrote:
>> Changes in V9:
>> - Fixed incorrect patch in series. Removed changes in DTSI, as dwc3-qcom will
>> add the property by default from the kernel.
>
> This patch series has one build failure and one warning added:
>
> drivers/usb/dwc3/gadget.c: In function ‘dwc3_gadget_calc_tx_fifo_size’:
> drivers/usb/dwc3/gadget.c:653:45: warning: passing argument 1 of ‘dwc3_mdwidth’ makes pointer from integer without a cast [-Wint-conversion]
> 653 | mdwidth = dwc3_mdwidth(dwc->hwparams.hwparams0);
> | ~~~~~~~~~~~~~^~~~~~~~~~
> | |
> | u32 {aka unsigned int}
> In file included from drivers/usb/dwc3/debug.h:14,
> from drivers/usb/dwc3/gadget.c:25:
> drivers/usb/dwc3/core.h:1493:45: note: expected ‘struct dwc3 *’ but argument is of type ‘u32’ {aka ‘unsigned int’}
> 1493 | static inline u32 dwc3_mdwidth(struct dwc3 *dwc)
> | ~~~~~~~~~~~~~^~~
>
>
> drivers/usb/dwc3/dwc3-qcom.c: In function ‘dwc3_qcom_of_register_core’:
> drivers/usb/dwc3/dwc3-qcom.c:660:23: error: implicit declaration of function ‘of_add_property’; did you mean ‘of_get_property’? [-Werror=implicit-function-declaration]
> 660 | ret = of_add_property(dwc3_np, prop);
> | ^~~~~~~~~~~~~~~
> | of_get_property
>
>
> How did you test these?
to be honest, I don't think these should go in (apart from the build
failure) because it's likely to break instantiations of the core with
differing FIFO sizes. Some instantiations even have some endpoints with
dedicated functionality that requires the default FIFO size configured
during coreConsultant instantiation. I know of at OMAP5 and some Intel
implementations which have dedicated endpoints for processor tracing.
With OMAP5, these endpoints are configured at the top of the available
endpoints, which means that if a gadget driver gets loaded and takes
over most of the FIFO space because of this resizing, processor tracing
will have a hard time running. That being said, processor tracing isn't
supported in upstream at this moment.
I still think this may cause other places to break down. The promise the
databook makes is that increasing the FIFO size over 2x wMaxPacketSize
should bring little to no benefit, if we're not maintaining that, I
wonder if the problem is with some of the BUSCFG registers instead,
where we configure interconnect bursting and the like.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]
next prev parent reply other threads:[~2021-06-04 14:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 7:49 [PATCH v9 0/5] Re-introduce TX FIFO resize for larger EP bursting Wesley Cheng
2021-05-19 7:49 ` [PATCH v9 1/5] usb: gadget: udc: core: Introduce check_config to verify USB configuration Wesley Cheng
2021-05-19 7:49 ` [PATCH v9 2/5] usb: gadget: configfs: Check USB configuration before adding Wesley Cheng
2021-05-19 7:49 ` [PATCH v9 3/5] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Wesley Cheng
2021-05-19 7:49 ` [PATCH v9 4/5] usb: dwc3: dwc3-qcom: Enable tx-fifo-resize property by default Wesley Cheng
2021-05-19 7:49 ` [PATCH v9 5/5] dt-bindings: usb: dwc3: Update dwc3 TX fifo properties Wesley Cheng
2021-06-04 11:54 ` [PATCH v9 0/5] Re-introduce TX FIFO resize for larger EP bursting Greg KH
2021-06-04 14:18 ` Felipe Balbi [this message]
2021-06-04 14:36 ` Greg KH
2021-06-08 5:44 ` Wesley Cheng
2021-06-10 9:20 ` Felipe Balbi
2021-06-10 10:03 ` Greg KH
2021-06-10 10:16 ` Felipe Balbi
2021-06-10 18:15 ` Wesley Cheng
2021-06-11 6:29 ` Felipe Balbi
2021-06-11 8:43 ` Wesley Cheng
2021-06-11 13:00 ` Felipe Balbi
2021-06-11 13:14 ` Heikki Krogerus
2021-06-11 13:21 ` Andy Shevchenko
2021-06-12 21:27 ` Ferry Toth
2021-06-12 21:37 ` Andy Shevchenko
2021-06-14 18:58 ` Wesley Cheng
2021-06-14 19:30 ` Ferry Toth
2021-06-15 4:22 ` Wesley Cheng
2021-06-15 19:53 ` Ferry Toth
2021-06-17 4:25 ` Wesley Cheng
[not found] ` <fe834dbf-786a-2996-5c4b-1eac92e3ed18@gmail.com>
2021-06-17 8:30 ` Wesley Cheng
2021-06-17 19:54 ` Ferry Toth
2021-07-01 1:08 ` Wesley Cheng
2021-06-07 16:04 ` Jack Pham
2021-06-08 5:07 ` Wesley Cheng
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=87k0n9btnb.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jackp@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh+dt@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.