From: Meador Inge <meador_inge@mentor•com>
To: Arnd Bergmann <arnd@arndb•de>
Cc: Hollis Blanchard <hollis_blanchard@mentor•com>,
devicetree-discuss@lists•ozlabs.org,
linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH v2 1/3] powerpc: Removing support for 'protected-sources'
Date: Thu, 03 Feb 2011 17:29:18 -0600 [thread overview]
Message-ID: <4D4B3A4E.2070106@mentor.com> (raw)
In-Reply-To: <201102031656.38222.arnd@arndb.de>
On 02/03/2011 09:56 AM, Arnd Bergmann wrote:
> On Thursday 03 February 2011, Meador Inge wrote:
>> In a recent discussion [1, 2] concerning device trees for AMP systems, the
>> question of whether we really need 'protected-sources' arose. The general
>> consensus was that if you don't want a source to be used, then it should *not*
>> be mentioned in an 'interrupts' property. If a source really needs to be
>> mentioned, then it should be put in a property other than 'interrupts' with
>> a specific binding for that use case.
>>
>> [1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004038.html
>> [2] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/003991.html
>
> That doesn't work in the case that this code was written for:
>
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg01394.html
>
> The problem is that you don't want the mpic to initialize the interrupt
> line to the default, but instead leave it at whatever the boot firmware
> has set up. Note that interrupt is not listed in any "interrupts"
> property of any of the devices on the CPU interpreting the device
> tree, but it may be mentioned in the device tree that another CPU
> uses to access the same MPIC.
>
> Arnd
We touched on that use case before on list. However, I did a really bad
job of explaining things in the above patch description. I understand
that the sources that are being protected are mentioned in a device tree
other than the one that actually interprets the 'protected-sources'
property.
The idea is to try and expand the meaning of the 'no-reset' property to
cover what 'protected-sources' was taking care of, but without
explicitly naming the sources.
In the protected sources version of the code, the relevant MPIC
initialization went something like (in 'mpic_init'):
for (i = 0; i < mpic->num_sources; i++) {
/* start with vector = source number, and masked */
u32 vecpri = MPIC_VECPRI_MASK | i |
(8 << MPIC_VECPRI_PRIORITY_SHIFT);
/* check if protected */
if (mpic->protected && test_bit(i, mpic->protected))
continue;
/* init hw */
mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri);
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
}
So unless a particular source was marked as protected, it would get the
VECPRI and CPU binding initialization. This is the exact behavior that
you describe above, Arnd.
In the 'no-reset' model, the initialization looks more like (see PATCH 3
in the set for the full implementation):
if (mpic->flags & MPIC_WANTS_RESET) {
for (i = 0; i < mpic->num_sources; i++) {
mpic_init_vector(mpic, hw);
}
}
So in 'mpic_init' we don't initialize anything and then in
'mpic_host_map' we lazily do the VECPRI and CPU binding initialization with:
if (!(mpic->flags & MPIC_WANTS_RESET))
if (!(mpic_is_ipi(mpic, hw)
|| mpic_is_timer_interrupt(mpic, hw)))
mpic_init_vector(mpic, hw);
Thus when 'no-reset' is thrown it ensures that only the sources which
are mentioned in the device tree are actually initialized. The net
effect should be the same as what 'protected-sources' was accomplishing,
but without having to maintain the list of sources in the property cell.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
next prev parent reply other threads:[~2011-02-03 23:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-03 1:51 [PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation Meador Inge
2011-02-03 1:51 ` [PATCH v2 1/3] powerpc: Removing support for 'protected-sources' Meador Inge
2011-02-03 15:56 ` Arnd Bergmann
2011-02-03 23:29 ` Meador Inge [this message]
2011-02-04 12:17 ` Arnd Bergmann
2011-02-03 1:51 ` [PATCH v2 2/3] powerpc: document the Open PIC device tree binding Meador Inge
2011-02-03 15:56 ` Grant Likely
2011-02-03 16:29 ` Meador Inge
2011-02-03 16:36 ` Grant Likely
2011-02-03 17:02 ` Yoder Stuart-B08248
2011-02-03 1:51 ` [PATCH v2 3/3] powerpc: make MPIC honor the 'no-reset' device tree property Meador Inge
2011-02-03 15:22 ` [PATCH v2 0/3] powerpc: Open PIC binding and 'no-reset' implementation 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=4D4B3A4E.2070106@mentor.com \
--to=meador_inge@mentor$(echo .)com \
--cc=arnd@arndb$(echo .)de \
--cc=devicetree-discuss@lists$(echo .)ozlabs.org \
--cc=hollis_blanchard@mentor$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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