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

Jarkko Nikula
2009-12-08T07:34:09Z

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