From: Ran Wang <ran.wang_1@nxp.com>
To: Felipe Balbi <balbi@kernel.org>, Rob Herring <robh+dt@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list:DESIGNWARE USB3 DRD IP DRIVER"
<linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Leo Li <leoyang.li@nxp.com>
Subject: RE: [PATCH] usb: dwc3: Enable the USB snooping
Date: Mon, 24 Jun 2019 01:45:13 +0000 [thread overview]
Message-ID: <VE1PR04MB66557834D3588FC8B558950AF1E00@VE1PR04MB6655.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <87o92wgyqj.fsf@linux.intel.com>
Hi Felipe,
On Monday, June 17, 2019 20:53, Felipe Balbi wrote:
> Hi,
>
> Ran Wang <ran.wang_1@nxp.com> writes:
> > Hi Felipe,
> >
> > On Thursday, May 30, 2019 17:09, Ran Wang wrote:
> >>
> >> <snip>
> >> > >> >> > /* Global Debug Queue/FIFO Space Available Register */
> >> > >> >> > #define DWC3_GDBGFIFOSPACE_NUM(n) ((n) & 0x1f)
> >> > >> >> > #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
> >> > >> >> > @@ -859,6 +867,7 @@ struct dwc3_scratchpad_array {
> >> > >> >> > * 3 - Reserved
> >> > >> >> > * @imod_interval: set the interrupt moderation interval in 250ns
> >> > >> >> > * increments or 0 to disable.
> >> > >> >> > + * @dma_coherent: set if enable dma-coherent.
> >> > >> >>
> >> > >> >> you're not enabling dma coherency, you're enabling cache snooping.
> >> > >> >> And this property should describe that. Also, keep in mind
> >> > >> >> that different devices may want different cache types for
> >> > >> >> each of those fields, so your property would have to be a lot
> >> > >> >> more complex. Something
> >> > like:
> >> > >> >>
> >> > >> >> snps,cache-type = <foobar "cacheable">, <baz "cacheable">, ...
> >> > >> >>
> >> > >> >> Then driver would have to parse this properly to setup GSBUSCFG0.
> >> > >
> >> > > According to the DesignWare Cores SuperSpeed USB 3.0 Controller
> >> > > Databook (v2.60a), it has described Type Bit Assignments for all
> >> > > supported
> >> > master bus type:
> >> > > AHB, AXI3, AXI4 and Native. I found the bit definition are
> >> > > different among
> >> > them.
> >> > > So, for the example you gave above, feel a little bit confused.
> >> > > Did you mean:
> >> > > snps,cache-type = <DATA_RD "write allocate">, <DESC_RD
> >> > > "cacheable">, <DATA_WR "bufferable">, <DESC_WR "read allocate">
> >> >
> >> > yeah, something like that.
> >>
> >> I think DATA_RD should be a macro, right? So, where I can put its define?
> >> Create a dwc3.h in include/dt-bindings/usb/ ?
> >
> > Could you please give me some advice here? I'd like to prepare next
> > version patch after getting this settled.
> >
> >> Another question about this remain open is: DWC3 data book's Table
> >> 6-5 Cache Type Bit Assignments show that bits definition will differ
> >> per MBUS_TYPEs as
> >> below:
> >> ----------------------------------------------------------------
> >> 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
> >> ----------------------------------------------------------------
> >> Note: 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)
> >>
> >> For Layerscape SoCs, MBUS_TYPE is AXI3. So I am not sure how to use
> >> snps,cache-type = <DATA_RD "write allocate">, to cover all MBUS_TYPE?
> >> (you can notice that AHB and AXI3's cacheable are on different bit)
> >> Or I just need to handle AXI3 case?
> >
> > Also on this open. Thank you in advance.
>
> You could pass two strings and let the driver process them. Something
> like:
>
> snps,cache_type = <"data_wr" "write allocate">, <"desc_rd"
> "cacheable">...
>
> And so on. The only thing missing is for the mbus_type to be known by the driver.
> Is that something we can figure out on any of the HWPARAMS registers or does
> it have to be told explicitly?
I have checked Layerscape Reference manual, HWPARAMS0~8 doesn't contain mbus_type
Info, and I didn't know where have declared it explicitly.
> Another option would be to pass a string followed by one hex digit for the bits:
>
> snps,cache_type = <"data_wr" 0x8>, <"desc_rd" 0x2>...;
>
> Then we don't need to describe mbus_type since the bits are what matters.
Yes, it's also what we prefer to use, it will be more flexible, I can add above Table
6-5 Cache Type Bit Assignments in binding to help user decide which value they
would use.
I would submit another version of patch for further review, thank you very much.
Regards,
Ran
> Rob, any comments?
>
> --
> balbi
next prev parent reply other threads:[~2019-06-24 1:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20171115060459.45375-1-ran.wang_1@nxp.com>
[not found] ` <87ineb9b5v.fsf@linux.intel.com>
[not found] ` <VI1PR04MB1504776EF3D4D8C374F0C069F1290@VI1PR04MB1504.eurprd04.prod.outlook.com>
[not found] ` <87shdfet90.fsf@linux.intel.com>
2019-05-28 10:02 ` [PATCH] usb: dwc3: Enable the USB snooping Ran Wang
2019-05-28 10:19 ` Felipe Balbi
2019-05-29 10:12 ` Ran Wang
2019-05-29 10:24 ` Felipe Balbi
2019-05-30 2:17 ` Ran Wang
2019-05-30 9:08 ` Ran Wang
2019-06-03 2:33 ` Ran Wang
2019-06-17 12:52 ` Felipe Balbi
2019-06-24 1:45 ` Ran Wang [this message]
2019-06-24 5:58 ` Felipe Balbi
2019-07-09 7:55 ` Ran Wang
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=VE1PR04MB66557834D3588FC8B558950AF1E00@VE1PR04MB6655.eurprd04.prod.outlook.com \
--to=ran.wang_1@nxp.com \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=leoyang.li@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh+dt@kernel.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).