On Feb 16, 2012, at 8:49 PM, Jia Hongtao 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 me
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
On 05/06/2011 02:29 PM, Scott Wood wrote:
> On Thu, 5 May 2011 16:41:29 -0500
>
> How can both OSes independently own registers 1 and 3 for alloction?
They can't. I just choose a horrible example. It does point to a serious
flaw (which you allude to later) in inferring free registers from send/
On Thu, 5 May 2011 16:41:29 -0500
Meador Inge wrote:
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask
On 05/03/2011 10:19 AM, Scott Wood wrote:
> In the absence of partitioning, no driver should need a specific one. With
> partitioning, let the system designer mark those resources as reserved so
> they don't get allocated. :-)
That seem reasonable. Back to the device tree then. One option is to
On Mon, 2 May 2011 09:03:53 -0700
Hollis Blanchard wrote:
> On 05/01/2011 08:41 PM, Kushwaha Prabhakar-B32579 wrote:
> >> Perhaps an allocator could be added in the same patchset that adds such a
> >> user.
> > Yaa. It can be done. Otherwise module has to query each message unit for
> > its avai
On 05/01/2011 08:41 PM, Kushwaha Prabhakar-B32579 wrote:
Hi,
I have no comments about coding and architecture. It looks fine.
Only have a query about its use case..
"Any application intended to use message interrupt requires to
know
reg_num because of struct mpic_msgr* mpic_msgr_get(unsign
>
> >
> >
> > > > Hi,
> > > >
> > > > I have no comments about coding and architecture. It looks fine.
> > > >
> > > > Only have a query about its use case..
> > > >"Any application intended to use message interrupt requires to
> > > > know
> > > reg_num because of struct mpic_msgr* mpic_msg
On Fri, 29 Apr 2011 17:27:06 +
Kushwaha Prabhakar-B32579 wrote:
>
>
> > > Hi,
> > >
> > > I have no comments about coding and architecture. It looks fine.
> > >
> > > Only have a query about its use case..
> > >"Any application intended to use message interrupt requires to know
> > reg_
> > Hi,
> >
> > I have no comments about coding and architecture. It looks fine.
> >
> > Only have a query about its use case..
> >"Any application intended to use message interrupt requires to know
> reg_num because of struct mpic_msgr* mpic_msgr_get(unsigned int reg_num)
> API"
> >
> > It w
On 04/28/2011 10:00 PM, Kushwaha Prabhakar-B32579 wrote:
Hi,
I have no comments about coding and architecture. It looks fine.
Only have a query about its use case..
"Any application intended to use message interrupt requires to know reg_num
because of struct mpic_msgr* mpic_msgr_get(unsigne
org]
> On Behalf Of Meador Inge
> Sent: Tuesday, April 19, 2011 10:30 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: openmcapi-...@googlegroups.com; devicetree-disc...@lists.ozlabs.org;
> Hollis Blanchard
> Subject: [PATCH 2/2] powerpc: add support for MPIC message register API
>
&g
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
13 matches
Mail list logo
