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: 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

             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: 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.