From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Meador Inge <meador_inge@mentor.com>
Cc: Hollis Blanchard <hollis_blanchard@mentor.com>,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'
Date: Tue, 08 Feb 2011 08:45:36 +1100 [thread overview]
Message-ID: <1297115136.14982.82.camel@pasglop> (raw)
In-Reply-To: <4D5033C9.8030407@mentor.com>
> In my previous reply I said that "it is not so much as a need as it is a
> potential simplification." After further reflection, I don't think that
> is completely true. As we get into AMP systems with higher core counts,
> then implementing this functionality using the existing
> "protected-sources" implementation versus the new "pic-no-reset" work is
> going to be harder to maintain.
I'm not arguing that your approach isn't more suitable for AMP systems,
I just want to leave the existing protected-sources mechanism alone. I'm
not opposing adding a new, better, mechanism for newer platforms.
However, I'd name it differently. "pic-no-reset" doesn't carry enough
meaning in that case. What we want to point out here is that the PIC
has been pre-initialized.
Another option, which may be cleaner, is to stick to "no-reset" (no need
for pic- prefix) and make it do just that (prevent the reset), and then
use a positive variant of "protected-sources", call it
"allowed-sources". Maybe even make it a series of ranges. Then have the
MPIC only access these.
I think this is more robust as it would also prevent "accidental" use of
the wrong sources (bad device-tree, drivers that let you muck around
with irq numbers, etc...).
Cheers,
Ben.
> The reason being that *every* OS instance has to know about *every*
> other OSes interrupt sources, which is a little gross. You can see this
> happening already in "arch/powerpc/boot/dts/p2020rdb_camp_core0.dts" and
> "arch/powerpc/boot/dts/p2020rdb_camp_core1.dts":
>
> // p2020rdb_camp_core0.dts
> mpic: pic@40000 {
> ...
> // Sources used by the OS on core 1
> protected-sources = <
> 42 76 77 78 79 /* serial1 , dma2 */
> 29 30 34 26 /* enet0, pci1 */
> 0xe0 0xe1 0xe2 0xe3 /* msi */
> 0xe4 0xe5 0xe6 0xe7
> >;
> };
>
> // p2020rdb_camp_core1.dts
> mpic: pic@40000 {
> ...
> // Sources used by the OS on core 0
> protected-sources = <
> 17 18 43 42 59 47 /*ecm, mem, i2c, serial0, spi,gpio */
> 16 20 21 22 23 28 /* L2, dma1, USB */
> 03 35 36 40 31 32 33 /* mdio, enet1, enet2 */
> 72 45 58 25 /* sdhci, crypto , pci */
> >;
> };
>
> It is going to be a real pain to keep all of the lists up to date.
> Especially considering we already have sufficient information in the
> device tree to do this work. I do understand the concern of
> finding/testing the older systems. However, is the testing of those
> systems enough to keep out the proposed change and potentially lower
> maintenance in the future? Is the legacy system argument the only
> reason to keep this change out or are there other technical deficiencies?
>
> Also, in the proposed MPIC modifications there is a check for protected
> sources (it is treated as an alias for "pic-no-reset"; see PATCH 3 in
> the set) that should provide functionality equivalent to what systems
> using "protected-sources" already have. That check only looks for the
> presence of "protected-sources" and does not process the cells. Another
> option would be to leave in the protected sources implementation (but
> undocumented in the binding) and have the full "pic-no-reset" behavior
> there as well (and documented in the binding).
>
> If this has no chance of acceptance (?), then I will just re-submit the
> binding and implementation with "protected-sources" and the limited form
> of "pic-no-reset".
>
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Meador Inge <meador_inge-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Cc: Hollis Blanchard
<hollis_blanchard-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'
Date: Tue, 08 Feb 2011 08:45:36 +1100 [thread overview]
Message-ID: <1297115136.14982.82.camel@pasglop> (raw)
In-Reply-To: <4D5033C9.8030407-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> In my previous reply I said that "it is not so much as a need as it is a
> potential simplification." After further reflection, I don't think that
> is completely true. As we get into AMP systems with higher core counts,
> then implementing this functionality using the existing
> "protected-sources" implementation versus the new "pic-no-reset" work is
> going to be harder to maintain.
I'm not arguing that your approach isn't more suitable for AMP systems,
I just want to leave the existing protected-sources mechanism alone. I'm
not opposing adding a new, better, mechanism for newer platforms.
However, I'd name it differently. "pic-no-reset" doesn't carry enough
meaning in that case. What we want to point out here is that the PIC
has been pre-initialized.
Another option, which may be cleaner, is to stick to "no-reset" (no need
for pic- prefix) and make it do just that (prevent the reset), and then
use a positive variant of "protected-sources", call it
"allowed-sources". Maybe even make it a series of ranges. Then have the
MPIC only access these.
I think this is more robust as it would also prevent "accidental" use of
the wrong sources (bad device-tree, drivers that let you muck around
with irq numbers, etc...).
Cheers,
Ben.
> The reason being that *every* OS instance has to know about *every*
> other OSes interrupt sources, which is a little gross. You can see this
> happening already in "arch/powerpc/boot/dts/p2020rdb_camp_core0.dts" and
> "arch/powerpc/boot/dts/p2020rdb_camp_core1.dts":
>
> // p2020rdb_camp_core0.dts
> mpic: pic@40000 {
> ...
> // Sources used by the OS on core 1
> protected-sources = <
> 42 76 77 78 79 /* serial1 , dma2 */
> 29 30 34 26 /* enet0, pci1 */
> 0xe0 0xe1 0xe2 0xe3 /* msi */
> 0xe4 0xe5 0xe6 0xe7
> >;
> };
>
> // p2020rdb_camp_core1.dts
> mpic: pic@40000 {
> ...
> // Sources used by the OS on core 0
> protected-sources = <
> 17 18 43 42 59 47 /*ecm, mem, i2c, serial0, spi,gpio */
> 16 20 21 22 23 28 /* L2, dma1, USB */
> 03 35 36 40 31 32 33 /* mdio, enet1, enet2 */
> 72 45 58 25 /* sdhci, crypto , pci */
> >;
> };
>
> It is going to be a real pain to keep all of the lists up to date.
> Especially considering we already have sufficient information in the
> device tree to do this work. I do understand the concern of
> finding/testing the older systems. However, is the testing of those
> systems enough to keep out the proposed change and potentially lower
> maintenance in the future? Is the legacy system argument the only
> reason to keep this change out or are there other technical deficiencies?
>
> Also, in the proposed MPIC modifications there is a check for protected
> sources (it is treated as an alias for "pic-no-reset"; see PATCH 3 in
> the set) that should provide functionality equivalent to what systems
> using "protected-sources" already have. That check only looks for the
> presence of "protected-sources" and does not process the cells. Another
> option would be to leave in the protected sources implementation (but
> undocumented in the binding) and have the full "pic-no-reset" behavior
> there as well (and documented in the binding).
>
> If this has no chance of acceptance (?), then I will just re-submit the
> binding and implementation with "protected-sources" and the limited form
> of "pic-no-reset".
>
next prev parent reply other threads:[~2011-02-07 21:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-04 23:25 [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset" Meador Inge
2011-02-04 23:25 ` Meador Inge
2011-02-04 23:25 ` [PATCH v3 1/4] powerpc: Removing support for 'protected-sources' Meador Inge
2011-02-06 23:35 ` Benjamin Herrenschmidt
2011-02-06 23:35 ` Benjamin Herrenschmidt
2011-02-07 1:32 ` Meador Inge
2011-02-07 1:32 ` Meador Inge
2011-02-07 1:37 ` Benjamin Herrenschmidt
2011-02-07 18:02 ` Meador Inge
2011-02-07 21:45 ` Benjamin Herrenschmidt [this message]
2011-02-07 21:45 ` Benjamin Herrenschmidt
2011-02-08 0:32 ` Meador Inge
2011-02-08 0:32 ` Meador Inge
2011-02-08 15:13 ` Yoder Stuart-B08248
2011-02-08 15:13 ` Yoder Stuart-B08248
2011-02-04 23:25 ` [PATCH v3 2/4] powerpc: document the Open PIC device tree binding Meador Inge
2011-02-04 23:25 ` [PATCH v3 3/4] powerpc: make MPIC honor the "pic-no-reset" device tree property Meador Inge
2011-02-04 23:25 ` [PATCH v3 4/4] powerpc: Replacing "protected-sources" with "pic-no-reset" in DTS files Meador Inge
2011-02-04 23:25 ` Meador Inge
[not found] ` <AANLkTinda9TX+Ng=kL-HHLOdqRnUZ6uitQKyZcRUHVco@mail.gmail.com>
2011-02-11 2:01 ` [PATCH v3 0/4] powerpc: Open PIC binding and "pic-no-reset" Meador Inge
2011-02-11 2:01 ` Meador Inge
2011-02-11 3:26 ` Meador Inge
2011-02-11 3:26 ` Meador Inge
2011-02-11 14:58 ` Yoder Stuart-B08248
2011-02-11 14:58 ` Yoder Stuart-B08248
2011-02-11 17:35 ` Meador Inge
2011-02-11 17:35 ` Meador Inge
2011-02-11 18:41 ` Scott Wood
2011-02-11 18:41 ` Scott Wood
2011-02-11 18:59 ` Grant Likely
2011-02-11 18:59 ` Grant Likely
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=1297115136.14982.82.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=hollis_blanchard@mentor.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=meador_inge@mentor.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 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.