linux-kernel - Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <40536322-073F-48BD-9D07-32B9A9F07AF2@goldelico.com>
Date:	Wed, 27 Apr 2016 16:35:01 +0200
From:	"H. Nikolaus Schaller" <hns@...delico.com>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	Tero Kristo <t-kristo@...com>, Tony Lindgren <tony@...mide.com>,
	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>,
	Laxman Dewangan <ldewangan@...dia.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Marek Belisko <marek@...delico.com>, kernel@...a-handheld.com,
	Discussions about the Letux Kernel 
	<letux-kernel@...nphoenux.org>
Subject: Re: [PATCH v2 4/5] ARM: dts: omap5: describe control for ckobuffer

HI,

> Am 27.04.2016 um 16:23 schrieb Peter Ujfalusi <peter.ujfalusi@...com>:
> 
> On 04/27/2016 05:10 PM, Tero Kristo wrote:
>> On 27/04/16 16:10, H. Nikolaus Schaller wrote:
>>> 
>>>> Am 27.04.2016 um 14:31 schrieb Tero Kristo <t-kristo@...com>:
>>>> 
>>>> 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.
>>> 
>>> Why do you consider it a "pinctrl hack"? IMHO it is not a hack, but 100%
>>> proper use of pinctrl.
>> 
>> It is just the level of abstraction we are talking about here. If it is a
>> clock we are controlling, we should rather control it as a clock (higher level
>> abstraction), not a pin.
> 
> I second this. I think it is better to have a simple gate clock and handle
> only CONTROL_CKOBUFFER:CKOBUFFER_CLK_EN (bit 28) only as the other bits does
> not have real use.
> 
> Then we can add clk API support for this. On most OMAP4 devices the clock is
> always on,

this is why I am raising the question if we really want to control it on the omap5 or just 
turn it on for all omap5 boards like the omap4 appears to do... I.e. if turning the pin on
as a pinctrl is IMHO sufficient for all practical purposes.

> so the board DTS file need to provide a dummy clock, or we can make
> the high precision clock also as optional (on panda both OMAP4 and twl6040
> uses the same reference clock).

Hm. It looks as if implementing this (and clock gating) is beyond my experiences.
But I am happy to test a proposal on our omap5 board.

BR and thanks,
Nikolaus