From: "Stanley Chang[昌育德]" <stanley_chang@realtek.com>
To: Krzysztof Kozlowski <krzk@kernel.org>, Rob Herring <robh+dt@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Felipe Balbi <balbi@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 2/2] dt-bindings: usb: snps,dwc3: Add 'snps,global-regs-starting-offset' quirk
Date: Fri, 14 Apr 2023 09:36:57 +0000 [thread overview]
Message-ID: <a8ceb3e4cae842118b805d92db0465bf@realtek.com> (raw)
In-Reply-To: <94db291f-6d93-548b-92ad-3a9f480783e2@kernel.org>
> On 13/04/2023 04:53, Stanley Chang[昌育德] wrote:
> >
> >>
> >> On Tue, Apr 11, 2023 at 10:30 PM Stanley Chang
> >> <stanley_chang@realtek.com> wrote:
> >>>
> >>> Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to
> >>> remap the global register start address
> >>>
> >>> The RTK DHC SoCs were designed the global register address offset at
> >>> 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
> >>> Therefore, add the property of device-tree to adjust this start address.
> >>>
> >>> Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
> >>> ---
> >>> Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >>> b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >>> index be36956af53b..5cbf3b7ded04 100644
> >>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> >>> @@ -359,6 +359,13 @@ properties:
> >>> items:
> >>> enum: [1, 4, 8, 16, 32, 64, 128, 256]
> >>>
> >>> + snps,global-regs-starting-offset:
> >>> + description:
> >>> + value for remapping global register start address. For some dwc3
> >>> + controller, the dwc3 global register start address is not at
> >>> + default DWC3_GLOBALS_REGS_START (0xc100). This property is
> >> added to
> >>> + adjust the address.
> >>
> >> We already have 'reg' or using a specific compatible to handle
> >> differences. Use one of those, not a custom property. Generally,
> >> properties should be used for things that vary per board, not fixed in a given
> SoC.
> >>
> >> Rob
> >>
> >
> > The default offset is fixed by macro DWC3_GLOBALS_REGS_START, and it is
> not specified by reg.
>
> Are you saying that reg points to XHCI registers and the gap between them and
> DWC3_GLOBALS_REGS_START is different on some implementations of this IP?
Yes.
> > The dwc3/core is a general driver for every dwc3 IP of SoCs, and
> > vendor's definition and compatible should specify on its parent.
>
> Not entirely. It's how currently it is written, but not necessarily correct
> representation. The parent is only glue part which for some non-IP resources.
I agree.
I think this offset belongs to the IP resource.
But it is fixed value on dwc3/core driver.
Therefore, I had to add this patch to adjust it.
> > If we add a specific compatible to dwc3/core driver, then it will break this
> rule.
>
> What rule? The rule is to have specific compatibles, so now you are breaking it.
>
I just don't want dwc3/core to look like a specific Realtek driver.
If I add compatible to our platform, then apply this offset.
For example,
@@ -2046,6 +2046,9 @@ static const struct of_device_id of_dwc3_match[] = {
{
.compatible = "synopsys,dwc3"
},
+ {
+ .compatible = "realtek,dwc3"
+ },
{ },
};
Why not use a property of the device tree to specify this offset?
It will be more general. Other vendor IPs can also use this option if desired.
For example,
@@ -123,7 +123,7 @@ port0_dwc3: dwc3_u2drd@98020000 {
compatible = "synopsys,dwc3", "syscon";
reg = <0x98020000 0x9000>;
interrupts = <0 95 4>;
+ snps,global-regs-starting-offset = <0x8100>;
usb-phy = <&dwc3_u2drd_usb2phy>;
dr_mode = "host";
snps,dis_u2_susphy_quirk;
next prev parent reply other threads:[~2023-04-14 9:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230412033006.10859-1-stanley_chang@realtek.com>
[not found] ` <20230412033006.10859-2-stanley_chang@realtek.com>
[not found] ` <955cc334-eaac-5880-51cf-8ab171f0ef48@kernel.org>
2023-04-12 11:11 ` [PATCH v2 2/2] dt-bindings: usb: snps,dwc3: Add 'snps,global-regs-starting-offset' quirk Stanley Chang[昌育德]
2023-04-12 14:13 ` Krzysztof Kozlowski
[not found] ` <CAL_JsqLqTHbHjB1qiLduhzvTaO7EBMgL6KYqZJtgStGVGtX1vQ@mail.gmail.com>
2023-04-13 2:53 ` Stanley Chang[昌育德]
2023-04-14 9:08 ` Krzysztof Kozlowski
2023-04-14 9:36 ` Stanley Chang[昌育德] [this message]
2023-04-13 4:25 ` Stanley Chang
2023-04-13 7:32 ` Krzysztof Kozlowski
2023-04-13 14:58 ` Stanley Chang[昌育德]
2023-04-13 16:36 ` Krzysztof Kozlowski
2023-04-14 2:12 ` Stanley Chang[昌育德]
2023-04-14 9:05 ` Krzysztof Kozlowski
2023-04-13 13:00 ` 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=a8ceb3e4cae842118b805d92db0465bf@realtek.com \
--to=stanley_chang@realtek.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzk@kernel.org \
--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).