linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 08/10] Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc
Date: Fri, 14 Aug 2015 12:02:37 +0200	[thread overview]
Message-ID: <1439546557.13210.52.camel@pengutronix.de> (raw)
In-Reply-To: <20150814084050.GE11072@shlinux2>

Am Freitag, den 14.08.2015, 16:40 +0800 schrieb Peter Chen:
> On Fri, Aug 14, 2015 at 10:37:30AM +0200, Lucas Stach wrote:
> > Am Freitag, den 07.08.2015, 15:15 +0800 schrieb Peter Chen:
> > > It is used to override the default setting for burst size, changing
> > > burst size takes effect only when the SBUSCFG.AHBBRST = 0.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > > ---
> > >  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > index d52a747..d71ef07 100644
> > > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > @@ -37,6 +37,14 @@ Optional properties:
> > >    property is used to change AHB burst configuration, check the chipidea
> > >    spec for meaning of each value. If this property is not existed, it
> > >    will use the reset value.
> > > +- tx-burst-size-dword: it is vendor dependent, the tx burst size in dword
> > > +  (4 bytes), This register represents the maximum length of a the burst
> > > +  in 32-bit words while moving data from system memory to the USB
> > > +  bus, changing this value takes effect only the SBUSCFG.AHBBRST is 0.
> > 
> > The last bits about SBUSCFG.AHBBRST don't make any sense in the DT
> > binding. The DT writer doesn't know about the SBUSCFG.AHBBRST value and
> > should not care either.
> > If someone sets the burst size to something
> > non-standard in the DT, the driver should make sure to enable to
> > necessary bits to make this setting take effect.
> 
> The SBUSCFG.AHBBRST property description is just above this one,
> and the user should read the spec for changing these system
> configuration parameters.
> 
This is not clear from the description. This should read something like
"The value of this property will only take effect if property
ahb-burst-config is set to 0."

The DT binding should be coherent and understandable without reading the
DW USB spec and/or the code. Please take some care about this.

> This requirement is from the spec, and the code logic makes sure
> the burst size changes only when SBUSCFG.AHBBRST is 0, since the
> hardware will only change burst size if SBUSCFG.AHBBRST is 0.
> 
> > 
> > Also both those descriptions are missing a description to what value the
> > burst sizes will be set if the DT properties are not found. If it's
> > implementation defined spell this out in the doc.
> 
> It is optional property, if without this property, it will use the
> default value.
> 
Then specify this in the binding. Again, the binding is a spec that one
should be able to understand without reading the code.

"If this property is missing the reset defaults of the hardware
implementation will be used."

> > 
> > Are there really cases where it makes sense to set RX and TX burst sizes
> > to different values?
> 
> Yes, the default burst size is the same for all SoCs, but the bus
> burst size may be larger for some SoCs.
> 
This question wasn't meant to dispute the RX/TX burst size
configuration, but I'm questioning if it really makes sense to set them
to different values. Do we really need 2 properties for this, or is 1
enough?

Do you see any use case where someone would like to do something like:
tx-burst-size-dword = <0x8>;
rx-burst-size-dword = <0x10>;

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

  reply	other threads:[~2015-08-14 10:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07  7:15 [PATCH v3 00/10] USB: chipidea misc patches Peter Chen
2015-08-07  7:15 ` [PATCH v3 01/10] usb: chipidea: udc: zero-length packet is only needed for TX Peter Chen
2015-08-07  7:15 ` [PATCH v3 02/10] usb: chipidea: define stream mode disable for both roles Peter Chen
2015-08-07  7:15 ` [PATCH v3 03/10] usb: chipidea: imx: add stream mode enable for device mode at imx6sl/imx6sx Peter Chen
2015-08-07  7:15 ` [PATCH v3 04/10] Doc: usb: ci-hdrc-usb2: add ahb-burst-config for binding doc Peter Chen
2015-08-07  7:15 ` [PATCH v3 05/10] ARM: imx6: set ahb-burst-config as 0 for USB Peter Chen
2015-08-07  7:15 ` [PATCH v3 06/10] usb: chipidea: add ahb burst configuration interface Peter Chen
2015-08-07  7:15 ` [PATCH v3 07/10] usb: chipidea: usbmisc_imx: add non-burst setting for imx6 Peter Chen
2015-08-07  7:15 ` [PATCH v3 08/10] Doc: usb: ci-hdrc-usb2: add tx(rx)-burst-config-dword for binding doc Peter Chen
2015-08-14  8:37   ` Lucas Stach
2015-08-14  8:40     ` Peter Chen
2015-08-14 10:02       ` Lucas Stach [this message]
2015-10-08  6:26         ` Peter Chen
2015-08-07  7:15 ` [PATCH v3 09/10] ARM: imx6: change default burst size for USB Peter Chen
2015-08-07  7:15 ` [PATCH v3 10/10] usb: chipidea: add tx/rx burst size configuration interface Peter Chen
2015-08-14  3:13 ` [PATCH v3 00/10] USB: chipidea misc patches Peter Chen

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=1439546557.13210.52.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --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 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).