On Mon, 23 Nov 2009 15:53:55 -0800 Tony Lindgren <tony@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
