Re: [RFC][RFT][PATCH 3/4 v5b] OMAP: McBSP: Introduce caching in register write operations

[Jarkko Nikula <jhnikula@gmail.com>]

Hi, sorry not commenting for few days.

On Mon, 7 Dec 2009 13:06:31 -0800
Tony Lindgren <tony@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