Thread (40 messages) 40 messages, 5 authors, 2012-11-06
STALE4989d

[PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

From: Hiremath, Vaibhav <hidden>
Date: 2012-08-16 09:36:44
Also in: linux-omap

On Thu, Aug 16, 2012 at 03:56:42, Paul Walmsley wrote:
Hi

On Mon, 9 Jul 2012, Tony Lindgren wrote:
quoted
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 
it?
quoted
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 
future.
quoted
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...

Thanks,
Vaibhav
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help