From: "Andreas Färber" <afaerber@suse.de>
To: James Tai <james.tai@realtek.com>
Cc: "linux-realtek-soc@lists.infradead.org"
<linux-realtek-soc@lists.infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes
Date: Tue, 19 Nov 2019 09:34:46 +0100 [thread overview]
Message-ID: <ed7c483d-b518-c74f-f66d-a812d0858f4c@suse.de> (raw)
In-Reply-To: <20b3d0956bed4338a540216df07f16e5@realtek.com>
Hi James,
Adding Philipp.
Am 18.11.19 um 10:22 schrieb James Tai:
>> + reset1: reset-controller@0 {
>> + compatible = "snps,dw-low-reset";
>> + reg = <0x0 0x4>;
>> + #reset-cells = <1>;
>> + };
>> +
>> + reset2: reset-controller@4 {
>> + compatible = "snps,dw-low-reset";
>> + reg = <0x4 0x4>;
>> + #reset-cells = <1>;
>> + };
>> +
>> + reset3: reset-controller@8 {
>> + compatible = "snps,dw-low-reset";
>> + reg = <0x8 0x4>;
>> + #reset-cells = <1>;
>> + };
>> +
>> + iso_reset: reset-controller@7088 {
>> + compatible = "snps,dw-low-reset";
>> + reg = <0x7088 0x4>;
>> + #reset-cells = <1>;
>> + };
>> +
>
> We don't use the DesignWare IP for the reset controller.
Thanks for reviewing.
We already merged the equivalent nodes for RTD129x into arm-soc.git.
No Realtek review was received back when it was posted [1], sadly.
How does your reset controller differ from DesignWare, and how would you
prefer to handle it?
a) Do you want to send patches for a new Realtek-specific dt-binding [2]
and extend reset-simple driver to cover it as a copy&paste of the
DesignWare of_device_id?
b) Do you believe you need to submit a completely new reset driver?
An issue I had raised twice [4, 1] was that reset-simple only allows for
contiguous registers and thus couldn't handle the gap between reset3 and
reset4 on RTD1295, forcing me to use per-register nodes for consistency.
I am against modeling RTD1195 differently from RTD1295+, assuming
they're the equivalent IP, so we need a solution that works for both.
Philipp did indicate in [4] we could extend reset-simple for this gap
"if the implementation could be kept reasonably simple".
With v5.4-rc8 already tagged, please hurry if you want a different
binding in v5.5.
Regards,
Andreas
[1] https://patchwork.kernel.org/cover/11206255/
[2] https://patchwork.kernel.org/patch/9902665/
[3] https://patchwork.kernel.org/patch/9902673/
[4] https://patchwork.kernel.org/patch/9902675/
[5] https://patchwork.kernel.org/patch/9902671/
[6] https://patchwork.kernel.org/patch/9902663/
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
next prev parent reply other threads:[~2019-11-19 8:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-17 7:21 [PATCH v3 0/8] ARM: Initial RTD1195 and MeLE X1000 support Andreas Färber
2019-11-17 7:21 ` [PATCH v3 1/8] dt-bindings: arm: realtek: Add RTD1195 and MeLE X1000 Andreas Färber
2019-11-17 7:21 ` [PATCH v3 3/8] ARM: dts: Prepare Realtek " Andreas Färber
2019-11-17 10:47 ` Marc Zyngier
2019-11-17 15:40 ` Andreas Färber
2019-11-17 16:22 ` Marc Zyngier
2019-11-18 1:24 ` Andreas Färber
2019-11-18 9:14 ` Marc Zyngier
2019-11-17 7:21 ` [PATCH v3 4/8] ARM: dts: rtd1195: Introduce r-bus Andreas Färber
2019-11-17 7:21 ` [PATCH v3 5/8] dt-bindings: reset: Add Realtek RTD1195 Andreas Färber
2019-11-17 7:21 ` [PATCH v3 6/8] ARM: dts: rtd1195: Add reset nodes Andreas Färber
2019-11-18 9:22 ` James Tai
2019-11-19 8:34 ` Andreas Färber [this message]
2019-11-20 6:53 ` James Tai
2019-11-17 7:21 ` [PATCH v3 7/8] ARM: dts: rtd1195: Add UART resets Andreas Färber
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=ed7c483d-b518-c74f-f66d-a812d0858f4c@suse.de \
--to=afaerber@suse.de \
--cc=devicetree@vger.kernel.org \
--cc=james.tai@realtek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-realtek-soc@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--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).