From: Tony Lindgren <tony@atomide.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: Jarkko Nikula <jhnikula@gmail.com>,
linux-omap@vger.kernel.org,
Peter Ujfalusi <peter.ujfalusi@nokia.com>
Subject: Re: [RFC][RFT][PATCH 3/4 v5b] OMAP: McBSP: Introduce caching in register write operations
Date: Mon, 7 Dec 2009 09:55:35 -0800 [thread overview]
Message-ID: <20091207175534.GZ24013@atomide.com> (raw)
In-Reply-To: <200912051447.41777.jkrzyszt@tis.icnet.pl>
Hi,
This is pretty close :) Few more tweaks are still needed.
* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [091205 05:46]:
> Reserve static space for storing cached copies of McBSP register values.
> Split omap_mcbsp_read()/omap_mcbsp_write() into separate functions for OMAP1
> and OMAP2/3/4, move them from plat-omap to mach-omap1 / mach-omap2 to be able
> to access the static cache.
> Modify omap_msbcp_write() to update the cache with every register write
> operation.
> Modify omap_mcbsp_read() to support reading from cache or hardware.
> Update MCBSP_READ/MCBSP_WRITE macros for modified function APIs.
> Introduce a new macro that reads from the cache.
>
> Applies on top of patch 2 from this series:
> [PATCH v3 2/4] OMAP: McBSP: Prepare register read/write macros API for caching
>
> Tested on OMAP1510 based Amstrad Delta using linux-omap for-next,
> commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c.
> Compile-tested with omap_generic_2420_defconfig, omap_3430sdp_defconfig.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>
> ---
>
> Tony,
>
> Since I was not sure what your primary concern was, I've prepared two
> alternative versions of patch 3/4.
> Please take this one as a base for further discussion if your primary concern
> was storage class for the cache.
> Otherwise, have a look at the other one (v5a), since this one has even more
> ifdefs than before.
>
> Thanks,
> Janusz
>
> 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-02 15:48:37.000000000 +0100
> +++ git/arch/arm/mach-omap1/mcbsp.c 2009-12-05 06:42:35.000000000 +0100
> @@ -200,3 +200,26 @@ int __init omap1_mcbsp_init(void)
> }
>
> arch_initcall(omap1_mcbsp_init);
> +
> +/* if adding more, put larger first */
> +#if defined(CONFIG_ARCH_OMAP16XX)
> +static u16 omap_mcbsp_cache[OMAP16XX_MCBSP_PDATA_SZ][OMAP_MCBSP_REG_COUNT];
> +#elif defined(CONFIG_ARCH_OMAP15XX)
> +static u16 omap_mcbsp_cache[OMAP15XX_MCBSP_PDATA_SZ][OMAP_MCBSP_REG_COUNT];
> +#elif defined(CONFIG_ARCH_OMAP7XX)
> +static u16 omap_mcbsp_cache[OMAP7XX_MCBSP_PDATA_SZ][OMAP_MCBSP_REG_COUNT];
> +#else
> +#define omap_mcbsp_cache NULL
> +#endif
As 15xx and 16xx can be compiled into the same kernel binary, we need to
get rid of the ifdef elif else (untested):
#ifdef(CONFIG_ARCH_OMAP7XX)
static u16 omap7xx_mcbsp_cache[OMAP7XX_MCBSP_PDATA_SZ][OMAP7XX_MCBSP_REG_COUNT];
#else
static 16 omap7xx_mcbsp_cache;
#endif
#if defined(CONFIG_ARCH_OMAP15XX)
static u16 omap15xx_mcbsp_cache[OMAP15XX_MCBSP_PDATA_SZ][OMAP15XX_MCBSP_REG_COUNT];
#else
static 16 omap15xx_mcbsp_cache;
#endif
#if defined(CONFIG_ARCH_OMAP16XX)
static u16 omap16xx_mcbsp_cache[OMAP16XX_MCBSP_PDATA_SZ][OMAP_16XXMCBSP_REG_COUNT];
#else
static 16 omap16xx_mcbsp_cache;
#endif
...
> +void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
> +{
> + omap_mcbsp_cache[mcbsp->id][reg / sizeof(u16)] = (u16)val;
> + __raw_writew((u16)val, mcbsp->io_base + reg);
> +}
> +
> +int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg, bool from_cache)
> +{
> + return !from_cache ? __raw_readw(mcbsp->io_base + reg) :
> + omap_mcbsp_cache[mcbsp->id][reg / sizeof(u16)];
> +}
Then these can become something like this:
void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
if (cpu_is_omap7xx())
omap7xx_mcbsp_cache[mcbsp->id][reg / sizeof(u16)] = (u16)val;
else if (cpu_is_omap15xx())
omap15xx_mcbsp_cache[mcbsp->id][reg / sizeof(u16)] = (u16)val;
else if (cpu_is_omap16xx())
omap16xx_mcbsp_cache[mcbsp->id][reg / sizeof(u16)] = (u16)val;
__raw_writew((u16)val, mcbsp->io_base + reg);
}
...
The code for processors that are not compiled in will get automatically
optimized out as the cpu_is_xxxx() becomes 0.
Regards,
Tony
next prev parent reply other threads:[~2009-12-07 17:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 3:10 [PATCH v3 0/4] OMAP: McBSP: Use register cache Janusz Krzysztofik
2009-12-01 3:12 ` [PATCH v3 1/4] OMAP: McBSP: Use macros for all register read/write operations Janusz Krzysztofik
2009-12-01 3:26 ` [Resend] " Janusz Krzysztofik
2009-12-01 3:14 ` [PATCH v3 2/4] OMAP: McBSP: Prepare register read/write macros API for caching Janusz Krzysztofik
2009-12-01 3:15 ` [PATCH v3 3/4] OMAP: McBSP: Introduce caching in register write operations Janusz Krzysztofik
2009-12-03 7:49 ` Jarkko Nikula
2009-12-03 12:30 ` [PATCH 3/4 v4] " Janusz Krzysztofik
2009-12-03 20:03 ` Tony Lindgren
2009-12-03 23:18 ` Janusz Krzysztofik
2009-12-04 12:57 ` Janusz Krzysztofik
2009-12-04 19:17 ` Tony Lindgren
2009-12-05 13:46 ` [PATCH 3/4 v5a] " Janusz Krzysztofik
2009-12-05 13:47 ` [RFC][RFT][PATCH 3/4 v5b] " Janusz Krzysztofik
2009-12-07 17:55 ` Tony Lindgren [this message]
2009-12-07 19:39 ` Janusz Krzysztofik
2009-12-07 21:06 ` Tony Lindgren
2009-12-08 7:35 ` Jarkko Nikula
2009-12-08 16:07 ` [RFC][RFT][PATCH 3/4 v6] " Janusz Krzysztofik
2009-12-08 16:40 ` Tony Lindgren
2009-12-08 16:59 ` Tony Lindgren
2009-12-08 19:46 ` Janusz Krzysztofik
2009-12-08 23:32 ` Tony Lindgren
2009-12-08 23:39 ` Tony Lindgren
2009-12-01 3:17 ` [PATCH v3 4/4] OMAP: McBSP: Use cache when modifying individual register bits Janusz Krzysztofik
2009-12-03 12:31 ` [PATCH 4/4 v4] " Janusz Krzysztofik
2009-12-03 7:49 ` [PATCH v3 0/4] OMAP: McBSP: Use register cache Jarkko Nikula
2009-12-03 9:35 ` Peter Ujfalusi
2009-12-03 12:31 ` Janusz Krzysztofik
2009-12-04 6:58 ` 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=20091207175534.GZ24013@atomide.com \
--to=tony@atomide.com \
--cc=jhnikula@gmail.com \
--cc=jkrzyszt@tis.icnet.pl \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@nokia.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