All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jingbao Qiu <qiujingbao.dlmu@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: alexandre.belloni@bootlin.com, robh+dt@kernel.org,
	 krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	chao.wei@sophgo.com,  unicorn_wang@outlook.com,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	 aou@eecs.berkeley.edu, linux-rtc@vger.kernel.org,
	devicetree@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,  dlan@gentoo.org,
	inochiama@outlook.com
Subject: Re: [PATCH v6 3/3] riscv: dts: sophgo: add rtc dt node for CV1800
Date: Wed, 17 Jan 2024 11:24:43 +0800	[thread overview]
Message-ID: <CAJRtX8Qxvpf_CTJG41U6JC3_qLL9raFxX3LD0LoPNhve=MDyFA@mail.gmail.com> (raw)
In-Reply-To: <f99da95d-a6ab-4646-8ad8-8245e275639e@linaro.org>

On Wed, Jan 17, 2024 at 12:58 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/01/2024 17:29, Jingbao Qiu wrote:
> > On Wed, Jan 17, 2024 at 12:03 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/01/2024 16:51, Jingbao Qiu wrote:
> >>>>> CV1800 is a RISCV based SOC that includes an RTC module. The RTC
> >>>>> module has an OSC oscillator
> >>>>
> >>>>
> >>>> I am not going to read pages of description. Please write concise replies.
> >>>
> >>> Thanks, What I mean is that this hardware includes two functions, RTC
> >>> and POR. How should I describe their relationship?
> >>
> >> Your POR does not need to take any resources, so no need to describe any
> >> relationship.
> >>
> >> ...
> >>
> >>>>> Your suggestion is, firstly, the por submodule does not have any
> >>>>> resources, so it should be deleted.
> >>>>
> >>>> So where did you delete it? I still see it in this patch.
> >>>
> >>> Should I completely delete him? How can a por driver obtain device information?
> >>
> >> Delete completely.
> >>
> >> Device information? What is this? We already agreed you don't have any
> >> resources for POR.
> >>
> >> ....
> >>
> >>>> Device is only one thing, not two.
> >>>>
> >>>>>                     reg = <0x5025000 0x2000>;
> >>>>>                     interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>                     clocks = <&osc>;
> >>>>> };
> >>>>> However, in reality, the POR submodule does not use IRQ and CLK.
> >>>>> Please do not hesitate to teach. Thanks.
> >>>>
> >>>> I expect one device node. How many drivers you have does not matter: you
> >>>> can instantiate 100 Linux devices in 100 Linux device drivers.
> >>>
> >>> I understand what you mean. A device node corresponds to multiple drivers.
> >>> Should I completely delete the POR device tree node and add it when
> >>> submitting the POR driver?
> >>
> >> ? I wrote it in previous messages and twice in this thread. Completely
> >> delete. You do not add it back! Because if you ever intended to add it
> >> back, it should be added since beginning. I don't understand what
> >> submitting later would solve.
> >>
> >>> If that's the case, how can I explain that the rtc device tree node
> >>> uses the syscon tag?
> >>> How can I describe a POR device in DTS? POR is a submodule of RTC, and
> >>> it also has corresponding drivers.
> >>
> >> I said, there is no need for POR in DTS, because you have nothing there.
> >> Why do you insist on putting it on DTS?
> >>
> >>> It's just that his resources are only shared with RTC's Reg.
> >>
> >> What resources? Reg? That's not a separate resource.
>
> I meant, separate from the RTC. I had impression that IO space is shared
> or mixed with RTC? If it is separate, why it wasn't listed?
>
> >
> > I'm very sorry about this.
> > But I found a binding file that only contains Reg and Compatible.
> >
> > rtc@80920000 {
> > compatible = "cirrus,ep9301-rtc";
> > reg = <0x80920000 0x100>;
> > };
> >
> > Link: Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml
>
> And?
>
> >
> >>
> >> To summarize: Drop POR from DTS and never bring it back, unless you come
> >> with some different arguments, which you did not say already.
> >>
> >
> > You are right, if there is no por device tree node, how can the por
> > driver obtain the Reg?
>
> The same as currently. Does your POR node has reg? No, so according to
> your logic it cannot obtain address space.
>
> Children Linux devices share regmap with parent device.
>

Thanks, Power-On-Reset/POR driver requires Reg to complete its functions.
The compatible of POR is required in DTS to load the corresponding driver.
The POR driver was not submitted in the patch. However, this patch requires
the addition of RTC in DTS. Considering the future addition of POR
driver, I added a POR node.
I'm not sure why the POR node needs to be deleted, just because it
only has the compatible attribute?
Or maybe it's because I didn't submit the POR driver, so I need to
delete the POR node.
I found an example.

