From: balbi@kernel.org (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
Date: Tue, 17 Jan 2017 12:45:19 +0200 [thread overview]
Message-ID: <8737gikls0.fsf@linux.intel.com> (raw)
In-Reply-To: <DB5PR0401MB1813548526D3C8D34B9CCE52FE7C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>
Hi,
Jerry Huang <jerry.huang@nxp.com> writes:
<snip>
>> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
>> >> burst type.
>> > Hi, Balbi,
>> > It seems there is no feedback for my comment, so these patches can be
>> accepted?
>>
>> probably not, we need to really understand what information we need so it
>> can be described properly. The last thing we want is unnecessary DT
>> properties.
>>
>> It seems to me that we can extrapolate INCRBrstEna based on which burst
>> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
>> other size is passed, then that bit should be 0, no?
> Hi, Balbi,
> Below is the definition for this property,
> snps,incr-burst-type-adjustment = <x>, <y>
> x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> 0 - INCRX burst mode (not enable INCRBrstEna)
> 1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> y: the burst length
>
> 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> it) , we select one of
> INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> value through "y")to set the fix burst length controller supported.
>
> For example:
>
> snps,incr-burst-type-adjustment = <0>, <16>
>
> driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
>
> 2> if x = 1: means INCRBrstEna enabled, we select one of
> INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> through "y") to set the burst length, and controller will use any
> length less than or equal to that we selected.
>
> For example:
>
> snps,incr-burst-type-adjustment = <1>, <32>
>
> driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> Enabled), controller will use any burst length less than (such as 4,
> 8, 16 byte) or equal to 32 byte to transfer data.
>
> Therefore, I think this two fileds are needed. Do you think about it?
no, I don't think two values are needed, because first value can be
extrapolated from the second. Something like this:
snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
This is basically telling us that we can support anything in this
list. So INCRBrstEna should be set to 1.
If DT, on the other hand, says:
snps,incr-burst-type-adjustment = <32>;
this means that we can only support INCR32, so INCRBrstEna should be
cleared to 0.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170117/596669fd/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Jerry Huang <jerry.huang@nxp.com>, Rob Herring <robh@kernel.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
Date: Tue, 17 Jan 2017 12:45:19 +0200 [thread overview]
Message-ID: <8737gikls0.fsf@linux.intel.com> (raw)
In-Reply-To: <DB5PR0401MB1813548526D3C8D34B9CCE52FE7C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
Hi,
Jerry Huang <jerry.huang@nxp.com> writes:
<snip>
>> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
>> >> burst type.
>> > Hi, Balbi,
>> > It seems there is no feedback for my comment, so these patches can be
>> accepted?
>>
>> probably not, we need to really understand what information we need so it
>> can be described properly. The last thing we want is unnecessary DT
>> properties.
>>
>> It seems to me that we can extrapolate INCRBrstEna based on which burst
>> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
>> other size is passed, then that bit should be 0, no?
> Hi, Balbi,
> Below is the definition for this property,
> snps,incr-burst-type-adjustment = <x>, <y>
> x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> 0 - INCRX burst mode (not enable INCRBrstEna)
> 1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> y: the burst length
>
> 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> it) , we select one of
> INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> value through "y")to set the fix burst length controller supported.
>
> For example:
>
> snps,incr-burst-type-adjustment = <0>, <16>
>
> driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
>
> 2> if x = 1: means INCRBrstEna enabled, we select one of
> INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> through "y") to set the burst length, and controller will use any
> length less than or equal to that we selected.
>
> For example:
>
> snps,incr-burst-type-adjustment = <1>, <32>
>
> driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> Enabled), controller will use any burst length less than (such as 4,
> 8, 16 byte) or equal to 32 byte to transfer data.
>
> Therefore, I think this two fileds are needed. Do you think about it?
no, I don't think two values are needed, because first value can be
extrapolated from the second. Something like this:
snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
This is basically telling us that we can support anything in this
list. So INCRBrstEna should be set to 1.
If DT, on the other hand, says:
snps,incr-burst-type-adjustment = <32>;
this means that we can only support INCR32, so INCRBrstEna should be
cleared to 0.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Jerry Huang <jerry.huang@nxp.com>, Rob Herring <robh@kernel.org>
Cc: "mark.rutland\@arm.com" <mark.rutland@arm.com>,
"catalin.marinas\@arm.com" <catalin.marinas@arm.com>,
"will.deacon\@arm.com" <will.deacon@arm.com>,
"linux\@armlinux.org.uk" <linux@armlinux.org.uk>,
"devicetree\@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel\@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
Date: Tue, 17 Jan 2017 12:45:19 +0200 [thread overview]
Message-ID: <8737gikls0.fsf@linux.intel.com> (raw)
In-Reply-To: <DB5PR0401MB1813548526D3C8D34B9CCE52FE7C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
Hi,
Jerry Huang <jerry.huang@nxp.com> writes:
<snip>
>> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
>> >> burst type.
>> > Hi, Balbi,
>> > It seems there is no feedback for my comment, so these patches can be
>> accepted?
>>
>> probably not, we need to really understand what information we need so it
>> can be described properly. The last thing we want is unnecessary DT
>> properties.
>>
>> It seems to me that we can extrapolate INCRBrstEna based on which burst
>> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
>> other size is passed, then that bit should be 0, no?
> Hi, Balbi,
> Below is the definition for this property,
> snps,incr-burst-type-adjustment = <x>, <y>
> x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> 0 - INCRX burst mode (not enable INCRBrstEna)
> 1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> y: the burst length
>
> 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> it) , we select one of
> INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> value through "y")to set the fix burst length controller supported.
>
> For example:
>
> snps,incr-burst-type-adjustment = <0>, <16>
>
> driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
>
> 2> if x = 1: means INCRBrstEna enabled, we select one of
> INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> through "y") to set the burst length, and controller will use any
> length less than or equal to that we selected.
>
> For example:
>
> snps,incr-burst-type-adjustment = <1>, <32>
>
> driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> Enabled), controller will use any burst length less than (such as 4,
> 8, 16 byte) or equal to 32 byte to transfer data.
>
> Therefore, I think this two fileds are needed. Do you think about it?
no, I don't think two values are needed, because first value can be
extrapolated from the second. Something like this:
snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
This is basically telling us that we can support anything in this
list. So INCRBrstEna should be set to 1.
If DT, on the other hand, says:
snps,incr-burst-type-adjustment = <32>;
this means that we can only support INCR32, so INCRBrstEna should be
cleared to 0.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-01-17 10:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 9:25 [PATCH v3 1/3] USB3/DWC3: Add definition for global soc bus configuration register Changming Huang
2016-12-19 9:25 ` Changming Huang
2016-12-19 9:25 ` Changming Huang
2016-12-19 9:25 ` [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type Changming Huang
2016-12-19 9:25 ` [PATCH v3 2/3] USB3/DWC3: Add property "snps,incr-burst-type-adjustment" " Changming Huang
2016-12-19 9:25 ` [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" " Changming Huang
2016-12-22 18:45 ` Rob Herring
2016-12-22 18:45 ` Rob Herring
2016-12-23 2:52 ` Jerry Huang
2016-12-23 2:52 ` Jerry Huang
2016-12-23 2:52 ` Jerry Huang
2017-01-03 21:23 ` Rob Herring
2017-01-03 21:23 ` Rob Herring
2017-01-03 21:23 ` Rob Herring
2017-01-04 2:24 ` Jerry Huang
2017-01-04 2:24 ` Jerry Huang
2017-01-04 2:24 ` Jerry Huang
2017-01-21 20:21 ` Rob Herring
2017-01-21 20:21 ` Rob Herring
2017-01-21 20:21 ` Rob Herring
2017-02-10 15:16 ` Jerry Huang
2017-02-10 15:16 ` Jerry Huang
2017-02-10 15:16 ` Jerry Huang
2017-01-16 8:15 ` Jerry Huang
2017-01-16 8:15 ` Jerry Huang
2017-01-16 8:15 ` Jerry Huang
2017-01-16 8:50 ` Felipe Balbi
2017-01-16 8:50 ` Felipe Balbi
2017-01-16 8:50 ` Felipe Balbi
2017-01-17 10:37 ` Jerry Huang
2017-01-17 10:37 ` Jerry Huang
2017-01-17 10:37 ` Jerry Huang
2017-01-17 10:45 ` Felipe Balbi [this message]
2017-01-17 10:45 ` Felipe Balbi
2017-01-17 10:45 ` Felipe Balbi
2017-01-17 11:08 ` Jerry Huang
2017-01-17 11:08 ` Jerry Huang
2017-01-17 11:08 ` Jerry Huang
2016-12-19 9:25 ` [PATCH v3 3/3] USB3/DWC3: Enable undefined length " Changming Huang
2016-12-19 9:25 ` Changming Huang
2016-12-19 9:25 ` Changming Huang
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=8737gikls0.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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 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.