public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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: [PATCH 3/4 v4] OMAP: McBSP: Introduce caching in register write operations
Date: Fri, 4 Dec 2009 11:17:45 -0800	[thread overview]
Message-ID: <20091204191745.GH24013@atomide.com> (raw)
In-Reply-To: <4B19074B.1000606@tis.icnet.pl>

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [091204 04:56]:
> Janusz Krzysztofik napisał(a):

<snip>
 
> I think I've already found one part of the answer myself: you
> probably mean putting each table definition in a corresponding
> arch/arm/mach-omap[12]/mcbsp.c source file, don't you?

Well I did not initially, but sounds like that's the cleanest
way to go.
 
> What remains unclear for me is if you really intend to reserve
> static cache space for all McBSP ports supported by a machine, even
> if not supported by a particular cpu or not used on a particular
> board.

No idea :) But please consider what happens if we want to compile in
omap2 + omap3 into a single binary. Or what happens if some newer omaps
add more McBSP registers.

<snip>
 
> >
> >Did you mean defining a new omap_mcbsp_read_cache() function,
> >similiar to omap_mcbsp_read(), but reading from cache instead of
> >hardware?

Yeah something like that. That is more future proof.

> >Or do you prefere if I modify omap_mcbsp_read() to be able to read
> >from both hardware and cache, dependig on an additional argument,
> >for example?

That actually sounds like the best way to solve it to me!

> But shouldn't declarations for both tables be placed in
> arch/arm/plat-omap/include/plat/mcbsp.h withing an ifdef else block?
> If yes, one ifdef else block would be replaced with another. Or did
> you mean placing those declarations inside existing ifdef block with
> defines for register offsets?

Ifdefs are OK if they just optimize out code when some omap is not
compiled in. But if you do ifdef else, then it means trouble sooner
or later. In this case you should probably have the cache initialized
separately in mach-omap1/mcbsp.c and mach-omap2/mcbsp.c.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-12-04 19:17 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 [this message]
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
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=20091204191745.GH24013@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