On Wed, May 18, 2011 at 06:06, Kevin Hilman <khilman@xxxxxx> wrote: > "Menon, Nishanth" <nm@xxxxxx> writes: > > [...] > >>> >>>> to handle this on the fly, add a structure to describe this >>>> and use the structure for vc44xx mpu definition. use the >>>> default for rest of the domains. >>> >>> IMO, while it makes us generate a few more struct in the data, I think >>> it's cleaner to not treat this as an exception. IOW, just define >>> the channel struct(s) in each data file, so every VC has one associated >>> with it. Probably also need a WARN() and graceful failure during init >>> if a channel doesn't have a channel config defined. >> .. >> >>> >>>> Signed-off-by: Nishanth Menon <nm@xxxxxx> >>>> --- >>>> arch/arm/mach-omap2/vc.c | 35 +++++++++++++++++++---------------- >>>> arch/arm/mach-omap2/vc.h | 33 +++++++++++++++++++++++++++++++++ >>>> arch/arm/mach-omap2/vc44xx_data.c | 10 ++++++++++ >>>> 3 files changed, 62 insertions(+), 16 deletions(-) >>>> >>>> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c >>>> index f8185d2..2add945 100644 >>>> --- a/arch/arm/mach-omap2/vc.c >>>> +++ b/arch/arm/mach-omap2/vc.c >> [..] >>>> >>>> + /* if there is an exception case, use the exception data */ >>>> + if (!vc->cfg_ch_data) >>>> + cfg_channel_data = &cfg_channel_common; >>>> + else >>>> + cfg_channel_data = vc->cfg_ch_data; >>> >>> Based on the above, this block could be dropped, and... >> >> Except I will have to replicate this for OMAP3 and 4 - which is >> possible.. but replicated data which is needed only during init > > Yes, but remember we are trying to keep data separated from code. > Eventually, much of this data will likely be migrated to the device > tree, so we want to be sure our data is cleanly separated from code. > >> :( did not want vc pointer to contain __initdata pointer (dangling >> ones after boot) > > Yes, so far, we're not using initdata for per-SoC stuff, and there have > been proposals around that. However, moving to device tree will largely > solve the per-SoC bloat issues around that. ok. will post a new rev as soon as I get free. Regards, Nishanth Menon -- 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
