Hi, sorry not commenting for few days. On Mon, 7 Dec 2009 13:06:31 -0800 Tony Lindgren <t...@atomide.com> wrote:
> > For me, the fact that more than one processor type can be configured side > > by > > side it not enough reason here. With your code, if more then one processor > > type is configured, twice or tripple as much memory space will be devoted > > to > > two or three cache tables instead of one that can be reused easily, as it > > is > > with mine. Since you cannot run the same instance of the kernel on several > > machines simultaneously, only one of those two or three tables is required > > at > > runtime for storing data, so this looks like a waste of expensive memory > > unless some kind of runtime optimization that I am not familiar with can > > happen here. I was even affraid before that one of objections against my > > idea > > of using the cache could be unnecessary waste of memory space. > > Well if you want to optimize it out further, how about just kzalloc it > during init? Then you have just one copy that gets set the right size > depending on what you boot. > > > Nevertheless, I'll do it your way. Maybe there are still some other reasons > > not explicitly expressed yet. > > > > I guess that omap2 part should follow the same pattern, shouldn't it? > How about declaring the reg_cache as a void pointer in struct omap_mcbsp and allocate the cache and its size in omap_mcbsp_request according to omap type? Read and write functions would access the *reg_cache either as 16-bit or 32-bit table depending on omap. No ifdefs, no unused cache tables in multi-omap binary and cache tables are allocated only for used ports. I don't think there is need to preserve cache content over omap_mcbsp_free and new omap_mcbsp_request? -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
