From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Keguang Zhang <keguang.zhang@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Binbin Zhou <zhoubb.aaron@gmail.com>,
Conor Dooley <conor@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Conor Dooley <conor.dooley@microchip.com>,
Binbin Zhou <zhoubinbin@loongson.cn>,
Alessandro Zummo <a.zummo@towertech.it>,
linux-rtc@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, Huacai Chen <chenhuacai@loongson.cn>,
Huacai Chen <chenhuacai@kernel.org>,
Xuerui Wang <kernel@xen0n.name>,
loongarch@lists.linux.dev,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
zhao zhang <zhzhl555@gmail.com>, Yang Ling <gnaygnil@gmail.com>,
loongson-kernel@lists.loongnix.cn
Subject: Re: [PATCH V4 1/5] dt-bindings: rtc: Remove the LS2X from the trivial RTCs
Date: Tue, 30 May 2023 11:22:00 +0200 [thread overview]
Message-ID: <2023053009220055969681@mail.local> (raw)
In-Reply-To: <CAJhJPsXyS_+tTLJ1JSCNx6wXs8eGwwQ4khg=-0gRGZuJRDddoQ@mail.gmail.com>
On 30/05/2023 17:13:12+0800, Keguang Zhang wrote:
> On Tue, May 30, 2023 at 4:40 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 30/05/2023 10:17:43+0200, Krzysztof Kozlowski wrote:
> > > On 29/05/2023 10:31, Binbin Zhou wrote:
> > > > Hi Krzysztof:
> > > >
> > > > Excuse me.
> > > > We have different opinions on how to better describe rtc-loongson compatible.
> > > >
> > > > Based on my previous communication with you, I think we should list
> > > > all the Socs in the driver and drop the wildcards.
> > >
> > > Suggestion was about the bindings. Not in the driver. I never said to
> > > list all compatibles in the driver...
> > >
> > > > This should be clearer and more straightforward:
> > > >
> > > > { .compatible = "loongson,ls1b-rtc", .data = &ls1x_rtc_config
> > > > }, //ls1b soc
> > > > { .compatible = "loongson,ls1c-rtc", .data = &ls1x_rtc_config
> > > > }, //ls1c soc
> > > > { .compatible = "loongson,ls7a-rtc", .data =
> > > > &generic_rtc_config }, //ls7a bridge chip
> > > > { .compatible = "loongson,ls2k0500-rtc", .data =
> > > > &generic_rtc_config }, // ls2k0500 soc
> > > > { .compatible = "loongson,ls2k2000-rtc", .data =
> > > > &generic_rtc_config }, // ls2k2000 soc
> > > > { .compatible = "loongson,ls2k1000-rtc", .data =
> > > > &ls2k1000_rtc_config }, // ls2k1000 soc
> > >
> > > I would suggest to use fallbacks as suggested by Conor at least for some
> > > of them. You referred to my previous comments about wildcards.
> > > Wildcard != fallback.
> > >
> > > >
> > > > And Conor thought it should be rendered using a fallback compatible
> > > > form based on ".data".
> > >
> > > Based on common (compatible) programming model unless you already have
> > > clear hardware differences making them incompatible.
> > >
> > > >
> > > > "loongson,ls1b-rtc"
> > > > "loongson,ls1c-rtc", "loongson,ls1b-rtc"
> > > > "loongson,ls7a-rtc"
> > > > "loongson,ls2k0500-rtc", "loongson,ls7a-rtc"
> > > > "longson,ls2k2000-rtc", "longson,ls7a-rtc"
> > > > "loonson,ls2k1000-rtc"
> > > >
> > > > { .compatible = "loongson,ls1b-rtc", .data = &ls1x_rtc_config }
> > > > { .compatible = "loongson,ls7a-rtc", .data = &generic_rtc_config }
> > > > { .compatible = "loongson,ls2k1000-rtc", .data = &ls2k1000_rtc_config }
> > > >
> > > > In this form, I think it might not be possible to show very
> > > > graphically which chips are using the driver.
> > >
> > > ??? How is it impossible? For all other SoCs and architectures it is
> > > possible, so what is special for Loongson?
> > >
> > > > Also, for example, "ls7a" is a bridge chip, while
> > > > "ls2k2000"/"ls2k0500" are soc chips, and it seems inappropriate to
> > > > integrate them into one item.
> > >
> > > Why it is inappropriate? I don't see the issue here... what is a
> > > "bridge" chip? Isn't this also an SoC?
> > >
> > >
> > > >
> > > > Which one do you think is more suitable for us?
> > >
> > > Use fallbacks for some. You pointed difference in alarm for ls1x, right?
> > > If so, then they can stay separate.
> >
> > From what I seen the IP and register set is the same, it is just the
> > integration on the SoC that differs.
> >
> Actually, ls1c RTC registers are not the same as ls1b.
> ls1c doesn't have the following resgisters.
> +#define TOY_MATCH0_REG 0x34 /* TOY timing interrupt 0 */
> +#define TOY_MATCH1_REG 0x38 /* TOY timing interrupt 1 */
> +#define TOY_MATCH2_REG 0x3c /* TOY timing interrupt 2 */
>
> +#define RTC_CTRL_REG 0x40 /* TOY and RTC control register */
> +#define RTC_TRIM_REG 0x60 /* Must be initialized to 0 */
> +#define RTC_WRITE0_REG 0x64 /* RTC counters value (write-only) */
> +#define RTC_READ0_REG 0x68 /* RTC counters value (read-only) */
> +#define RTC_MATCH0_REG 0x6c /* RTC timing interrupt 0 */
> +#define RTC_MATCH1_REG 0x70 /* RTC timing interrupt 1 */
> +#define RTC_MATCH2_REG 0x74 /* RTC timing interrupt 2 */
>
> As you can see, it doesn't support match function, which is why ls1c
> doesn't support RTC interrupt.
They are in the Loongson1C Processor User Manual I have which states:
21.2.6 SYS_TOYMATCH0/1/2 (no register in 1C2)
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-05-30 9:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 12:55 [PATCH V4 0/5] rtc: Add rtc driver for the Loongson family chips Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 1/5] dt-bindings: rtc: Remove the LS2X from the trivial RTCs Binbin Zhou
2023-05-25 17:05 ` Conor Dooley
2023-05-26 1:37 ` Binbin Zhou
2023-05-26 12:06 ` Conor Dooley
2023-05-26 12:22 ` Jiaxun Yang
2023-05-26 12:38 ` Conor Dooley
2023-05-27 9:22 ` Binbin Zhou
2023-05-27 16:13 ` Jiaxun Yang
2023-05-27 16:23 ` Conor Dooley
2023-05-27 21:59 ` Jiaxun Yang
2023-05-27 22:22 ` Conor Dooley
2023-05-29 2:59 ` Keguang Zhang
2023-05-29 6:24 ` Conor Dooley
2023-05-29 8:31 ` Binbin Zhou
2023-05-29 22:20 ` Alexandre Belloni
2023-05-30 6:41 ` Binbin Zhou
2023-05-30 8:17 ` Krzysztof Kozlowski
2023-05-30 8:40 ` Alexandre Belloni
2023-05-30 9:13 ` Keguang Zhang
2023-05-30 9:22 ` Alexandre Belloni [this message]
2023-05-30 9:49 ` Keguang Zhang
2023-05-30 11:39 ` Binbin Zhou
2023-05-30 12:02 ` Alexandre Belloni
2023-05-25 12:55 ` [PATCH V4 2/5] rtc: Remove the Loongson-1 RTC driver Binbin Zhou
2023-05-30 8:08 ` Krzysztof Kozlowski
2023-05-30 8:39 ` Alexandre Belloni
2023-05-25 12:55 ` [PATCH V4 3/5] rtc: Add rtc driver for the Loongson family chips Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 4/5] MIPS: Loongson64: DTS: Add RTC support to LS7A PCH Binbin Zhou
2023-05-25 12:55 ` [PATCH V4 5/5] MIPS: Loongson64: DTS: Add RTC support to Loongson-2K1000 Binbin Zhou
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=2023053009220055969681@mail.local \
--to=alexandre.belloni@bootlin.com \
--cc=a.zummo@towertech.it \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gnaygnil@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=keguang.zhang@gmail.com \
--cc=kernel@xen0n.name \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=loongson-kernel@lists.loongnix.cn \
--cc=robh+dt@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=zhoubb.aaron@gmail.com \
--cc=zhoubinbin@loongson.cn \
--cc=zhzhl555@gmail.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;
as well as URLs for NNTP newsgroup(s).