linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jerry Huang <jerry.huang@nxp.com>
To: Felipe Balbi <balbi@kernel.org>,
	"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 16:18:56 +0000	[thread overview]
Message-ID: <DB5PR0401MB1813341E65ABDF44059E97DCFE9C0@DB5PR0401MB1813.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <87bmwcf69h.fsf@linux.intel.com>


Hi, Balbi,
> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@kernel.org]
> Sent: Friday, December 16, 2016 7:44 PM
> To: Jerry Huang <jerry.huang@nxp.com>; gregkh@linuxfoundation.org
> Cc: linux-usb@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
> 
> 
> 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 :-)
I think "snps,quirk-frame-length-adjustment" is one good reference, which can pass the required value to driver from DTS file.

> >> 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.
When bit0 = 1 (Undefined Length INCR Burst Type Enable), which means:
 1: INCR (undefined length) burst mode
- AHB configurations: HBURST uses SINGLE or INCR
of any length less than or equal to the largest-enabled
burst length of INCR4/8/16/32/64/128/256.
- AXI configurations: ARLEN/AWLEN uses any length
less than or equal to the largest-enabled burst length
of INCR4/8/16/32/64/128/256.
So, after enable undefined length INCR burst and enable INCR16, controller will use less than or equal to 16byte.

> 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?
I will check it with IP designer.

> > 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

  reply	other threads:[~2016-12-16 16:19 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
2016-12-16 16:18         ` Jerry Huang [this message]
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=DB5PR0401MB1813341E65ABDF44059E97DCFE9C0@DB5PR0401MB1813.eurprd04.prod.outlook.com \
    --to=jerry.huang@nxp.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --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).