* Pedanekar, Hemant <hemantp@xxxxxx> [110105 15:59]: > linux-omap-owner@xxxxxxxxxxxxxxx wrote on : > > > Tony Lindgren wrote on Wednesday, January 05, 2011 4:56 AM: > > > >> * Paul Walmsley <paul@xxxxxxxxx> [110104 09:48]: > >>> On Tue, 4 Jan 2011, Pedanekar, Hemant wrote: > >>> > >>>> Looking at above, it seems another config option like > >>>> CONFIG_SOC_OMAP3XXX is also needed in addition to CONFIG_SOC_OMAPTI816X. > >>> > >>> We already have CONFIG_ARCH_OMAP3430, CONFIG_ARCH_OMAP2430, and > >>> CONFIG_ARCH_OMAP2420. I guess at some point those need to be renamed to > >>> CONFIG_SOC_*. > >> > >> Yes that's what I was thinking too. Keep CONFIG_ARCH_OMAP2, 3, and 4, > >> and rename CONFIG_ARCH_OMAP3430 etc to CONFIG_SO_COMAP3430 and so on. > >> > >> Regards, > >> > >> Tony > > > > So I will add CONFIG_SOC_OMAPTI816X to handle TI816X specific variations. > > But I think without addition of corresponding > > CONFIG_SOC_OMAP3XXX, it would be > > difficult to handle 2nd case I mentioned (OMAP3 build for OMAP3xxx as well > > as TI816X SoCs). Will it be OK if we consider this 2nd case as > > invalid/unsupported for the moment - that is, 2nd case = 4th case (OMAP3 > > build for TI816X only)? Same applies for multi-omap case too. > > > > In short, if CONFIG_SOC_OMAPTI816X is selected, the build becomes specific > > to TI816X and not OMAP3xxx in all the cases (so keep > > CONFIG_SOC_OMAPTI816X disabled > > by default in multi-omap configuration). > > > Tony, > Does the above look ok? Also please let me know any other comments and I will > send updated patches. Let's try to keep all the possible dependencies out of this for now. Please just add CONFIG_SOC_OMAPTI816X and keep CONFIG_ARCH_OMAP3 selected. The CONFIG_SOC_XXXX things must be optional to save memory, whatever we do we should also be able to do without them. Regards, Tony -- 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