st: timer@fffffd00 {
    compatible = "atmel,at91rm9200-st", "syscon", "simple-mfd";
    reg = <0xfffffd00 0x100>;
    interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
    clocks = <&slow_xtal>;
    watchdog {
      compatible = "atmel,at91rm9200-wdt";
    };
};

Link:arch/arm/boot/dts/microchip/at91rm9200.dtsi:114

Like this, when the por driver insmod is activated, the por driver can
obtain the regs of the parent device.
Thank you again.

Best regards,
Jingbao Qiu

WARNING: multiple messages have this Message-ID (diff)
From: Jingbao Qiu <qiujingbao.dlmu@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: alexandre.belloni@bootlin.com, robh+dt@kernel.org,
	 krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	chao.wei@sophgo.com,  unicorn_wang@outlook.com,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	 aou@eecs.berkeley.edu, linux-rtc@vger.kernel.org,
	devicetree@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org,  dlan@gentoo.org,
	inochiama@outlook.com
Subject: Re: [PATCH v6 3/3] riscv: dts: sophgo: add rtc dt node for CV1800
Date: Wed, 17 Jan 2024 11:24:43 +0800	[thread overview]
Message-ID: <CAJRtX8Qxvpf_CTJG41U6JC3_qLL9raFxX3LD0LoPNhve=MDyFA@mail.gmail.com> (raw)
In-Reply-To: <f99da95d-a6ab-4646-8ad8-8245e275639e@linaro.org>

On Wed, Jan 17, 2024 at 12:58 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/01/2024 17:29, Jingbao Qiu wrote:
> > On Wed, Jan 17, 2024 at 12:03 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 16/01/2024 16:51, Jingbao Qiu wrote:
> >>>>> CV1800 is a RISCV based SOC that includes an RTC module. The RTC
> >>>>> module has an OSC oscillator
> >>>>
> >>>>
> >>>> I am not going to read pages of description. Please write concise replies.
> >>>
> >>> Thanks, What I mean is that this hardware includes two functions, RTC
> >>> and POR. How should I describe their relationship?
> >>
> >> Your POR does not need to take any resources, so no need to describe any
> >> relationship.
> >>
> >> ...
> >>
> >>>>> Your suggestion is, firstly, the por submodule does not have any
> >>>>> resources, so it should be deleted.
> >>>>
> >>>> So where did you delete it? I still see it in this patch.
> >>>
> >>> Should I completely delete him? How can a por driver obtain device information?
> >>
> >> Delete completely.
> >>
> >> Device information? What is this? We already agreed you don't have any
> >> resources for POR.
> >>
> >> ....
> >>
> >>>> Device is only one thing, not two.
> >>>>
> >>>>>                     reg = <0x5025000 0x2000>;
> >>>>>                     interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>                     clocks = <&osc>;
> >>>>> };
> >>>>> However, in reality, the POR submodule does not use IRQ and CLK.
> >>>>> Please do not hesitate to teach. Thanks.
> >>>>
> >>>> I expect one device node. How many drivers you have does not matter: you
> >>>> can instantiate 100 Linux devices in 100 Linux device drivers.
> >>>
> >>> I understand what you mean. A device node corresponds to multiple drivers.
> >>> Should I completely delete the POR device tree node and add it when
> >>> submitting the POR driver?
> >>
> >> ? I wrote it in previous messages and twice in this thread. Completely
> >> delete. You do not add it back! Because if you ever intended to add it
> >> back, it should be added since beginning. I don't understand what
> >> submitting later would solve.
> >>
> >>> If that's the case, how can I explain that the rtc device tree node
> >>> uses the syscon tag?
> >>> How can I describe a POR device in DTS? POR is a submodule of RTC, and
> >>> it also has corresponding drivers.
> >>
> >> I said, there is no need for POR in DTS, because you have nothing there.
> >> Why do you insist on putting it on DTS?
> >>
> >>> It's just that his resources are only shared with RTC's Reg.
> >>
> >> What resources? Reg? That's not a separate resource.
>
> I meant, separate from the RTC. I had impression that IO space is shared
> or mixed with RTC? If it is separate, why it wasn't listed?
>
> >
> > I'm very sorry about this.
> > But I found a binding file that only contains Reg and Compatible.
> >
> > rtc@80920000 {
> > compatible = "cirrus,ep9301-rtc";
> > reg = <0x80920000 0x100>;
> > };
> >
> > Link: Documentation/devicetree/bindings/rtc/cirrus,ep9301-rtc.yaml
>
> And?
>
> >
> >>
> >> To summarize: Drop POR from DTS and never bring it back, unless you come
> >> with some different arguments, which you did not say already.
> >>
> >
> > You are right, if there is no por device tree node, how can the por
> > driver obtain the Reg?
>
> The same as currently. Does your POR node has reg? No, so according to
> your logic it cannot obtain address space.
>
> Children Linux devices share regmap with parent device.
>

