[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5720B107.4000907@ti.com>
Date: Wed, 27 Apr 2016 15:31:03 +0300
From: Tero Kristo <t-kristo@...com>
To: "H. Nikolaus Schaller" <hns@...delico.com>,
Tony Lindgren <tony@...mide.com>,
"Ujfalusi, Peter" <peter.ujfalusi@...com>
CC: BenoƮt Cousson <bcousson@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Russell King <linux@....linux.org.uk>, <ldewangan@...dia.com>,
<linux-omap@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <marek@...delico.com>,
<kernel@...a-handheld.com>, <letux-kernel@...nphoenux.org>
Subject: Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer
On 27/04/16 09:04, H. Nikolaus Schaller wrote:
>
>> Am 26.04.2016 um 19:27 schrieb Tony Lindgren <tony@...mide.com>:
>>
>> Tero,
>>
>> * H. Nikolaus Schaller <hns@...delico.com> [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.
The two could very well be implemented as clock nodes, a mux and a gate.
This would describe the hardware functionality better imo, if the
assumptions made here are correct. Implementing the control as pinctrl
hacks looks rather weird to me.
I could not find any documentation related to the ckobuffer usage
though, maybe Peter can provide some insight? I think you spent some
considerable time bringing up twl6040 a few years back...
-Tero
>
> BR,
> Nikolaus
>
>>
>> Regards,
>>
>> Tony
>>
>>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
>>> ---
>>> 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@...4 {
>>> + 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@...00000 {
>>> --
>>> 2.7.3
>>>
>
Powered by blists - more mailing lists