linux-kernel - Re: [PATCH 23/24] ARM: OMAP2+: Allow clock alias provision from device tree

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: <513F352B.3050608@ti.com>
Date:	Tue, 12 Mar 2013 16:01:15 +0200
From:	Roger Quadros <rogerq@...com>
To:	Benoit Cousson <b-cousson@...com>, <tony@...mide.com>
CC:	<balbi@...com>, <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<devicetree-discuss@...ts.ozlabs.org>,
	Russell King <linux@....linux.org.uk>,
	Rajendra Nayak <rnayak@...com>,
	Santosh Shilimkar <santosh.shilimkar@...com>
Subject: Re: [PATCH 23/24] ARM: OMAP2+: Allow clock alias provision from device
 tree

Hi Benoit,

On 03/12/2013 03:17 PM, Benoit Cousson wrote:
> Hi Roger,
> 
> On 03/12/2013 12:43 PM, Roger Quadros wrote:
>> Currently on OMAP, it is not possible to specify a clock consumer
>> to any of the OMAP generated clocks using the device tree. This can pose
>> a problem for external devices that run off an OMAP clock as we
>> can't reliably provide a reference to the clock in the device tree.
> 
> I'm really confused by that statement... Why cannot you use the current
> clock binding definition?
> 
> The point is that we should avoid defining temporary custom bindings.
> Especially when a generic one already exist.
> 
> I know you already discussed that on the list, but I cannot really find
> the rational in the previous thread.
> 
> Here is a quote from the original "Subject: Re: how to specify an OMAP
> clock in device tree?" thread.
> 
>> /* provider */
>> clks: omapclocks {
>>         compatible = "ti,omapclocks";
>>         #clock-cells = <1>;
>> };
>>
>> /* consumer */
>> hsusb1_phy: hsusb1_phy {
>> 	compatible = "usb-nop-xceiv";
>> 	clocks = <&clks "auxclk3_ck">;	/* FREF_CLK3 */
>> 	clock-names = "main-clk";
>> };
>>
>> The only problem I see is that the argument to the clks phandle
>> cannot be a string. It needs to be u32.
>>
>> In that case we need to map all clocks into a u32 index.
>>
>> If we can do that only for auxclks, my problem is solved for panda.
> 
> phandle is u32 as always, but you should not care about that.
> What you care about is the clock node referenced by the phandle, not the
> phandle itself.
> 
> What is missing right now is a proper of_clk_add_provider call to
> declare a generic OMAP clock provider and thus allow OMAP clocks to be
> used with DT.
> 
> The AUXCLOCKs are managed by the SCRM which is outside the PRCM, so you
> should be able to add a clock providers dedicated to the SCRM clocks only.

Okay, I will convert at least the SCRM clocks to be provided by device tree.

Tony,

Please drop this patch and patch 24. The rest should be fine.
Just that Panda EHCI won't work till we have the PHY clock correctly
provided.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/