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

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

From: tony@atomide.com (Tony Lindgren)
Date: 2012-08-16 08:39:24
Also in: linux-omap

* Paul Walmsley [off-list ref] [120815 15:27]:
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?
Probably best for you to take it along with other related patches.
 
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.
And then we're wasting that 1.6KB..
 
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.
Right, let's do the ifdef else thing then.

Regards,

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