Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache

Jarkko Nikula
2009-11-24T07:58:18Z

On Mon, 23 Nov 2009 15:53:55 -0800
Tony Lindgren <tony@atomide.com> wrote:

> > I have just found this patch, initially submitted on 2009-08-12, archived in
> > linux-omap patchwork with State: Awaiting Upstream. What does it mean? Am I
> > supposed to do something about it? After that many weeks of no negative
> > comments nor requests for changes, and taking into account what Jarkko said
> > lately in a different thread[*] about the McBSP register cache concept, can I
> > assume that it has been generally accepted? Is it worth of refreshing against
> > current linux-omap?
>
> I'll just mark patches "Awaiting upstream" if I feel like somebody else
> should ack or merge it. If there are obvious changes needed, I'll mark
> it "Changes requested".
>
> So for the patch, please refresh. Then let's apply it assuming Jarkko
> acks it.
>
Yep, I was aware of this Janusz's patch and was thinking that it could
help also for developing the McBSP context save/restore features.

> > > > + OMAP_MCBSP_WRITE(io_base, SPCR2, reg_cache->spcr2 = config->spcr2);
> > > > + OMAP_MCBSP_WRITE(io_base, SPCR1, reg_cache->spcr1 = config->spcr1);
...
> > > > - mcbsp->rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1) >> 5) & 0x7;
> > > > - mcbsp->tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1) >> 5) & 0x7;
> > > > + mcbsp->rx_word_length = (reg_cache->rcr1 >> 5) & 0x7;
> > > > + mcbsp->tx_word_length = (reg_cache->xcr1 >> 5) & 0x7;

IMO these would be cleaner if you embed cache handling into read and
write functions only. Probably reading could have explicit _read and
read_cache functions when code is dealing with the status bits and when
just updating some cached bits.

--
Jarkko