All of lore.kernel.org
 help / color / mirror / Atom feed
From: Meador Inge <meador_inge@mentor.com>
To: Yoder Stuart-B08248 <B08248@freescale.com>
Cc: "Blanchard, Hollis" <Hollis_Blanchard@mentor.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
Date: Thu, 27 Jan 2011 17:50:32 -0600	[thread overview]
Message-ID: <4D4204C8.9040905@mentor.com> (raw)
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150307A5C8@039-SN1MPN1-004.039d.mgd.msft.net>

On 01/20/2011 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Meador Inge [mailto:meador_inge@mentor.com]
>> Sent: Wednesday, January 19, 2011 6:08 PM
>> To: Yoder Stuart-B08248
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; devicetree-
>> discuss@lists.ozlabs.org; Blanchard, Hollis
>> Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
>>
>> On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote:
>>>
>>>> +** Optional properties:
>>>> +
>>>> +   - no-reset : The presence of this property indicates that the MPIC
>>>> +                should not be reset during runtime initialization.
>>>> +   - protected-sources : Specifies a list of interrupt sources that
>>>> + are not
>>>> +                         available for use and whose corresponding
>>>> + vectors
>>>> +                         should not be initialized.  A typical use
>>>> + case for
>>>> +                         this property is in AMP systems where multiple
>>>> +                         independent operating systems need to share
>>>> + the MPIC
>>>> +                         without clobbering each other.
>>>
>>> Is "protected-sources" really needed for AMP systems to tell the OSes
>>> not to clobber each other?  Won't each OS be given a device tree with
>>> only its interrupt sources?  ...so you know what you are allowed to
>>> touch.
>>
>> This was discussed a little bit already [1, 2].  The MPIC driver currently
>> initializes the VECPRI register for all interrupt sources, which can lead
>> to the aforementioned clobbering.
>
> For sources that are protected and not to be touched, it seems
> that the other need is for the OS to know (be guaranteed?) that
> those sources have been put in state where the source is masked
> or directed to other cores.   You can't have interrupts occurring
> on sources that you are not allowed to initialize.
>
> So the "no-reset" property could potentially cover this as well-- if it was
> defined to mean "don't reset the mpic" and boot firmware has put all sources
> in a sane initial state.   And we wouldn't need the "protected-sources"
> property any longer.
>

This seems reasonable to me.  If "no-reset" is there, then we will not 
reset the MPIC and *only* sources explicitly listed in "interrupts" 
properties are up for any sort of initialization (e.g. the VECPRI init). 
   If "no-reset" is not there, then anything is free game.

In terms of implementation, I think we can (1) pull the protected 
sources code, (2) keep the VECPRI initialization in 'mpic_init' from 
happening when "no-reset" is present, and (3) "lazily" perform the 
VECPRI initialization in 'mpic_host_map' (this way only sources 
mentioned in the device tree are initialized).

I will send out a patch with these updates tomorrow.  I also CC'd Ben, 
who wrote the original protected sources work, to make sure something 
about the original use case is not being missed.

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

WARNING: multiple messages have this Message-ID (diff)
From: Meador Inge <meador_inge-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Yoder Stuart-B08248 <B08248-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: "Blanchard,
	Hollis"
	<Hollis_Blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
	Wood Scott-B07421
	<B07421-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
	"linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
	<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
Date: Thu, 27 Jan 2011 17:50:32 -0600	[thread overview]
Message-ID: <4D4204C8.9040905@mentor.com> (raw)
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150307A5C8-TcFNo7jSaXM0vywKSws3iq4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org>

On 01/20/2011 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Meador Inge [mailto:meador_inge-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org]
>> Sent: Wednesday, January 19, 2011 6:08 PM
>> To: Yoder Stuart-B08248
>> Cc: Wood Scott-B07421; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; devicetree-
>> discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Blanchard, Hollis
>> Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
>>
>> On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote:
>>>
>>>> +** Optional properties:
>>>> +
>>>> +   - no-reset : The presence of this property indicates that the MPIC
>>>> +                should not be reset during runtime initialization.
>>>> +   - protected-sources : Specifies a list of interrupt sources that
>>>> + are not
>>>> +                         available for use and whose corresponding
>>>> + vectors
>>>> +                         should not be initialized.  A typical use
>>>> + case for
>>>> +                         this property is in AMP systems where multiple
>>>> +                         independent operating systems need to share
>>>> + the MPIC
>>>> +                         without clobbering each other.
>>>
>>> Is "protected-sources" really needed for AMP systems to tell the OSes
>>> not to clobber each other?  Won't each OS be given a device tree with
>>> only its interrupt sources?  ...so you know what you are allowed to
>>> touch.
>>
>> This was discussed a little bit already [1, 2].  The MPIC driver currently
>> initializes the VECPRI register for all interrupt sources, which can lead
>> to the aforementioned clobbering.
>
> For sources that are protected and not to be touched, it seems
> that the other need is for the OS to know (be guaranteed?) that
> those sources have been put in state where the source is masked
> or directed to other cores.   You can't have interrupts occurring
> on sources that you are not allowed to initialize.
>
> So the "no-reset" property could potentially cover this as well-- if it was
> defined to mean "don't reset the mpic" and boot firmware has put all sources
> in a sane initial state.   And we wouldn't need the "protected-sources"
> property any longer.
>

This seems reasonable to me.  If "no-reset" is there, then we will not 
reset the MPIC and *only* sources explicitly listed in "interrupts" 
properties are up for any sort of initialization (e.g. the VECPRI init). 
   If "no-reset" is not there, then anything is free game.

In terms of implementation, I think we can (1) pull the protected 
sources code, (2) keep the VECPRI initialization in 'mpic_init' from 
happening when "no-reset" is present, and (3) "lazily" perform the 
VECPRI initialization in 'mpic_host_map' (this way only sources 
mentioned in the device tree are initialized).

I will send out a patch with these updates tomorrow.  I also CC'd Ben, 
who wrote the original protected sources work, to make sure something 
about the original use case is not being missed.

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

  reply	other threads:[~2011-01-27 23:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-18  0:52 [PATCH 1/2] powerpc: document the MPIC device tree binding Meador Inge
2011-01-18  0:52 ` Meador Inge
     [not found] ` <AANLkTi=QX4BfLvPfQDMOgmh90TtX4MQqio6AOZR8JKas@mail.gmail.com>
2011-01-18 20:21   ` Yoder Stuart-B08248
2011-01-18 20:21     ` Yoder Stuart-B08248
2011-01-19 20:24     ` Meador Inge
2011-01-19 20:38       ` Yoder Stuart-B08248
2011-01-19 20:38         ` Yoder Stuart-B08248
2011-01-19 22:14   ` Yoder Stuart-B08248
2011-01-19 22:14     ` Yoder Stuart-B08248
2011-01-20  0:08     ` Meador Inge
2011-01-20  0:08       ` Meador Inge
2011-01-20 15:50       ` Yoder Stuart-B08248
2011-01-20 15:50         ` Yoder Stuart-B08248
2011-01-27 23:50         ` Meador Inge [this message]
2011-01-27 23:50           ` Meador Inge
2011-01-18 20:31 ` Scott Wood

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=4D4204C8.9040905@mentor.com \
    --to=meador_inge@mentor.com \
    --cc=B07421@freescale.com \
    --cc=B08248@freescale.com \
    --cc=Hollis_Blanchard@mentor.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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.