From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753062AbcD0GFL (ORCPT ); Wed, 27 Apr 2016 02:05:11 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.160]:30091 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752963AbcD0GFI (ORCPT ); Wed, 27 Apr 2016 02:05:08 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6mSAGQ+qKIDwzPD5N2Q== X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer From: "H. Nikolaus Schaller" In-Reply-To: <20160426172710.GI5995@atomide.com> Date: Wed, 27 Apr 2016 08:04:43 +0200 Cc: Tero Kristo , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , ldewangan@nvidia.com, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, marek@goldelico.com, kernel@pyra-handheld.com, letux-kernel@openphoenux.org Content-Transfer-Encoding: 7bit Message-Id: <70572DA1-BEB4-4681-BA6C-2E1C9002D730@goldelico.com> References: <20160426172710.GI5995@atomide.com> To: Tony Lindgren X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Am 26.04.2016 um 19:27 schrieb Tony Lindgren : > > Tero, > > * H. Nikolaus Schaller [160418 11:23]: >> OMAP5 has a register to control if the ckobuffer is enabled >> and defines the polarity. ckobuffer is required to drive a twl6040 >> with the system clock. Hence, add the pinctrl,single to the >> OMAP5 SoC description so that omap5-board-common can >> set up the ckobuffer as required. > > Is this really a mux or should it be a mux clock? It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad. The register is part of the CTRL_MODULE_WKUP. The clock signal is the xtal master clock of the whole SoC. Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon. Therefore I would say it is about padconf and not clock or clock mux related. It just happens to be a clock signal which can be routed to this pad. BR, Nikolaus > > Regards, > > Tony > >> Signed-off-by: H. Nikolaus Schaller >> --- >> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >> index 120b6b8..1d9050f 100644 >> --- a/arch/arm/boot/dts/omap5.dtsi >> +++ b/arch/arm/boot/dts/omap5.dtsi >> @@ -277,6 +277,16 @@ >> pinctrl-single,register-width = <16>; >> pinctrl-single,function-mask = <0x7fff>; >> }; >> + >> + omap5_control_ckobuffer: pinmux@cdb4 { >> + compatible = "ti,omap5-padconf", >> + "pinctrl-single"; >> + reg = <0xcdb4 4>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-single,register-width = <32>; >> + pinctrl-single,function-mask = <0xf0000000>; >> + }; >> }; >> >> ocmcram: ocmcram@40300000 { >> -- >> 2.7.3 >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Nikolaus Schaller" Subject: Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer Date: Wed, 27 Apr 2016 08:04:43 +0200 Message-ID: <70572DA1-BEB4-4681-BA6C-2E1C9002D730@goldelico.com> References: <20160426172710.GI5995@atomide.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160426172710.GI5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Tony Lindgren Cc: Tero Kristo , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, marek-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org, kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf@public.gmane.org, letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org List-Id: devicetree@vger.kernel.org > Am 26.04.2016 um 19:27 schrieb Tony Lindgren : > > Tero, > > * H. Nikolaus Schaller [160418 11:23]: >> OMAP5 has a register to control if the ckobuffer is enabled >> and defines the polarity. ckobuffer is required to drive a twl6040 >> with the system clock. Hence, add the pinctrl,single to the >> OMAP5 SoC description so that omap5-board-common can >> set up the ckobuffer as required. > > Is this really a mux or should it be a mux clock? It is a pinmux setting for the clock out buffer to choose what signal (and polarity) is presented on the fref_xtal_clk pad. The register is part of the CTRL_MODULE_WKUP. The clock signal is the xtal master clock of the whole SoC. Although there is a bit to choose an alternate clock, there is no alternate in the OMAP5 silicon. Therefore I would say it is about padconf and not clock or clock mux related. It just happens to be a clock signal which can be routed to this pad. BR, Nikolaus > > Regards, > > Tony > >> Signed-off-by: H. Nikolaus Schaller >> --- >> arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi >> index 120b6b8..1d9050f 100644 >> --- a/arch/arm/boot/dts/omap5.dtsi >> +++ b/arch/arm/boot/dts/omap5.dtsi >> @@ -277,6 +277,16 @@ >> pinctrl-single,register-width = <16>; >> pinctrl-single,function-mask = <0x7fff>; >> }; >> + >> + omap5_control_ckobuffer: pinmux@cdb4 { >> + compatible = "ti,omap5-padconf", >> + "pinctrl-single"; >> + reg = <0xcdb4 4>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + pinctrl-single,register-width = <32>; >> + pinctrl-single,function-mask = <0xf0000000>; >> + }; >> }; >> >> ocmcram: ocmcram@40300000 { >> -- >> 2.7.3 >> -- 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