linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Meador Inge <meador_inge@mentor.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: openmcapi-dev@googlegroups.com,
	Hollis Blanchard <hollis_blanchard@mentor.com>,
	devicetree-discuss@lists.ozlabs.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [openmcapi-dev] Re: [PATCH v3 2/2] powerpc: add support for MPIC message register API
Date: Wed, 29 Jun 2011 22:04:20 -0500	[thread overview]
Message-ID: <4E0BE7B4.1020901@mentor.com> (raw)
In-Reply-To: <1308288784.32158.30.camel@pasglop>

On 06/17/2011 12:33 AM, Benjamin Herrenschmidt wrote:

> On Tue, 2011-05-31 at 14:19 -0500, Meador Inge wrote:
>> Some MPIC implementations contain one or more blocks of message registers
>> that are used to send messages between cores via IPIs.  A simple API has
>> been added to access (get/put, read, write, etc ...) these message registers.
>> The available message registers are initially discovered via nodes in the
>> device tree.  A separate commit contains a binding for the message register
>> nodes.

<snip>

> 
> Ok, so we have another scheme of:
> 
>  - Count all devices in the system of a given type
>  - Assign them numbers
>  - API uses number
> 
> That sucks... unless you have an allocator. And even then.
> 
> I'd rather clients use something like struct mpic_msgr (or msg_reg or
> message_reg) as the "handle" to one of these things.
> 
> It can be obtained via an allocator or a device tree parsing routine if
> there's a fixed relationship between clients and registers, I don't
> really know how that stuff is to be used, but in any case, the whole
> thing stinks as it is.

Ben,

I posted a more detailed response a few days back:
http://patchwork.ozlabs.org/patch/98075/.  In
that response, I tried to put forth the rationale
for allocating the registers statically due to
the AMP use case.  With that in mind, do you
still disagree with the design?  If so, do
you have any suggestions for how it could be
better?

-- 
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software

  parent reply	other threads:[~2011-06-30  3:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-31 19:19 [PATCH v3 0/2] powerpc: define and implement MPIC message register support Meador Inge
2011-05-31 19:19 ` [PATCH v3 1/2] powerpc: document the FSL MPIC message register binding Meador Inge
2011-05-31 19:23   ` Scott Wood
2011-06-02 14:33     ` Meador Inge
2011-05-31 19:19 ` [PATCH v3 2/2] powerpc: add support for MPIC message register API Meador Inge
2011-06-17  5:33   ` Benjamin Herrenschmidt
2011-06-17 13:49     ` [openmcapi-dev] " Meador Inge
2011-06-17 16:58     ` Scott Wood
2011-06-17 22:58       ` Benjamin Herrenschmidt
2011-06-20 15:59         ` Scott Wood
2011-06-21  7:47           ` Benjamin Herrenschmidt
2011-06-30  3:04     ` Meador Inge [this message]
2011-06-30  4:19       ` [openmcapi-dev] " Benjamin Herrenschmidt
2011-06-09 14:44 ` [openmcapi-dev] [PATCH v3 0/2] powerpc: define and implement MPIC message register support Meador Inge

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=4E0BE7B4.1020901@mentor.com \
    --to=meador_inge@mentor.com \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=hollis_blanchard@mentor.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=openmcapi-dev@googlegroups.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;
as well as URLs for NNTP newsgroup(s).