[PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset"
meador_inge at mentor.com
Sat Feb 12 04:35:41 EST 2011
On 02/11/2011 08:58 AM, Yoder Stuart-B08248 wrote:
>> -----Original Message-----
>> From: Meador Inge [mailto:meadori at gmail.com]
>> Sent: Thursday, February 10, 2011 9:26 PM
>> To: Benjamin Herrenschmidt
>> Cc: Yoder Stuart-B08248; devicetree-discuss at lists.ozlabs.org; linuxppc-
>> dev at lists.ozlabs.org
>> Subject: Re: [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset"
>> Apologies for the bad post. Bad day for email ... Please ignore the top
>> reply in my previous reply. The full reply is the below the quote.
>> On Thu, Feb 10, 2011 at 8:01 PM, Meador Inge<meador_inge at mentor.com>
>>> On 02/10/2011 02:42 PM, Meador Inge wrote:
>>>> ---------- Forwarded message ----------
>>>> From: Meador Inge<meador_inge at mentor.com>
>>>> Date: Fri, Feb 4, 2011 at 5:25 PM
>>>> Subject: [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset"
>>>> To: linuxppc-dev at lists.ozlabs.org
>>>> Cc: devicetree-discuss at lists.ozlabs.org, Hollis Blanchard<
>>>> hollis_blanchard at mentor.com>
>>>> This patch set provides a binding for Open PIC and implements support
>>>> for a new property, specified by that binding, called "pic-no-reset".
>>>> With "pic-no-reset" in place the "protected-sources" property is no
>>>> longer needed and its full implementation was removed.
>>>> "protected-sources" is still checked for, however, for legacy
>>>> For v3 of this patch the Open PIC binding was changed to be more
>>>> consistent with existing bindings, several DTS files were cleaned up,
>>>> "no-reset" was changed to "pic-no-reset", and a check to treat
>>>> "protected-sources" as a synonym for "pic-no-reset" was added.
>> From the feedback I have received so far, the fundamental ideas in this
>> patch set are sane. However, the following issues still need agreement:
>> 1. What should be the name of the no reset property?
>> "pic-no-reset" or "no-reset"?
>> 2. Should we just keep the existing protected sources implementation
>> in place?
>> For (1), I prefer "no-reset".
> I also prefer plain "no-reset". The property is on a pic node so
> "pic" on the property seems redundant.
>> For (2), I still think that we can make "no-
>> reset" a synonym for "protected-sources" and that things will work out.
>> Ben, you said that you would really like to leave the protected sources
>> implementation alone. Is the mechanism implemented in "PATCH
>> v3 3/4"  of having "protected-sources" as a synonym for "pic-no-reset"
>> not suitable?
> I thought what Ben was getting at was that there is existing
> firmware that may provide a device tree with protected-sources,
> and thus we should continue supporting it for backwards
Yup, Arnd pointed that out as well. That is why in "PATCH v3 3/4" I
added a check for "protected-sources". If it is found, then it is
treated exactly the same way as "no-reset", which should give equivalent
For example, say we have 100 sources and the sources [1, 50] are the
only ones actually mentioned in the device tree. Also assume we set
"protected-sources = <51 52 53>".
Then, with the protected sources model sources [1, 50] and [54, 100]
would have there VECPRI/cpu binding initialization. Where as in the
enhanced "no-reset" model, only sources [1, 50] would have the
So unless there is some problem with not initializing the remaining
sources, e.g. sources [51, 100] in the previous example, then the
expanded "no-reset" should offer equivalent behavior to "protected-sources".
> So, I would say add "no-reset" as the preferred mechanism
> going forward, but keep "protected-sources" for backwards
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
More information about the Linuxppc-dev