[PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
hvaibhav at ti.com
Thu Aug 16 05:36:44 EDT 2012
On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote:
> On Mon, 9 Jul 2012, Tony Lindgren wrote:
> > Below (untested) is what could be done in the short term.
> That's fine with me. Do you want to queue it or do you want me to queue
> > Heh these CK_XXXX defines are now running out of the u16 cpu_mask.
> > They really should be replaced with SoC specific lists of clocks
> > rather than bloating the cpu_mask and repeating it for every clock
> > that's compiled in for 800+ times.
> Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of
> bloat concerns for multi-OMAP kernels. If it were up to me, I'd just
> change it to a u32 and be done with the problem for the foreseeable
> > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set
> > for non-shared clocks if they only get set in some *_data.c
> > file in a unique way?
> > Paul got any better ideas?
> Aside from using u32? Not really. As we've discussed in the past, at
> some point we should convert the clock initialization to using some kind
> of per-SoC list. But it doesn't seem worth spending too much time on that
> while the common clock framework conversion is higher priority.
This reminds me for AM33xx clock-tree migration to common-clock framework,
so just wanted to update on this, I have already converted the clock-tree to
common-clock fw, on top of Rajendra's repository.
Now waiting on Rajendra for his next series...
More information about the linux-arm-kernel