From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Qais Yousef <qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>,
"devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Jiang Liu <jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Lisa Parratt
<Lisa.Parratt-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Subject: Re: Generic DT binding for IPIs
Date: Thu, 10 Dec 2015 11:49:41 +1100 [thread overview]
Message-ID: <20151210004941.GY20139@voom.fritz.box> (raw)
In-Reply-To: <CAL_Jsq+yv1UnBhrR+x+DEA41yETVANY9_-5W0DSQJVEQ4+Mx_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]
On Wed, Dec 09, 2015 at 10:50:35AM -0600, Rob Herring wrote:
> On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef <qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> wrote:
> > Hi,
> >
> > On 10/22/2015 12:55 PM, Jason Cooper wrote:
> >>
> >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
> >>>
> >>> Is there anything more I can do to get more attention about this? I
> >>> think Marc's suggestion is more generic and future proof, if I send
> >>> RFC patches for that would this be better?
> >>
> >> Please do.
> >
> >
> > Unfortunately I haven't had a chance to get around writing the patches yet.
> > I came up with a different description though that I thought maybe worth
> > sharing
> > to see if there's any opinion about it before the actual work being done.
>
> I've not given this too much thought, but here's my initial thoughts.
>
> >
> > To summarise, the problem I am trying to solve is that we have a type of
> > coprocessors which share the interrupt controller with Linux, hence the IPI
> > mechanism this controller uses. I've been working with Thomas on
> > implementing
> > a generic API to allocate IPIs for coprocesors and a way for drivers to send
> > these IPIs [1].
> >
> > To complement this new API, we need a mechanism to describe this in
> > device tree so a driver that wants to allocate an IPI can have this done
> > automatically for it like we handle interrupts.
> >
> > What I have in mind is:
> >
> > coproc {
> > ipi-parent = <&gic>;
> >
> > ipis = <CPU_VALUE IPI_SPEC>;
> > ipi-names = "in";
> > };
> >
> > This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as
> > parameters to the controller. Which means we need a new ipi-cells to
> > define how many cells are in ipis property. Note the new ipi-parent too.
>
> These are still interrupts, so I'd prefer to use or extend the
> interrupt binding if possible.
I agree. It should be possible to just describe these as interrupts,
with the interrupt-parent being a special interrupt controller node to
represent these IPIs.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Rob Herring <robh+dt@kernel.org>
Cc: Qais Yousef <qais.yousef@imgtec.com>,
"devicetree-spec@vger.kernel.org"
<devicetree-spec@vger.kernel.org>,
Jason Cooper <jason@lakedaemon.net>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Jiang Liu <jiang.liu@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Lisa Parratt <Lisa.Parratt@imgtec.com>
Subject: Re: Generic DT binding for IPIs
Date: Thu, 10 Dec 2015 11:49:41 +1100 [thread overview]
Message-ID: <20151210004941.GY20139@voom.fritz.box> (raw)
In-Reply-To: <CAL_Jsq+yv1UnBhrR+x+DEA41yETVANY9_-5W0DSQJVEQ4+Mx_w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]
On Wed, Dec 09, 2015 at 10:50:35AM -0600, Rob Herring wrote:
> On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef <qais.yousef@imgtec.com> wrote:
> > Hi,
> >
> > On 10/22/2015 12:55 PM, Jason Cooper wrote:
> >>
> >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
> >>>
> >>> Is there anything more I can do to get more attention about this? I
> >>> think Marc's suggestion is more generic and future proof, if I send
> >>> RFC patches for that would this be better?
> >>
> >> Please do.
> >
> >
> > Unfortunately I haven't had a chance to get around writing the patches yet.
> > I came up with a different description though that I thought maybe worth
> > sharing
> > to see if there's any opinion about it before the actual work being done.
>
> I've not given this too much thought, but here's my initial thoughts.
>
> >
> > To summarise, the problem I am trying to solve is that we have a type of
> > coprocessors which share the interrupt controller with Linux, hence the IPI
> > mechanism this controller uses. I've been working with Thomas on
> > implementing
> > a generic API to allocate IPIs for coprocesors and a way for drivers to send
> > these IPIs [1].
> >
> > To complement this new API, we need a mechanism to describe this in
> > device tree so a driver that wants to allocate an IPI can have this done
> > automatically for it like we handle interrupts.
> >
> > What I have in mind is:
> >
> > coproc {
> > ipi-parent = <&gic>;
> >
> > ipis = <CPU_VALUE IPI_SPEC>;
> > ipi-names = "in";
> > };
> >
> > This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as
> > parameters to the controller. Which means we need a new ipi-cells to
> > define how many cells are in ipis property. Note the new ipi-parent too.
>
> These are still interrupts, so I'd prefer to use or extend the
> interrupt binding if possible.
I agree. It should be possible to just describe these as interrupts,
with the interrupt-parent being a special interrupt controller node to
represent these IPIs.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-12-10 0:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 10:18 Generic DT binding for IPIs Qais Yousef
2015-10-14 10:18 ` Qais Yousef
[not found] ` <561E2BE6.2090807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2015-10-22 10:44 ` Qais Yousef
2015-10-22 10:44 ` Qais Yousef
[not found] ` <5628BE00.4020106-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2015-10-22 11:55 ` Jason Cooper
2015-10-22 11:55 ` Jason Cooper
[not found] ` <20151022115551.GI3953-fahSIxCzskDQ+YiMSub0/l6hYfS7NtTn@public.gmane.org>
2015-12-09 15:27 ` Qais Yousef
2015-12-09 15:27 ` Qais Yousef
2015-12-09 16:50 ` Rob Herring
[not found] ` <CAL_Jsq+yv1UnBhrR+x+DEA41yETVANY9_-5W0DSQJVEQ4+Mx_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-10 0:49 ` David Gibson [this message]
2015-12-10 0:49 ` David Gibson
2015-12-10 10:20 ` Qais Yousef
2015-12-10 10:20 ` Qais Yousef
[not found] ` <56695201.2070807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2015-12-11 0:39 ` David Gibson
2015-12-11 0:39 ` David Gibson
[not found] ` <20151211003902.GE20139-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org>
2015-12-11 10:47 ` Qais Yousef
2015-12-11 10:47 ` Qais Yousef
[not found] ` <566AA9DD.6040404-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
2015-12-14 1:40 ` David Gibson
2015-12-14 1:40 ` David Gibson
2015-12-17 11:31 ` Qais Yousef
2015-12-22 4:38 ` David Gibson
2015-10-22 13:43 ` Rob Herring
2015-10-22 13:43 ` Rob Herring
2015-10-23 10:28 ` Qais Yousef
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=20151210004941.GY20139@voom.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=Lisa.Parratt-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
--cc=jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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.