linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Meador Inge <meador_inge@mentor.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Hollis Blanchard <hollis_blanchard@mentor.com>,
	Kushwaha Prabhakar-B32579 <B32579@freescale.com>,
	"openmcapi-dev@googlegroups.com" <openmcapi-dev@googlegroups.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 2/2] powerpc: add support for MPIC message register API
Date: Thu, 05 May 2011 16:41:29 -0500	[thread overview]
Message-ID: <4DC31989.8080703@mentor.com> (raw)
In-Reply-To: <20110503101921.45f31d34@schlenkerla.am.freescale.net>

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 bring
back the sister-send property 'mpic-msgr-send-mask', which was discussed some
months back.  For example, consider:

	/* 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 = <0x5>;
		mpic-msgr-send-mask = <0xa>;
	};

	mpic_msgr_block1: mpic-msgr-block@42400 {
		compatible = "fsl,mpic-v3.1-msgr";
		reg = <0x42400 0x200>;
		interrupts = <0xb4 2 0xb6 2>;
		mpic-msgr-receive-mask = <0x5>;
	};

	/* OS 2 */
	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 = <0xa>;
		mpic-msgr-send-mask = <0x5>;
	};

	mpic_msgr_block1: mpic-msgr-block@42400 {
		compatible = "fsl,mpic-v3.1-msgr";
		reg = <0x42400 0x200>;
		interrupts = <0xb4 2 0xb6 2>;
		mpic-msgr-send-mask = <0x5>;
	};

In block0 for both OSes, all registers are partitioned and are thus not
available for allocation.  In block1 for both OSes, registers 0 and 2 are
reserved and registers 1 and 3 are available for general allocation.

So any register mentioned in one of 'mpic-msgr-receive-mask' or
'mpic-msgr-send-mask' is out of the running for general allocation.
If neither of the properties appear, then all registers are available
for general allocation.

You could get into trouble with this method with cases like:

	/* 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-send-mask = <0xa>;
	};

	/* OS 2 */
	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 = <0x5>;
	};

Now OS 1 has registers 0 and 2 available for general allocation, which
OS 2 is receiving on.  However, we already have that problem if someone
botches the masks.  So I am not very worried about that.

Clearly this is just one method, but I think tagging what is available from the
device tree is a must.


Thoughts?


-- 
Meador Inge     | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software

  reply	other threads:[~2011-05-05 21:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19 16:59 [PATCH 0/2] powerpc: define and implement MPIC message register support Meador Inge
2011-04-19 16:59 ` [PATCH 1/2] powerpc: document the FSL MPIC message register binding Meador Inge
2011-04-19 17:52   ` Scott Wood
2011-04-19 18:26     ` Meador Inge
2011-04-19 18:33       ` Scott Wood
2011-04-21 19:26         ` Meador Inge
2011-04-21 19:35           ` Scott Wood
2011-04-19 16:59 ` [PATCH 2/2] powerpc: add support for MPIC message register API Meador Inge
2011-04-29  5:00   ` Kushwaha Prabhakar-B32579
2011-04-29 16:54     ` Hollis Blanchard
2011-04-29 17:27       ` Kushwaha Prabhakar-B32579
2011-04-29 17:30         ` Scott Wood
2011-05-02  3:41           ` Kushwaha Prabhakar-B32579
2011-05-02 16:03             ` Hollis Blanchard
2011-05-03 15:19               ` Scott Wood
2011-05-05 21:41                 ` Meador Inge [this message]
2011-05-06 19:29                   ` Scott Wood
2011-05-06 23:51                     ` Meador Inge
  -- strict thread matches above, loose matches on Subject: below --
2012-02-17  2:49 [PATCH 1/2] powerpc: document the FSL MPIC message register binding Jia Hongtao
2012-02-17  2:49 ` [PATCH 2/2] powerpc: add support for MPIC message register API Jia Hongtao
2012-03-21 17:21   ` Kumar Gala

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=4DC31989.8080703@mentor.com \
    --to=meador_inge@mentor.com \
    --cc=B07421@freescale.com \
    --cc=B32579@freescale.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=hollis_blanchard@mentor.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=openmcapi-dev@googlegroups.com \
    --cc=scottwood@freescale.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).