From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754486AbbGBCGE (ORCPT ); Wed, 1 Jul 2015 22:06:04 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:43070 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752321AbbGBCF4 (ORCPT ); Wed, 1 Jul 2015 22:05:56 -0400 X-Listener-Flag: 11101 Message-ID: <1435802722.3526.13.camel@mtksdaap41> Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null From: James Liao To: Sascha Hauer , Heiko =?ISO-8859-1?Q?St=FCbner?= CC: , Eddie Huang , Matthias Brugger , , , , , Mike Turquette , Stephen Boyd , Date: Thu, 2 Jul 2015 10:05:22 +0800 In-Reply-To: <20150701064935.GC18611@pengutronix.de> References: <1434605351-64592-1-git-send-email-eddie.huang@mediatek.com> <8860488.JuX1EN5tWB@diego> <1435132455.28866.21.camel@mtksdaap41> <1510058.fTE6dlSRsH@diego> <1435655229.19330.15.camel@mtksdaap41> <20150701064935.GC18611@pengutronix.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sascha, On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote: > On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote: > > There are 4 clocks which are derived from clk_null directly in current > > topckgen implementation: > > > > clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts > > > > Our designer mentioned 2 things about external clocks: > > > > 1. These 4 clocks come from analog macro, not from PLL, nor from > > external clocks directly. > > Ok, this means there actually are clocks. We can't control these clock and > they have some known or unknown rate. This makes them fixed clocks. Just > specify them in the device tree and you are done. Give them reasonable > names and the rate if you know it, 0 otherwise. > > The problem is not that you use fixed clocks for non software > controllable clocks of unknwown rates, but that you try to use a single > clock for all of them and name it 'dummy' or 'null'. Name it > > dpi_ck { > compatible = "fixed-clock"; > rate = <0>; /* unknown, generated by some Analog block */ > }; > > Technically it's the same, but it sounds much more professional and like > you know what you are doing ;) These clocks are SoC internal clocks. Is it suitable to specify them in the device tree? According to your and Heiko's suggestion, it looks the best way should be specifying these clocks in the driver code without a dummy parent. i.e.: Original code: FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1), FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1), FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1), FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1), New code: FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE), FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE), FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE), FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE), Then we don't need to specify a dummy clock such as clk_null in device tree. Best regards, James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Liao Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null Date: Thu, 2 Jul 2015 10:05:22 +0800 Message-ID: <1435802722.3526.13.camel@mtksdaap41> References: <1434605351-64592-1-git-send-email-eddie.huang@mediatek.com> <8860488.JuX1EN5tWB@diego> <1435132455.28866.21.camel@mtksdaap41> <1510058.fTE6dlSRsH@diego> <1435655229.19330.15.camel@mtksdaap41> <20150701064935.GC18611@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150701064935.GC18611-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sascha Hauer , Heiko =?ISO-8859-1?Q?St=FCbner?= Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Eddie Huang , Matthias Brugger , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, Mike Turquette , Stephen Boyd , ted.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org List-Id: devicetree@vger.kernel.org Hi Sascha, On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote: > On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote: > > There are 4 clocks which are derived from clk_null directly in current > > topckgen implementation: > > > > clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts > > > > Our designer mentioned 2 things about external clocks: > > > > 1. These 4 clocks come from analog macro, not from PLL, nor from > > external clocks directly. > > Ok, this means there actually are clocks. We can't control these clock and > they have some known or unknown rate. This makes them fixed clocks. Just > specify them in the device tree and you are done. Give them reasonable > names and the rate if you know it, 0 otherwise. > > The problem is not that you use fixed clocks for non software > controllable clocks of unknwown rates, but that you try to use a single > clock for all of them and name it 'dummy' or 'null'. Name it > > dpi_ck { > compatible = "fixed-clock"; > rate = <0>; /* unknown, generated by some Analog block */ > }; > > Technically it's the same, but it sounds much more professional and like > you know what you are doing ;) These clocks are SoC internal clocks. Is it suitable to specify them in the device tree? According to your and Heiko's suggestion, it looks the best way should be specifying these clocks in the driver code without a dummy parent. i.e.: Original code: FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1), FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1), FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1), FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1), New code: FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE), FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE), FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE), FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE), Then we don't need to specify a dummy clock such as clk_null in device tree. Best regards, James -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: jamesjj.liao@mediatek.com (James Liao) Date: Thu, 2 Jul 2015 10:05:22 +0800 Subject: [PATCH] arm64: dts: mt8173: add clock_null In-Reply-To: <20150701064935.GC18611@pengutronix.de> References: <1434605351-64592-1-git-send-email-eddie.huang@mediatek.com> <8860488.JuX1EN5tWB@diego> <1435132455.28866.21.camel@mtksdaap41> <1510058.fTE6dlSRsH@diego> <1435655229.19330.15.camel@mtksdaap41> <20150701064935.GC18611@pengutronix.de> Message-ID: <1435802722.3526.13.camel@mtksdaap41> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Sascha, On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote: > On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote: > > There are 4 clocks which are derived from clk_null directly in current > > topckgen implementation: > > > > clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts > > > > Our designer mentioned 2 things about external clocks: > > > > 1. These 4 clocks come from analog macro, not from PLL, nor from > > external clocks directly. > > Ok, this means there actually are clocks. We can't control these clock and > they have some known or unknown rate. This makes them fixed clocks. Just > specify them in the device tree and you are done. Give them reasonable > names and the rate if you know it, 0 otherwise. > > The problem is not that you use fixed clocks for non software > controllable clocks of unknwown rates, but that you try to use a single > clock for all of them and name it 'dummy' or 'null'. Name it > > dpi_ck { > compatible = "fixed-clock"; > rate = <0>; /* unknown, generated by some Analog block */ > }; > > Technically it's the same, but it sounds much more professional and like > you know what you are doing ;) These clocks are SoC internal clocks. Is it suitable to specify them in the device tree? According to your and Heiko's suggestion, it looks the best way should be specifying these clocks in the driver code without a dummy parent. i.e.: Original code: FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1), FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1), FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1), FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1), New code: FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE), FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE), FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE), FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE), Then we don't need to specify a dummy clock such as clk_null in device tree. Best regards, James