Thanks, Power-On-Reset/POR driver requires Reg to complete its functions.
The compatible of POR is required in DTS to load the corresponding driver.
The POR driver was not submitted in the patch. However, this patch requires
the addition of RTC in DTS. Considering the future addition of POR
driver, I added a POR node.
I'm not sure why the POR node needs to be deleted, just because it
only has the compatible attribute?
Or maybe it's because I didn't submit the POR driver, so I need to
delete the POR node.
I found an example.

st: timer@fffffd00 {
    compatible = "atmel,at91rm9200-st", "syscon", "simple-mfd";
    reg = <0xfffffd00 0x100>;
    interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
    clocks = <&slow_xtal>;
    watchdog {
      compatible = "atmel,at91rm9200-wdt";
    };
};

Link:arch/arm/boot/dts/microchip/at91rm9200.dtsi:114

Like this, when the por driver insmod is activated, the por driver can
obtain the regs of the parent device.
Thank you again.

Best regards,
Jingbao Qiu

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2024-01-17  3:24 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 16:05 [PATCH v6 0/3] riscv: rtc: sophgo: add mfd and rtc support for CV1800 Jingbao Qiu
2024-01-15 16:05 ` Jingbao Qiu
2024-01-15 16:05 ` [PATCH v6 1/3] dt-bindings: rtc: sophgo: add RTC support for Sophgo CV1800 series SoC Jingbao Qiu
2024-01-15 16:05   ` Jingbao Qiu
2024-01-15 16:05 ` [PATCH v6 2/3] rtc: sophgo: add rtc support for Sophgo CV1800 SoC Jingbao Qiu
2024-01-15 16:05   ` Jingbao Qiu
2024-01-16  7:46   ` Krzysztof Kozlowski
2024-01-16  7:46     ` Krzysztof Kozlowski
2024-01-15 16:06 ` [PATCH v6 3/3] riscv: dts: sophgo: add rtc dt node for CV1800 Jingbao Qiu
2024-01-15 16:06   ` Jingbao Qiu
2024-01-16  7:44   ` Krzysztof Kozlowski
2024-01-16  7:44     ` Krzysztof Kozlowski
2024-01-16 14:41     ` Jingbao Qiu
2024-01-16 14:41       ` Jingbao Qiu
2024-01-16 15:25       ` Krzysztof Kozlowski
2024-01-16 15:25         ` Krzysztof Kozlowski
2024-01-16 15:51         ` Jingbao Qiu
2024-01-16 15:51           ` Jingbao Qiu
2024-01-16 16:03           ` Krzysztof Kozlowski
2024-01-16 16:03             ` Krzysztof Kozlowski
2024-01-16 16:29             ` Jingbao Qiu
2024-01-16 16:29               ` Jingbao Qiu
2024-01-16 16:53               ` Alexandre Belloni
2024-01-16 16:53                 ` Alexandre Belloni
2024-01-17  2:54                 ` Jingbao Qiu
2024-01-17  2:54                   ` Jingbao Qiu
2024-01-17  9:01                   ` Alexandre Belloni
2024-01-17  9:01                     ` Alexandre Belloni
2024-01-17 10:12                     ` Jingbao Qiu
2024-01-17 10:12                       ` Jingbao Qiu
2024-01-16 16:58               ` Krzysztof Kozlowski
2024-01-16 16:58                 ` Krzysztof Kozlowski
2024-01-17  3:24                 ` Jingbao Qiu [this message]
2024-01-17  3:24                   ` Jingbao Qiu
2024-01-17  7:28                   ` Krzysztof Kozlowski
2024-01-17  7:28                     ` Krzysztof Kozlowski
2024-01-17  7:39                     ` Jingbao Qiu
2024-01-17  7:39                       ` Jingbao Qiu
2024-01-17 12:59     ` Conor Dooley
2024-01-17 12:59       ` Conor Dooley

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='CAJRtX8Qxvpf_CTJG41U6JC3_qLL9raFxX3LD0LoPNhve=MDyFA@mail.gmail.com' \
    --to=qiujingbao.dlmu@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=chao.wei@sophgo.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlan@gentoo.org \
    --cc=inochiama@outlook.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=unicorn_wang@outlook.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.