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 v6] OMAP: McBSP: Introduce caching in register write operations
Date: Tue, 8 Dec 2009 08:40:28 -0800 [thread overview]
Message-ID: <20091208164028.GQ24013@atomide.com> (raw)
In-Reply-To: <200912081707.39812.jkrzyszt@tis.icnet.pl>
Hi,
Almost there :) Just one more comment below.
* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [091208 08:06]:
> Allocate space for storing cached copies of McBSP register values.
> 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>
>
> ---
> Monday 07 December 2009 22:06:31 Tony Lindgren wrote:
> >
> > Well if you want to optimize it out further, how about just kzalloc it
> > during init? Then you have just one copy that gets set the right size
> > depending on what you boot.
>
> Tony,
> In v4 of the patch, a single table was actually kzalloced during init as a
> part of struct omap_mcbsp for each McBSP port configured. Since you objected
> it, and the reason was not quite obvious to me, I submitted two alternate
> versions: 5a, with ifdef...else cleanup, maybe still not good enough but
> keeping that dynamic allocation, and 5b, using static storage instead, since I
> could suspect you may like it better. Now it appears not quite true.
>
> Anyway, sorry for all that long discussion, but it's really important for me
> to understand precisely what your concearns, goals and preferences are when
> you request changes before I'm able to implement them correctly, ie. in an way
> acceptable for you. Otherwise, it all turns into a kind of quiz.
Yeah, thanks for considering all the issues, hopefully it will make
things easier for us in the long run.
> Tuesday 08 December 2009 08:35:21 Jarkko Nikula wrote:
> >
> > How about declaring the reg_cache as a void pointer in struct
> > omap_mcbsp and allocate the cache and its size in omap_mcbsp_request
> > according to omap type? Read and write functions would access the
> > *reg_cache either as 16-bit or 32-bit table depending on omap.
> >
> > No ifdefs, no unused cache tables in multi-omap binary and cache tables
> > are allocated only for used ports. I don't think there is need to
> > preserve cache content over omap_mcbsp_free and new omap_mcbsp_request?
>
> Jarkko,
> I think this is the best solution. I had almost already sent a modified
> version last night, with two pointers, u16 *omap1_cache and u32 *omap2_cache,
> inside omap_mcbsp structre, but now I think that if using casts inside
> omap_mcbsp_read()/_write() is not objected by anyone, the version below,
> based on your idea, seems the most clean one.
>
> I was not sure about deferring memory allocation until omap_mcbsp_request(),
> but if you say it should be ok, I'm all in favour of that.
>
> Note: 2420 handling may look weird, but I just tried to follow exactly what I
> was able to learn about it by reading the code: register address spacing
> were 32-bit, register read/write operations - 16-bit, since u16 reg_cache
> elements.
>
> Thanks,
> Janusz
>
> arch/arm/plat-omap/include/plat/mcbsp.h | 9 ++++++
> arch/arm/plat-omap/mcbsp.c | 66 +++++++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 63 insertions(+), 12 deletions(-)
>
> diff -upr git.orig/arch/arm/plat-omap/include/plat/mcbsp.h git/arch/arm/plat-omap/include/plat/mcbsp.h
> --- git.orig/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-02 15:48:51.000000000 +0100
> +++ git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-12-08 14:26:42.000000000 +0100
> @@ -157,6 +157,14 @@
>
> #endif
>
> +#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
> +#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
> +#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
> +
> +#define OMAP24XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
> +#define OMAP34XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
> +#define OMAP44XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
> +
> /************************** McBSP SPCR1 bit definitions ***********************/
> #define RRST 0x0001
> #define RRDY 0x0002
> @@ -415,6 +423,7 @@ struct omap_mcbsp {
> u16 max_tx_thres;
> u16 max_rx_thres;
> #endif
> + void *reg_cache;
> };
> extern struct omap_mcbsp **mcbsp_ptr;
> extern int omap_mcbsp_count;
> diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
> --- git.orig/arch/arm/plat-omap/mcbsp.c 2009-12-07 22:43:56.000000000 +0100
> +++ git/arch/arm/plat-omap/mcbsp.c 2009-12-08 14:38:38.000000000 +0100
> @@ -30,26 +30,40 @@
> struct omap_mcbsp **mcbsp_ptr;
> int omap_mcbsp_count;
>
> -void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
> +void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
> {
> - if (cpu_class_is_omap1() || cpu_is_omap2420())
> - __raw_writew((u16)val, io_base + reg);
> - else
> - __raw_writel(val, io_base + reg);
> + if (cpu_class_is_omap1()) {
> + ((u16 *)mcbsp->reg_cache)[reg / sizeof(u16)] = (u16)val;
> + __raw_writew((u16)val, mcbsp->io_base + reg);
> + } else if (cpu_is_omap2420()) {
> + ((u16 *)mcbsp->reg_cache)[reg / sizeof(u32)] = (u16)val;
> + __raw_writew((u16)val, mcbsp->io_base + reg);
> + } else {
> + ((u32 *)mcbsp->reg_cache)[reg / sizeof(u32)] = val;
> + __raw_writel(val, mcbsp->io_base + reg);
> + }
> }
>
> -int omap_mcbsp_read(void __iomem *io_base, u16 reg)
> +int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg, bool from_cache)
> {
> - if (cpu_class_is_omap1() || cpu_is_omap2420())
> - return __raw_readw(io_base + reg);
> - else
> - return __raw_readl(io_base + reg);
> + if (cpu_class_is_omap1()) {
> + return !from_cache ? __raw_readw(mcbsp->io_base + reg) :
> + ((u16 *)mcbsp->reg_cache)[reg / sizeof(u16)];
> + } else if (cpu_is_omap2420()) {
> + return !from_cache ? __raw_readw(mcbsp->io_base + reg) :
> + ((u16 *)mcbsp->reg_cache)[reg / sizeof(u32)];
> + } else {
> + return !from_cache ? __raw_readl(mcbsp->io_base + reg) :
> + ((u32 *)mcbsp->reg_cache)[reg / sizeof(u32)];
> + }
> }
>
> #define MCBSP_READ(mcbsp, reg) \
> - omap_mcbsp_read(mcbsp->io_base, OMAP_MCBSP_REG_##reg)
> + omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg, 0)
> #define MCBSP_WRITE(mcbsp, reg, val) \
> - omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, val)
> + omap_mcbsp_write(mcbsp, OMAP_MCBSP_REG_##reg, val)
> +#define MCBSP_READ_CACHE(mcbsp, reg) \
> + omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg, 1)
>
> #define omap_mcbsp_check_valid_id(id) (id < omap_mcbsp_count)
> #define id_to_mcbsp_ptr(id) mcbsp_ptr[id];
> @@ -391,6 +405,31 @@ int omap_mcbsp_request(unsigned int id)
> }
> mcbsp = id_to_mcbsp_ptr(id);
>
> + if (cpu_is_omap7xx()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u16) *
> + OMAP7XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap15xx()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u16) *
> + OMAP15XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap16xx()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u16) *
> + OMAP16XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap2420()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u16) *
> + OMAP24XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap2430()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u32) *
> + OMAP24XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap34xx()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u32) *
> + OMAP34XX_MCBSP_REG_NUM, GFP_KERNEL);
> + } else if (cpu_is_omap44xx()) {
> + mcbsp->reg_cache = kzalloc(sizeof(u32) *
> + OMAP44XX_MCBSP_REG_NUM, GFP_KERNEL);
> + }
How about just set the cache size above based on the processor,
then do kzalloc here:
mcbsp->reg_cache = kzalloc(size, GFP_KERNEL);
> + if (!mcbsp->reg_cache)
> + return -ENOMEM;
> +
That way the kzalloc and error checking are in the same place.
Regards,
Tony
next prev parent reply other threads:[~2009-12-08 16:40 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
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 [this message]
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=20091208164028.GQ24013@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.