linux-kernel - Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

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: <20130409164928.GL10155@atomide.com>
Date:	Tue, 9 Apr 2013 09:49:29 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Roger Quadros <rogerq@...com>
Cc:	b-cousson@...com, linux@....linux.org.uk, rnayak@...com,
	balbi@...com, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-usb@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Paul Walmsley <paul@...an.com>, "Menon, Nishanth" <nm@...com>,
	grygorii.strashko@...com
Subject: Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support
 for AUXCLKs

* Roger Quadros <rogerq@...com> [130409 03:00]:
> On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > 
> > Well your approach is fine as a first step moving all the clock
> > code, but it needs to be a real driver under drivers/clock/omap.
> > And the DT binding needs to stay the same for the driver(s) in the
> > long term as we start moving clocks to DT + /lib/firmware.
> 
> The code needs to be there were the clock structs are defined.
> Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4.

But if you do just a passthrough driver then that should not
be needed. 
 
> > If this all is too late for v3.10, I suggest you just set up the
> > right clock alias for panda with machine_is_compatible flag in
> > board-generic.c so we get EHCI working with DT for v3.10. Then
> > it's easy to to deal with it properly for v3.11.
> 
> OK, let's do it this way for Panda for 3.10.

Yes otherwise we'll be delaying omap4 DT conversion again. 
 
> >> How can that driver do clk_get() from cclock44xx_data.c?
> >> from where does it get the clk_id to pass into clk_get()?
> > 
> > Can't you just use the clock name there to get it?
> 
> In device tree we don't pass around clock names. You can either get
> a phandle or an index to the clock.
> 
> e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt

Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.

> > As long as the binding stays the same in the long run too, this
> > clock remapping approach is just fine as a starting point. And
> > the driver needs to go to drivers/clock/omap. But in the long run
> > we just want to get the huge amounts static data out of the kernel
> > for clocks and hwmod data to fix things for good.
> 
> In that case we need to identify what clocks need to be supported.
> If it is all (~200) of them, is this method good enough?

We should support any clock we need for booting the device with
just DT bindings to get timers, console and rootfs working. Then
we just need to load the complete set from /lib/firmware.

It seems that the binding can be the same for all the clocks.
For now, we can just use the standard clock binding and do the
remapping in the clock driver.

Regards,

Tony
--
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/