linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Youn <John.Youn@synopsys.com>
To: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
	John Stultz <john.stultz@linaro.org>,
	John Youn <John.Youn@synopsys.com>,
	"Minas Harutyunyan" <Minas.Harutyunyan@synopsys.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Felipe Balbi <felipe.balbi@linux.intel.com>
Subject: Re: bug? dwc2: insufficient fifo memory
Date: Mon, 5 Jun 2017 17:50:21 +0000	[thread overview]
Message-ID: <2B3535C5ECE8B5419E3ECBE300772909021B534712@US01WEMBX2.internal.synopsys.com> (raw)
In-Reply-To: 410670D7E743164D87FA6160E7907A56FDA5E05E@am04wembxa.internal.synopsys.com

On 6/5/2017 5:32 AM, Minas Harutyunyan wrote:
> On 6/2/2017 10:20 PM, John Stultz wrote:
>> On Mon, Apr 17, 2017 at 3:36 PM, John Stultz <john.stultz@linaro.org> wrote:
>>> On Fri, Feb 24, 2017 at 2:46 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>> Hey John,
>>>>   So after the USB tree landed in 4.11-rc, I've been seeing the
>>>> following warning at bootup.
>>>>
>>>> It seems the fifo_mem/total_fifo_size value on hikey is 1920, but I'm
>>>> seeing the addresses zip upward quickly as the txfsz values are all
>>>> 2048.  Not exactly sure whats wrong here.  Things still seem to work
>>>> properly.
>>>>
>>>> thanks
>>>> -john
>>>>
>>>>
>>>> [    8.944987] dwc2 f72c0000.usb: bound driver configfs-gadget
>>>> [    8.956651] insufficient fifo memory
>>>> [    8.956703] ------------[ cut here ]------------
>>>> [    8.964906] WARNING: CPU: 7 PID: 1 at drivers/usb/dwc2/gadget.c:330
>>>> dwc2_hsotg_init_fifo+0x1a8/0x1c8
>>>
>>>
>>> Hey John,
>>>    So I finally got a bit of time to look deeper into this, and it
>>> seems like this issue was introduced by commit 3c6aea7344c3 ("usb:
>>> dwc2: gadget: Add checking for g-tx-fifo-size parameter"), as that
>>> change added the following snippit:
>>>
>>>                if (hsotg->params.g_tx_fifo_size[fifo] < min ||
>>>                    hsotg->params.g_tx_fifo_size[fifo] >  dptxfszn) {
>>>                        dev_warn(hsotg->dev, "%s: Invalid parameter
>>> g_tx_fifo_size[%d]=%d\n",
>>>                                 __func__, fifo,
>>>                                 hsotg->params.g_tx_fifo_size[fifo]);
>>>                        hsotg->params.g_tx_fifo_size[fifo] = dptxfszn;
>>>                }
>>>
>>> On HiKey, we have g-tx-fifo-size = <128 128 128 128 128 128> in the
>>> dtsi, and the fifo_mem value ends up initialized at 1920.
>>>
>>> Unfortunately, in the above, it sees other entries in the
>>> g_tx_fifo_size[] array are initialized to zero, which then causes them
>>> to be set to the "default" value of dptxfszn which is 2048.  So then
>>> later in dwc2_hsotg_init_fifo() the addr value (which adds the
>>> fifo_size array value each step) quickly grows beyond the fifo_mem
>>> value, causing the warning.
>>>
>>> Not sure what the right fix is here? Should the min value be used
>>> instead of the "default" dptxfszn value?  Again, I'm not sure I see
>>> any side-effects from this warning, but wanted to try to figure out
>>> how to fix it properly.
>>
>> Hey John, Minas,
>>   Wanted to follow up on this again.  I'm using a patch that looks as
>> follows (sorry for the copy-paste whitespace damage) in the meantime
>> to work around this issue:
>>
>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>> index 9cd8722..13a911b 100644
>> --- a/drivers/usb/dwc2/params.c
>> +++ b/drivers/usb/dwc2/params.c
>> @@ -475,7 +475,7 @@ static void dwc2_check_param_tx_fifo_sizes(struct
>> dwc2_hsotg *hsotg)
>>                         dev_warn(hsotg->dev, "%s: Invalid parameter
>> g_tx_fifo_size[%d]=%d\n",
>>                                  __func__, fifo,
>>                                  hsotg->params.g_tx_fifo_size[fifo]);
>> -                       hsotg->params.g_tx_fifo_size[fifo] = dptxfszn;
>> +                       hsotg->params.g_tx_fifo_size[fifo] = min;
>>                 }
>>         }
>>  }
>>
>> Any suggestions on what a proper fix would look like?
>>
>> thanks
>> -john
>>
>
> Hi John,
>
> The patch series: "[PATCH 0/4] usb: dwc2: gadget: Fix dynamic FIFO
> initialization flow" from Sevak Arakelyan submitted to LKML at 4/26/2017
> should resolve this issue.
>
> Thanks,
> Minas
>

Hi John,

See if this patch helps and let us know.

Unfortunately, the author of this patch (and expert on this part of
the code) has left Synopsys. So it might take us a bit to look into
this.

Regards,
John

  reply	other threads:[~2017-06-05 17:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24 22:46 bug? dwc2: insufficient fifo memory John Stultz
2017-02-25  0:24 ` John Youn
2017-03-07 21:50 ` John Youn
2017-04-17 22:36 ` John Stultz
2017-05-04 23:25   ` John Stultz
2017-06-02 18:20   ` John Stultz
2017-06-05 12:32     ` Minas Harutyunyan
2017-06-05 17:50       ` John Youn [this message]
2017-07-18 20:12         ` John Stultz

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=2B3535C5ECE8B5419E3ECBE300772909021B534712@US01WEMBX2.internal.synopsys.com \
    --to=john.youn@synopsys.com \
    --cc=Minas.Harutyunyan@synopsys.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).