All of lore.kernel.org
 help / color / mirror / Atom feed
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: Re: Generic DT binding for IPIs
Date: Thu, 22 Oct 2015 11:44:16 +0100	[thread overview]
Message-ID: <5628BE00.4020106@imgtec.com> (raw)
In-Reply-To: <561E2BE6.2090807@imgtec.com>

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?

Thanks,
Qais

On 10/14/2015 11:18 AM, Qais Yousef wrote:
> 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: Re: Generic DT binding for IPIs
Date: Thu, 22 Oct 2015 11:44:16 +0100	[thread overview]
Message-ID: <5628BE00.4020106@imgtec.com> (raw)
In-Reply-To: <561E2BE6.2090807-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>

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?

Thanks,
Qais

On 10/14/2015 11:18 AM, Qais Yousef wrote:
> 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

  reply	other threads:[~2015-10-22 10: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 [this message]
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=5628BE00.4020106@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: 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.