From: Qais Yousef <qais.yousef@imgtec.com> To: <devicetree@vger.kernel.org> Cc: <robh+dt@kernel.org>, <pawel.moll@arm.com>, <mark.rutland@arm.com>, <ijc+devicetree@hellion.org.uk>, <galak@codeaurora.org>, <tglx@linutronix.de>, <jason@lakedaemon.net>, <marc.zyngier@arm.com>, <jiang.liu@linux.intel.com>, <linux-kernel@vger.kernel.org> Subject: Generic DT binding for IPIs Date: Wed, 14 Oct 2015 11:18:14 +0100 [thread overview] Message-ID: <561E2BE6.2090807@imgtec.com> (raw) Hi, This is an attempt to revive a discussion on the right list this time with all the correct people hopefully on CC. 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>; }; inttarg1: mydevice@f1000000 { interrupt-sink = <&intc HWAFFINITY1>; }; 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. What do the DT experts think? Any preference or a better suggestion? I tried to keep this short and simple, please let me know if you need more info or if there's anything that needs more clarification. Thanks, Qais
WARNING: multiple messages have this Message-ID (diff)
From: Qais Yousef <qais.yousef-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org, marc.zyngier-5wv7dgnIgG8@public.gmane.org, jiang.liu-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Generic DT binding for IPIs Date: Wed, 14 Oct 2015 11:18:14 +0100 [thread overview] Message-ID: <561E2BE6.2090807@imgtec.com> (raw) Hi, This is an attempt to revive a discussion on the right list this time with all the correct people hopefully on CC. 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>; }; inttarg1: mydevice@f1000000 { interrupt-sink = <&intc HWAFFINITY1>; }; 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. What do the DT experts think? Any preference or a better suggestion? I tried to keep this short and simple, please let me know if you need more info or if there's anything that needs more clarification. Thanks, Qais -- 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 reply other threads:[~2015-10-14 10:18 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-14 10:18 Qais Yousef [this message] 2015-10-14 10:18 ` Generic DT binding for IPIs 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 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=561E2BE6.2090807@imgtec.com \ --to=qais.yousef@imgtec.com \ --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=robh+dt@kernel.org \ --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.