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 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.