On Tue, May 30, 2023 at 4:17 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> 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?
>
Hi Krzysztof:
LS7A bridge chip can be considered as a combination of South and North
bridge. Generally, it will be connected to the Loongson-3 series CPUs.
LS2K500/LS2K1000/LS2K2000 refers to the LS2K series embedded CPU chip.
Therefore, from the understanding of the driver code, I don't think it
is appropriate to fallback them together. Please pardon me if this
view does not apply to dt-binding.
If fallback is necessary, can we have this:
Let ls7a remain a separate item.
"loongson,ls1b-rtc"
"loongson,ls1c-rtc", "loongson,ls1b-rtc"
"loongson,ls7a-rtc"
"loongson,ls2k0500-rtc"
"loongson,ls2k2000-rtc", "loongson,ls2k0500-rtc"
"loongson,ls2k1000-rtc"
{ .compatible = "loongson,ls1b-rtc", .data = &ls1x_rtc_config }
{ .compatible = "loongson,ls7a-rtc", .data = &generic_rtc_config }
{ .compatible = "loongson,ls2k0500-rtc", .data = &generic_rtc_config }
{ .compatible = "loongson,ls2k1000-rtc", .data = &ls2k1000_rtc_config }
Thanks.
Binbin
>
> >
> > 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.
>
> ls2k500 and ls2k2000 seem compatible with each other so should use fallback.
>
> Best regards,
> Krzysztof
>
