* Tony Lindgren <t...@atomide.com> [091208 15:32]:
> * Janusz Krzysztofik <jkrzy...@tis.icnet.pl> [091208 11:45]:
> > Tuesday 08 December 2009 17:59:31 Tony Lindgren napisaƂ(a):
> > > * Tony Lindgren <t...@atomide.com> [091208 08:39]:
> > > >
> > > > How about just set the cache size above based on the processor,
> > > > then do kzalloc here:
> > > >
> > > > mcbsp->reg_cache = kzalloc(size, GFP_KERNEL);
> > > >
> > > > > +     if (!mcbsp->reg_cache)
> > > > > +             return -ENOMEM;
> > > > > +
> > > >
> > > > That way the kzalloc and error checking are in the same place.
> > >
> > > Actually since we already have mach-omap1/mcbsp.c and mach-omap2/mcbsp.c,
> > > it would be best to pass the cache size from omap1_mcbsp_init and
> > > omap2_mcbsp_init. That leaves some of the if cpu_is_omapxxxx() else
> > > stuff.
> > 
> > Tony,
> > Almost ready with it, one more question: what do you think about splitting 
> > and 
> > moving omap_mcbsp_read()/_write() there as well? If you agree, should I 
> > submit 2 patches, one with this cleanup, the other one actually introducing 
> > cache support, or is one combined OK?
> 
> Sounds good to me!

Oh sorry forgot to reply to your question. If a single patch looks unreadable,
then split it into two where the first patch splits omap_mcbsp_read/write.

Tony
--
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

Reply via email to