[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140126002500.GA13741@localhost>
Date: Sat, 25 Jan 2014 21:25:01 -0300
From: Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>
To: Emilio López <emilio@...pez.com.ar>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Andrew Lunn <andrew@...n.ch>,
Mike Turquette <mturquette@...aro.org>,
Jason Cooper <jason@...edaemon.net>,
linux-kernel@...r.kernel.org,
Gregory Clement <gregory.clement@...e-electrons.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/4] clk: mvebu: fix clk init order
Hi Emilio,
Thanks for your help with this.
On Sat, Jan 25, 2014 at 07:11:07PM -0300, Emilio López wrote:
[..]
> >
> > Ok, I'll look if using of_clk_get_parent_name will help here. But again,
> > I can see that clk-gating driver gets registered before core-clk driver.
> > There may be no code to give you the parent name at that time.
>
> After looking at some of the armada*.dtsi, I see you don't list the
> clock names on the coreclk node, so of_clk_get_parent_name may not be of
> much value after all.
>
IIRC, we faced a similar issue with the Core Divider clock and solved it by
specifying the clock names in the DT.
I meant to complete the core and gating clocks in a similar way
(providing names on the DT), but apparently (as discussed with Gregory Clement)
Mike Turquette and others are planning to remove the clock names from
the DT entirely.
Can you guys explain about this plan a bit further? Or do you think we
should specify the names on the DT for all the clocks instead?
Notice that the latter would remove lots of strings from the kernel
itself (right?)
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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/
Powered by blists - more mailing lists