From: Jarkko Nikula <jhnikula@gmail.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: Tony Lindgren <tony@atomide.com>,
Peter Ujfalusi <peter.ujfalusi@nokia.com>,
linux-omap@vger.kernel.org
Subject: Re: [PATCH v7 5/5] OMAP: McBSP: Split and move read/write functions to mach-omap1/2
Date: Fri, 11 Dec 2009 15:21:16 +0200 [thread overview]
Message-ID: <20091211152116.4c471dca.jhnikula@gmail.com> (raw)
In-Reply-To: <200912092134.32015.jkrzyszt@tis.icnet.pl>
On Wed, 9 Dec 2009 21:34:30 +0100
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:
> > > > 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!
> >
...
> diff -upr git.orig/arch/arm/mach-omap1/mcbsp.c git/arch/arm/mach-omap1/mcbsp.c
> --- git.orig/arch/arm/mach-omap1/mcbsp.c 2009-12-09 15:49:52.000000000 +0100
> +++ git/arch/arm/mach-omap1/mcbsp.c 2009-12-09 16:20:43.000000000 +0100
>
> +void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
...
> diff -upr git.orig/arch/arm/mach-omap2/mcbsp.c git/arch/arm/mach-omap2/mcbsp.c
> --- git.orig/arch/arm/mach-omap2/mcbsp.c 2009-12-09 15:49:52.000000000 +0100
> +++ git/arch/arm/mach-omap2/mcbsp.c 2009-12-09 16:20:43.000000000 +0100
>
> +void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
These functions must be unique, otherwise multi-build is not possible
(no idea can we do it for OMAP1?).
IMO, the _write and _read functions in ./plat-omap/mcbsp.c are clean
after the patch 3/5 anyway so probably we don't need this splitting?
--
Jarkko
next prev parent reply other threads:[~2009-12-11 13:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-09 20:24 [PATCH v7 0/5] OMAP: McBSP: Use register cache Janusz Krzysztofik
2009-12-09 20:27 ` [PATCH v7 1/5] OMAP: McBSP: Use macros for all register read/write operations Janusz Krzysztofik
2009-12-09 20:29 ` [PATCH v7 2/5] OMAP: McBSP: Modify macros/functions API for easy cache access Janusz Krzysztofik
2009-12-09 20:40 ` [PATCH v7 2/5] [Resend] " Janusz Krzysztofik
2009-12-11 14:10 ` [PATCH v7 2/5] " Varadarajan, Charu Latha
2009-12-11 15:42 ` Janusz Krzysztofik
2009-12-14 6:05 ` Varadarajan, Charu Latha
2009-12-14 10:11 ` Janusz Krzysztofik
2009-12-14 11:14 ` Jarkko Nikula
2009-12-14 19:36 ` Tony Lindgren
2009-12-22 8:58 ` Varadarajan, Charu Latha
2010-01-06 12:03 ` Janusz Krzysztofik
2009-12-09 20:31 ` [PATCH v7 3/5] OMAP: McBSP: Introduce caching in register write operations Janusz Krzysztofik
2009-12-11 13:11 ` Jarkko Nikula
2009-12-11 13:51 ` Janusz Krzysztofik
2009-12-15 0:36 ` [PATCH 3/5 v8] " Janusz Krzysztofik
2009-12-16 8:12 ` Jarkko Nikula
2009-12-09 20:33 ` [PATCH v7 4/5] OMAP: McBSP: Use cache when modifying individual register bits Janusz Krzysztofik
2009-12-09 20:34 ` [PATCH v7 5/5] OMAP: McBSP: Split and move read/write functions to mach-omap1/2 Janusz Krzysztofik
2009-12-11 13:21 ` Jarkko Nikula [this message]
2009-12-11 13:57 ` Janusz Krzysztofik
2009-12-16 8:02 ` [PATCH v7 0/5] OMAP: McBSP: Use register cache Peter Ujfalusi
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=20091211152116.4c471dca.jhnikula@gmail.com \
--to=jhnikula@gmail.com \
--cc=jkrzyszt@tis.icnet.pl \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@nokia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox