"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. Kevin -- 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
