From: Rob Herring <robh+dt@kernel.org> To: Qais Yousef <qais.yousef@imgtec.com> Cc: "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>, Jason Cooper <jason@lakedaemon.net>, Marc Zyngier <marc.zyngier@arm.com>, Jiang Liu <jiang.liu@linux.intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: Generic DT binding for IPIs Date: Thu, 22 Oct 2015 08:43:53 -0500 [thread overview] Message-ID: <CAL_JsqKb3VFyo+xrWeC99-z=xhKbei0=cETU=Nip79K1xU6FSw@mail.gmail.com> (raw) In-Reply-To: <561E2BE6.2090807@imgtec.com> On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef <qais.yousef@imgtec.com> wrote: > Hi, > > This is an attempt to revive a discussion on the right list this time with > all the correct people hopefully on CC. devicetree-spec would be more appropriate list for something like this. > While trying to upstream a driver, Thomas and Marc Zyngier pointed out the > need for a generic IPI support in the kernel to allow driver to reserve and > send ones. Hopefully my latest RFC patch will help to clarify what's being > done. > > https://lkml.org/lkml/2015/10/13/227 > > We need a generic DT binding support to accompany that to allow a driver to > reserve an IPI using this new mechanism. > > MarcZ had the following suggestion: > > https://lkml.org/lkml/2015/8/24/628 > > Which in summary is > > mydevice@f0000000 { > interrupt-source = <&intc INT_SPEC 2 &inttarg1 &inttarg1>; What is INT_SPEC and "2"? A drawing of the h/w connections and then what the binding looks like would be helpful. > }; > > inttarg1: mydevice@f1000000 { > interrupt-sink = <&intc HWAFFINITY1>; What is HWAFFINITY1? I want to be able to see if say this value is 1, then the affinity is for cpu0. > }; > > inttarg2: cpu@1 { > interrupt-sink = <&intc HWAFFINITY2>; > }; > > > interrupt-sink requests to reserve an IPI that it will receive at HWAFFINITY > cpumask. interrupt-source will not do any reservation. It will simply > connect an IPI reserved by interrupt-sink to the device that will be > responsible for generating that IPI. This description should allow > connecting any 2 devices. > Correct me Marc if I got it wrong please. > > I suggested a simplification by assuming that IPIs will only be between host > OS and a coprocessor which would gives us this form which I think is easier > to deal with > > coprocessor { > interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; > interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>; > } > > > interrupt-source here reserves an IPI to be sent from host OS to coprocessor > at COP_HWAFFINITY. interrupt-sink will reserve an IPI to be received by host > OS at CPU_HWAFFINITY. Less generic but I don't know how important it is for > host OS to setup IPIs between 2 external coprocessors and whether it should > really be doing that. Could we use the existing interrupts binding for interrupt-sink? > > What do the DT experts think? Any preference or a better suggestion? Depends how you would assign coproc to coproc IPIs in a system. It may be fixed in firmware, or more complex coprocs may read the dtb. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Qais Yousef <qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> Cc: "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>, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@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> Subject: Re: Generic DT binding for IPIs Date: Thu, 22 Oct 2015 08:43:53 -0500 [thread overview] Message-ID: <CAL_JsqKb3VFyo+xrWeC99-z=xhKbei0=cETU=Nip79K1xU6FSw@mail.gmail.com> (raw) In-Reply-To: <561E2BE6.2090807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef <qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> wrote: > Hi, > > This is an attempt to revive a discussion on the right list this time with > all the correct people hopefully on CC. devicetree-spec would be more appropriate list for something like this. > While trying to upstream a driver, Thomas and Marc Zyngier pointed out the > need for a generic IPI support in the kernel to allow driver to reserve and > send ones. Hopefully my latest RFC patch will help to clarify what's being > done. > > https://lkml.org/lkml/2015/10/13/227 > > We need a generic DT binding support to accompany that to allow a driver to > reserve an IPI using this new mechanism. > > MarcZ had the following suggestion: > > https://lkml.org/lkml/2015/8/24/628 > > Which in summary is > > mydevice@f0000000 { > interrupt-source = <&intc INT_SPEC 2 &inttarg1 &inttarg1>; What is INT_SPEC and "2"? A drawing of the h/w connections and then what the binding looks like would be helpful. > }; > > inttarg1: mydevice@f1000000 { > interrupt-sink = <&intc HWAFFINITY1>; What is HWAFFINITY1? I want to be able to see if say this value is 1, then the affinity is for cpu0. > }; > > inttarg2: cpu@1 { > interrupt-sink = <&intc HWAFFINITY2>; > }; > > > interrupt-sink requests to reserve an IPI that it will receive at HWAFFINITY > cpumask. interrupt-source will not do any reservation. It will simply > connect an IPI reserved by interrupt-sink to the device that will be > responsible for generating that IPI. This description should allow > connecting any 2 devices. > Correct me Marc if I got it wrong please. > > I suggested a simplification by assuming that IPIs will only be between host > OS and a coprocessor which would gives us this form which I think is easier > to deal with > > coprocessor { > interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; > interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>; > } > > > interrupt-source here reserves an IPI to be sent from host OS to coprocessor > at COP_HWAFFINITY. interrupt-sink will reserve an IPI to be received by host > OS at CPU_HWAFFINITY. Less generic but I don't know how important it is for > host OS to setup IPIs between 2 external coprocessors and whether it should > really be doing that. Could we use the existing interrupts binding for interrupt-sink? > > What do the DT experts think? Any preference or a better suggestion? Depends how you would assign coproc to coproc IPIs in a system. It may be fixed in firmware, or more complex coprocs may read the dtb. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-10-22 13:44 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 2015-10-22 10:44 ` Qais Yousef 2015-10-22 10:44 ` Qais Yousef 2015-10-22 11:55 ` Jason Cooper 2015-10-22 11:55 ` Jason Cooper 2015-12-09 15:27 ` Qais Yousef 2015-12-09 15:27 ` Qais Yousef 2015-12-09 16:50 ` Rob Herring 2015-12-10 0:49 ` David Gibson 2015-12-10 0:49 ` David Gibson 2015-12-10 10:20 ` Qais Yousef 2015-12-10 10:20 ` Qais Yousef 2015-12-11 0:39 ` David Gibson 2015-12-11 0:39 ` David Gibson 2015-12-11 10:47 ` Qais Yousef 2015-12-11 10:47 ` Qais Yousef 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 [this message] 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='CAL_JsqKb3VFyo+xrWeC99-z=xhKbei0=cETU=Nip79K1xU6FSw@mail.gmail.com' \ --to=robh+dt@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=jason@lakedaemon.net \ --cc=jiang.liu@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=pawel.moll@arm.com \ --cc=qais.yousef@imgtec.com \ --cc=tglx@linutronix.de \ /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: linkBe 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.