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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.