Linux USB
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@nxp.com>
To: Conor Dooley <conor@kernel.org>
Cc: thinh.nguyen@synopsys.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	balbi@kernel.org, devicetree@vger.kernel.org,
	gregkh@linuxfoundation.org, imx@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	mark.rutland@arm.com, mathias.nyman@intel.com, pku.leo@gmail.com,
	sergei.shtylyov@cogentembedded.com
Subject: Re: [PATCH 1/2] dt-bindings: usb: dwc3: Add system bus request info
Date: Tue, 23 Jan 2024 14:22:36 -0500	[thread overview]
Message-ID: <ZbAR/NQvjUnf2At+@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <20240123-nanometer-atlantic-6465b270043a@spud>

On Tue, Jan 23, 2024 at 06:42:27PM +0000, Conor Dooley wrote:
> On Tue, Jan 23, 2024 at 01:02:21PM -0500, Frank Li wrote:
> > On Tue, Jan 23, 2024 at 05:51:48PM +0000, Conor Dooley wrote:
> > > On Tue, Jan 23, 2024 at 12:49:27PM -0500, Frank Li wrote:
> > > > On Tue, Jan 23, 2024 at 05:27:13PM +0000, Conor Dooley wrote:
> > > > > On Tue, Jan 23, 2024 at 12:02:05PM -0500, Frank Li wrote:
> > > > > > Add device tree binding allow platform overwrite default value of *REQIN in
> > > > > > GSBUSCFG0.
> > > > > 
> > > > > Why might a platform actually want to do this? Why does this need to be
> > > > > set at the board level and being aware of which SoC is in use is not
> > > > > sufficient for the driver to set the correct values?
> > > > 
> > > > In snps,dwc3.yaml, there are already similary proptery, such as
> > > > snps,incr-burst-type-adjustment. Use this method can keep whole dwc3 usb
> > > > driver keep consistent. And not all platform try enable hardware
> > > > dma_cohenrence. It is configable for difference platform.
> > > 
> > > When you say "platform", what do you mean? I understand that term to
> > > mean a combination of board, soc and firmware.
> > 
> > In my company's environment, "platform" is "board". I will use "board" in
> > future. Is it big difference here?
> 
> Nah, that's close enough that it makes no difference here.
> 
> I'd still like an explanation for why a platform would need to actually
> set these properties though, and why information about coherency cannot
> be determined from whether or not the boss the usb controller is on is
> communicated to be dma coherent via the existing devicetree properties
> for that purpose.

Actually, I am not very clear about reason. I guest maybe treat off power
consumption and performance.

What's your judgement about proptery, which should be in dts. Such as
reg, clk, reset, dma and irq, which is tighted with SOC. It is the fixed
value for every SOC. The board dts never change these.

But for this "snps,*-reqinfo", you don't like put into dts? 

There are similar case at 2019,
https://lore.kernel.org/linux-devicetree/CADRPPNRHOda+ZfB25CeqReXBb-MrB1oAeTHF-3muXVExn+G+Dg@mail.gmail.com/
look like, this thread prefer quirk proptery method.

Frank

> 
> Thanks,
> Conor.
> 
> > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/usb/snps,dwc3.yaml    | 36 +++++++++++++++++++
> > > > > >  1 file changed, 36 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > index 8f5d250070c78..43e7fea3f6798 100644
> > > > > > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > > > @@ -439,6 +439,42 @@ properties:
> > > > > >      items:
> > > > > >        enum: [1, 4, 8, 16, 32, 64, 128, 256]
> > > > > >  
> > > > > > +  snps,des-wr-reqinfo:
> > > > > > +    description: Value for DESEWRREQIN of GSBUSCFG0 register.
> > > > > > +      ----------------------------------------------------------------
> > > > > > +       MBUS_TYPE| bit[3]       |bit[2]       |bit[1]     |bit[0]
> > > > > > +      ----------------------------------------------------------------
> > > > > > +       AHB      |Cacheable     |Bufferable   |Privilegge |Data
> > > > > > +       AXI3     |Write Allocate|Read Allocate|Cacheable  |Bufferable
> > > > > > +       AXI4     |Allocate Other|Allocate     |Modifiable |Bufferable
> > > > > > +       AXI4     |Other Allocate|Allocate     |Modifiable |Bufferable
> > > > > > +       Native   |Same as AXI   |Same as AXI  |Same as AXI|Same as AXI
> > > > > > +      ----------------------------------------------------------------
> > > > > > +      The AHB, AXI3, AXI4, and PCIe busses use different names for certain
> > > > > > +      signals, which have the same meaning:
> > > > > > +      Bufferable = Posted
> > > > > > +      Cacheable = Modifiable = Snoop (negation of No Snoop)
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > > > > +    maxItem: 15
> > > > > > +
> > > > > > +  snps,des-rd-reqinfo:
> > > > > > +    description: Value for DESRDREQIN of GSBUSCFG0 register. ref
> > > > > > +      snps,des-wr-reqinfo
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > > > > +    maxItem: 15
> > > > > > +
> > > > > > +  snps,dat-wr-reqinfo:
> > > > > > +    description: Value for DATWRREQIN of GSBUSCFG0 register. ref
> > > > > > +      snps,des-wr-reqinfo
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > > > > +    maxItem: 15
> > > > > > +
> > > > > > +  snps,des-wr-reqinfo:
> > > > > > +    description: Value for DATWRREQIN of GSBUSCFG0 register. ref
> > > > > > +      snps,des-wr-reqinfo
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint8
> > > > > > +    maxItem: 15
> > > > > > +
> > > > > >    num-hc-interrupters:
> > > > > >      maximum: 8
> > > > > >      default: 1
> > > > > > -- 
> > > > > > 2.34.1
> > > > > > 
> > > > 
> > > > 
> > 
> > 



  reply	other threads:[~2024-01-23 19:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 17:02 [PATCH 1/2] dt-bindings: usb: dwc3: Add system bus request info Frank Li
2024-01-23 17:02 ` [PATCH 2/2] usb: dwc3: core: allow overwrite reqinfo in GSBUSCFG0 by dts Frank Li
2024-01-23 17:27 ` [PATCH 1/2] dt-bindings: usb: dwc3: Add system bus request info Conor Dooley
2024-01-23 17:49   ` Frank Li
2024-01-23 17:51     ` Conor Dooley
2024-01-23 18:02       ` Frank Li
2024-01-23 18:42         ` Conor Dooley
2024-01-23 19:22           ` Frank Li [this message]
2024-01-23 21:46             ` Krzysztof Kozlowski
2024-01-23 22:23               ` Frank Li
2024-01-29 15:19                 ` Frank Li
2024-01-29 16:49                   ` Conor Dooley
2024-01-29 17:41                     ` Frank Li
2024-01-30  7:40                       ` Krzysztof Kozlowski
2024-01-30 15:20                         ` Frank Li
2024-01-30 16:10                           ` Krzysztof Kozlowski
2024-02-08 21:20                             ` Frank Li
2024-02-09  7:31                               ` Krzysztof Kozlowski
2024-01-23 18:37 ` Rob Herring

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=ZbAR/NQvjUnf2At+@lizhi-Precision-Tower-5810 \
    --to=frank.li@nxp.com \
    --cc=balbi@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=imx@lists.linux.dev \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathias.nyman@intel.com \
    --cc=pku.leo@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=thinh.nguyen@synopsys.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