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