From: Sascha Hauer <s.hauer@pengutronix.de>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: Eddie Huang <eddie.huang@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mediatek@lists.infradead.org,
James Liao <jamesjj.liao@mediatek.com>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null
Date: Tue, 7 Jul 2015 16:36:21 +0200 [thread overview]
Message-ID: <20150707143621.GW18700@pengutronix.de> (raw)
In-Reply-To: <CAGS+omCgSjLZ2Ae5DqfmEm-2BrxQqw2ztxUCxBSngNSXxabtbg@mail.gmail.com>
On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> Add clk_null, which represents clocks that can not / need not
> >> controlled by software.
> >> There are many clocks' parent set to clk_null.
> >>
> >> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> >> Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
> >> ---
> >> Base on 4.1-rc1
> >>
> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> ---
> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> index 924fdb6..4798f44 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> @@ -81,6 +81,12 @@
> >> cpu_on = <0x84000003>;
> >> };
> >>
> >> + clk_null: clk_null {
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <0>;
> >> + #clock-cells = <0>;
> >> + };
> >
> > The discussion around this patch shows that we don't want to have this
> > clock in the device tree as it is not a hardware description.
> >
> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
> > is not interesting. What's the motivation to send this patch anyway
> > then? Why can't you keep its children on the orphan list where they are
> > already now?
> >
> > Another possibility would be to instantiate the clk_null clock from C
> > code rather than from the device tree. This way we wouldn't put any
> > wrong descriptions into the device tree and still can implement the
> > support for the real parent clocks when we actually need them.
>
> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>
> mmc1: mmc@11240000 {
> compatible = "mediatek,mt8173-mmc",
> "mediatek,mt8135-mmc";
> reg = <0 0x11240000 0 0x1000>;
> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> <&clk_null>;
> clock-names = "source", "hclk";
> status = "disabled";
> };
This is another case than the one we discussed about. In the case above
I motivated using a dummy clock since the clock exists in the system,
but is not software controllable. To abstract this from the driver
(which needs this clock since it exists) we here have the dummy clock.
However, of course I can't prove the clock is indeed not software
controllable; that's only the information I have.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Eddie Huang <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
Matthias Brugger
<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"open list:OPEN FIRMWARE AND..."
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null
Date: Tue, 7 Jul 2015 16:36:21 +0200 [thread overview]
Message-ID: <20150707143621.GW18700@pengutronix.de> (raw)
In-Reply-To: <CAGS+omCgSjLZ2Ae5DqfmEm-2BrxQqw2ztxUCxBSngNSXxabtbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> Add clk_null, which represents clocks that can not / need not
> >> controlled by software.
> >> There are many clocks' parent set to clk_null.
> >>
> >> Signed-off-by: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >> Signed-off-by: Eddie Huang <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >> ---
> >> Base on 4.1-rc1
> >>
> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> ---
> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> index 924fdb6..4798f44 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> @@ -81,6 +81,12 @@
> >> cpu_on = <0x84000003>;
> >> };
> >>
> >> + clk_null: clk_null {
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <0>;
> >> + #clock-cells = <0>;
> >> + };
> >
> > The discussion around this patch shows that we don't want to have this
> > clock in the device tree as it is not a hardware description.
> >
> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
> > is not interesting. What's the motivation to send this patch anyway
> > then? Why can't you keep its children on the orphan list where they are
> > already now?
> >
> > Another possibility would be to instantiate the clk_null clock from C
> > code rather than from the device tree. This way we wouldn't put any
> > wrong descriptions into the device tree and still can implement the
> > support for the real parent clocks when we actually need them.
>
> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>
> mmc1: mmc@11240000 {
> compatible = "mediatek,mt8173-mmc",
> "mediatek,mt8135-mmc";
> reg = <0 0x11240000 0 0x1000>;
> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> <&clk_null>;
> clock-names = "source", "hclk";
> status = "disabled";
> };
This is another case than the one we discussed about. In the case above
I motivated using a dummy clock since the clock exists in the system,
but is not software controllable. To abstract this from the driver
(which needs this clock since it exists) we here have the dummy clock.
However, of course I can't prove the clock is indeed not software
controllable; that's only the information I have.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: mt8173: add clock_null
Date: Tue, 7 Jul 2015 16:36:21 +0200 [thread overview]
Message-ID: <20150707143621.GW18700@pengutronix.de> (raw)
In-Reply-To: <CAGS+omCgSjLZ2Ae5DqfmEm-2BrxQqw2ztxUCxBSngNSXxabtbg@mail.gmail.com>
On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
> >> Add clk_null, which represents clocks that can not / need not
> >> controlled by software.
> >> There are many clocks' parent set to clk_null.
> >>
> >> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> >> Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
> >> ---
> >> Base on 4.1-rc1
> >>
> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
> >> ---
> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> index 924fdb6..4798f44 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >> @@ -81,6 +81,12 @@
> >> cpu_on = <0x84000003>;
> >> };
> >>
> >> + clk_null: clk_null {
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <0>;
> >> + #clock-cells = <0>;
> >> + };
> >
> > The discussion around this patch shows that we don't want to have this
> > clock in the device tree as it is not a hardware description.
> >
> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
> > is not interesting. What's the motivation to send this patch anyway
> > then? Why can't you keep its children on the orphan list where they are
> > already now?
> >
> > Another possibility would be to instantiate the clk_null clock from C
> > code rather than from the device tree. This way we wouldn't put any
> > wrong descriptions into the device tree and still can implement the
> > support for the real parent clocks when we actually need them.
>
> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>
> mmc1: mmc at 11240000 {
> compatible = "mediatek,mt8173-mmc",
> "mediatek,mt8135-mmc";
> reg = <0 0x11240000 0 0x1000>;
> interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&pericfg CLK_PERI_MSDC30_1>,
> <&clk_null>;
> clock-names = "source", "hclk";
> status = "disabled";
> };
This is another case than the one we discussed about. In the case above
I motivated using a dummy clock since the clock exists in the system,
but is not software controllable. To abstract this from the driver
(which needs this clock since it exists) we here have the dummy clock.
However, of course I can't prove the clock is indeed not software
controllable; that's only the information I have.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2015-07-07 14:36 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 5:29 [PATCH] arm64: dts: mt8173: add clock_null Eddie Huang
2015-06-18 5:29 ` Eddie Huang
2015-06-18 5:29 ` Eddie Huang
2015-06-18 16:15 ` Heiko Stuebner
2015-06-18 16:15 ` Heiko Stuebner
2015-06-18 16:15 ` Heiko Stuebner
2015-06-19 11:36 ` Heiko Stuebner
2015-06-19 11:36 ` Heiko Stuebner
2015-06-19 11:36 ` Heiko Stuebner
2015-06-22 3:38 ` James Liao
2015-06-22 3:38 ` James Liao
2015-06-22 3:38 ` James Liao
2015-06-22 12:53 ` Heiko Stübner
2015-06-22 12:53 ` Heiko Stübner
2015-06-22 12:53 ` Heiko Stübner
2015-06-24 7:54 ` James Liao
2015-06-24 7:54 ` James Liao
2015-06-24 7:54 ` James Liao
2015-06-24 10:24 ` Heiko Stübner
2015-06-24 10:24 ` Heiko Stübner
2015-06-24 10:24 ` Heiko Stübner
2015-06-30 9:07 ` James Liao
2015-06-30 9:07 ` James Liao
2015-06-30 9:07 ` James Liao
2015-07-01 6:49 ` Sascha Hauer
2015-07-01 6:49 ` Sascha Hauer
2015-07-01 6:49 ` Sascha Hauer
2015-07-01 11:54 ` Daniel Kurtz
2015-07-01 11:54 ` Daniel Kurtz
2015-07-02 3:06 ` James Liao
2015-07-02 3:06 ` James Liao
2015-07-02 3:06 ` James Liao
2015-07-02 4:23 ` Daniel Kurtz
2015-07-02 4:23 ` Daniel Kurtz
2015-07-02 4:23 ` Daniel Kurtz
2015-07-03 7:45 ` James Liao
2015-07-03 7:45 ` James Liao
2015-07-03 7:45 ` James Liao
2015-07-03 8:38 ` Heiko Stübner
2015-07-03 8:38 ` Heiko Stübner
2015-07-03 8:38 ` Heiko Stübner
2015-07-02 2:05 ` James Liao
2015-07-02 2:05 ` James Liao
2015-07-02 2:05 ` James Liao
2015-07-07 13:07 ` Sascha Hauer
2015-07-07 13:07 ` Sascha Hauer
2015-07-07 13:07 ` Sascha Hauer
2015-07-07 14:15 ` Daniel Kurtz
2015-07-07 14:15 ` Daniel Kurtz
2015-07-07 14:15 ` Daniel Kurtz
2015-07-07 14:36 ` Sascha Hauer [this message]
2015-07-07 14:36 ` Sascha Hauer
2015-07-07 14:36 ` Sascha Hauer
2015-07-07 15:10 ` Daniel Kurtz
2015-07-07 15:10 ` Daniel Kurtz
2015-07-07 15:10 ` Daniel Kurtz
2015-07-08 2:37 ` Eddie Huang
2015-07-08 2:37 ` Eddie Huang
2015-07-08 2:37 ` Eddie Huang
2015-07-08 5:44 ` Sascha Hauer
2015-07-08 5:44 ` Sascha Hauer
2015-07-08 5:44 ` Sascha Hauer
2015-07-10 7:27 ` Eddie Huang
2015-07-10 7:27 ` Eddie Huang
2015-07-10 8:11 ` Daniel Kurtz
2015-07-10 8:11 ` Daniel Kurtz
2015-07-10 10:29 ` Eddie Huang
2015-07-10 10:29 ` Eddie Huang
2015-07-10 10:29 ` Eddie Huang
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=20150707143621.GW18700@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=djkurtz@chromium.org \
--cc=eddie.huang@mediatek.com \
--cc=jamesjj.liao@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@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.