linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Jerry Huang <jerry.huang@nxp.com>,
	"gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rajesh Bhagat <rajesh.bhagat@nxp.com>
Subject: RE: [PATCH] USB3/DWC3: Enable undefined length INCR burst type
Date: Fri, 16 Dec 2016 13:44:10 +0200	[thread overview]
Message-ID: <87bmwcf69h.fsf@linux.intel.com> (raw)
In-Reply-To: <DB5PR0401MB18132838F0F401FDCAF4BA7FFE9C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]


Hi,

Jerry Huang <jerry.huang@nxp.com> writes:
>> there's no need for that. This patch is in good format. I do have a question,
>> however: how do you know this will work for all users? Burst size is a function
>> of how wide the interconnect where dwc3 is attached to, is.
> So I need to generate one new property in usb node to identify my platform?

Well, we probably need a property to be passed, yes. But let's go
through it all first :-)

>> You could very well be degrading performance for some users here. Can you
>> send me the result of the following commands *without* this patch applied?
>> 
>> # mkdir -p /d
>> # mount -t debugfs none /d
>> # cat /d/*dwc3*/regdump
>> 
> Below is the regdump:
> root@ls1043ardb:/d/3000000.usb3# cat regdump
> GSBUSCFG0 = 0x00100080

so you already have INCR256 here. There's one note in the databook which
just caught my attention. It states the following:

	"Undefined burst length has priority over all other burst lenghts."

This means that setting both INCR16 and undefined INCR is
unnecessary. Only Undefined INCR will be taken into consideration. Can
you check with your HW engineers what's the largest burst the
interconnect is supposed to support?

> GSBUSCFG1 = 0x00000700

8 AXI pipelined requests

> GSNPSID = 0x5533280a

2.80a cool :-)

I'll check these settings on my platform as well and see if there's any
setting which would improve transfer speed. This is a very good idea,
btw, but we need to be careful about how to play with it.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2016-12-16 11:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13  9:06 [PATCH] USB3/DWC3: Enable undefined length INCR burst type Changming Huang
2016-12-16  3:07 ` Jerry Huang
2016-12-16  9:16   ` Felipe Balbi
2016-12-16  9:58     ` Jerry Huang
2016-12-16 11:44       ` Felipe Balbi [this message]
2016-12-16 16:18         ` Jerry Huang
2016-12-16 17:02           ` Felipe Balbi
2016-12-19  9:16             ` Jerry Huang
2016-12-19  9:19               ` Felipe Balbi

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=87bmwcf69h.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jerry.huang@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rajesh.bhagat@nxp.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;
as well as URLs for NNTP newsgroup(s).