Hi 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 it? > 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. > 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. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
