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 19:02:00 +0200 [thread overview]
Message-ID: <8760mjq03b.fsf@linux.intel.com> (raw)
In-Reply-To: <DB5PR0401MB1813341E65ABDF44059E97DCFE9C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>
Hi,
Jerry Huang <jerry.huang@nxp.com> writes:
> 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.
that's not for burst increment, though.
>> >> 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.
interesting, it doesn't describe what happens to OCP or PCI.
> 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.
cool, thanks :-)
>> > 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
balbi
next prev parent reply other threads:[~2016-12-16 17:04 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
2016-12-16 17:02 ` Felipe Balbi [this message]
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=8760mjq03b.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).