From: Jarkko Nikula <jhnikula@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache
Date: Tue, 24 Nov 2009 09:59:23 +0200 [thread overview]
Message-ID: <20091124095923.4f60044c.jhnikula@gmail.com> (raw)
In-Reply-To: <20091123235355.GJ22923@atomide.com>
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
next prev parent reply other threads:[~2009-11-24 7:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-12 10:39 [RFC][PATCH] ARM: OMAP: McBSP: Use register cache Janusz Krzysztofik
2009-08-28 11:26 ` Janusz Krzysztofik
2009-08-28 11:26 ` Janusz Krzysztofik
2009-11-14 2:06 ` Janusz Krzysztofik
2009-11-14 2:06 ` Janusz Krzysztofik
2009-11-23 20:42 ` Janusz Krzysztofik
2009-11-23 23:53 ` Tony Lindgren
2009-11-24 7:59 ` Jarkko Nikula [this message]
2009-11-24 11:31 ` [RFC][PATCH v2] " Janusz Krzysztofik
2009-11-26 8:00 ` Jarkko Nikula
2009-11-26 13:25 ` Janusz Krzysztofik
2009-11-28 16:14 ` Jarkko Nikula
-- strict thread matches above, loose matches on Subject: below --
2009-09-04 5:39 [RFC][PATCH] ARM: " Eero Nurkkala
2009-09-04 10:34 ` Janusz Krzysztofik
2009-09-04 11:07 ` Eero Nurkkala
2009-09-05 17:31 ` Anuj Aggarwal
2009-09-05 20:46 ` ext-Eero.Nurkkala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091124095923.4f60044c.jhnikula@gmail.com \
--to=jhnikula@gmail.com \
--cc=jkrzyszt@tis.icnet.pl \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.