* Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [091204 04:56]: > Janusz Krzysztofik napisał(a): <snip> > I think I've already found one part of the answer myself: you > probably mean putting each table definition in a corresponding > arch/arm/mach-omap[12]/mcbsp.c source file, don't you? Well I did not initially, but sounds like that's the cleanest way to go. > What remains unclear for me is if you really intend to reserve > static cache space for all McBSP ports supported by a machine, even > if not supported by a particular cpu or not used on a particular > board. No idea :) But please consider what happens if we want to compile in omap2 + omap3 into a single binary. Or what happens if some newer omaps add more McBSP registers. <snip> > > > >Did you mean defining a new omap_mcbsp_read_cache() function, > >similiar to omap_mcbsp_read(), but reading from cache instead of > >hardware? Yeah something like that. That is more future proof. > >Or do you prefere if I modify omap_mcbsp_read() to be able to read > >from both hardware and cache, dependig on an additional argument, > >for example? That actually sounds like the best way to solve it to me! > But shouldn't declarations for both tables be placed in > arch/arm/plat-omap/include/plat/mcbsp.h withing an ifdef else block? > If yes, one ifdef else block would be replaced with another. Or did > you mean placing those declarations inside existing ifdef block with > defines for register offsets? Ifdefs are OK if they just optimize out code when some omap is not compiled in. But if you do ifdef else, then it means trouble sooner or later. In this case you should probably have the cache initialized separately in mach-omap1/mcbsp.c and mach-omap2/mcbsp.c. 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
