From: Bjorn Andersson <bjorn@kryo.se> To: Mark Rutland <mark.rutland@arm.com> Cc: Suman Anna <s-anna@ti.com>, Ohad Ben-Cohen <ohad@wizery.com>, Tony Lindgren <tony@atomide.com>, Rob Herring <robherring2@gmail.com>, Kumar Gala <galak@codeaurora.org>, Josh Cartwright <joshc@codeaurora.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Rob Herring <robh+dt@kernel.org> Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock Date: Mon, 16 Feb 2015 10:06:26 -0800 [thread overview] Message-ID: <CAJAp7OgCs2kyF+ZdSzbf02qNHDdd_g=Nyf54akiAjAd1uK6cEA@mail.gmail.com> (raw) In-Reply-To: <20150211112907.GD9154@leverpostej> On Wed, Feb 11, 2015 at 3:29 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Jan 29, 2015 at 03:58:42AM +0000, Suman Anna wrote: >> On 01/22/2015 12:56 PM, Mark Rutland wrote: [..] >> > That's the only way I would expect this to possibly remain a stable >> > over time, and it's the entire reason for #hwlock-cells, no? >> > >> > How do you expect the other components sharing the hwspinlocks to be >> > described? >> >> Yes indeed, this is what any of the clients will use on Linux. But >> this is not necessarily the semantics for exchanging hwlocks with the >> other processor(s) which is where the global id space comes into >> picture. > > I did try to consider that above. Rather than thinking about the > numbering as "global", think of it as unique within the a given pool > shared between processors. That's what the "poolN" names are about > above. > > That way you can dynamically allocate within the pool and know that > Linux and the SW on the other processors will use the same ID. You can > have pools that span multiple hwlock hardware blocks, and you can have > multiple separate pools in operation at once. > > Surely that covers the cases you care about? > > If using names is clunky, we could instead have a pool-hwlocks property > for that purpose. > Just to make I understand your suggestion. We would have the communication entity list all the potential hwlocks (and gpios etc) that it can share and the key to be communicated would then basically be the index in that list? Like: awesome-hub { pool-hwlocks = <&a 1>, <&a 3>, <&b 5>; }; And a communicated "lock 2" would mean lock 3 from block a? This would make it possible to describe what locks are available in this "allocation pool" and would keep such allocation logic out from the hwlock core - as the awesome-hub driver could simply trial and error (with some logic) through the list. Is this understanding correct? Regards, Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: bjorn@kryo.se (Bjorn Andersson) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock Date: Mon, 16 Feb 2015 10:06:26 -0800 [thread overview] Message-ID: <CAJAp7OgCs2kyF+ZdSzbf02qNHDdd_g=Nyf54akiAjAd1uK6cEA@mail.gmail.com> (raw) In-Reply-To: <20150211112907.GD9154@leverpostej> On Wed, Feb 11, 2015 at 3:29 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Jan 29, 2015 at 03:58:42AM +0000, Suman Anna wrote: >> On 01/22/2015 12:56 PM, Mark Rutland wrote: [..] >> > That's the only way I would expect this to possibly remain a stable >> > over time, and it's the entire reason for #hwlock-cells, no? >> > >> > How do you expect the other components sharing the hwspinlocks to be >> > described? >> >> Yes indeed, this is what any of the clients will use on Linux. But >> this is not necessarily the semantics for exchanging hwlocks with the >> other processor(s) which is where the global id space comes into >> picture. > > I did try to consider that above. Rather than thinking about the > numbering as "global", think of it as unique within the a given pool > shared between processors. That's what the "poolN" names are about > above. > > That way you can dynamically allocate within the pool and know that > Linux and the SW on the other processors will use the same ID. You can > have pools that span multiple hwlock hardware blocks, and you can have > multiple separate pools in operation at once. > > Surely that covers the cases you care about? > > If using names is clunky, we could instead have a pool-hwlocks property > for that purpose. > Just to make I understand your suggestion. We would have the communication entity list all the potential hwlocks (and gpios etc) that it can share and the key to be communicated would then basically be the index in that list? Like: awesome-hub { pool-hwlocks = <&a 1>, <&a 3>, <&b 5>; }; And a communicated "lock 2" would mean lock 3 from block a? This would make it possible to describe what locks are available in this "allocation pool" and would keep such allocation logic out from the hwlock core - as the awesome-hub driver could simply trial and error (with some logic) through the list. Is this understanding correct? Regards, Bjorn
next prev parent reply other threads:[~2015-02-16 18:06 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-14 20:58 [PATCH v7 0/4] hwspinlock core & omap dt support Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-15 13:52 ` Mark Rutland 2015-01-15 13:52 ` Mark Rutland 2015-01-15 13:52 ` Mark Rutland 2015-01-15 13:55 ` Mark Rutland 2015-01-15 13:55 ` Mark Rutland 2015-01-15 13:55 ` Mark Rutland 2015-01-15 14:42 ` Rob Herring 2015-01-15 14:42 ` Rob Herring 2015-01-15 14:42 ` Rob Herring 2015-01-15 20:16 ` Suman Anna 2015-01-15 20:16 ` Suman Anna 2015-01-15 20:16 ` Suman Anna 2015-01-16 6:09 ` Ohad Ben-Cohen 2015-01-16 6:09 ` Ohad Ben-Cohen 2015-01-16 6:09 ` Ohad Ben-Cohen 2015-01-16 10:17 ` Mark Rutland 2015-01-16 10:17 ` Mark Rutland 2015-01-16 10:17 ` Mark Rutland 2015-01-17 0:46 ` Ohad Ben-Cohen 2015-01-17 0:46 ` Ohad Ben-Cohen 2015-01-17 0:46 ` Ohad Ben-Cohen 2015-01-20 18:05 ` Tony Lindgren 2015-01-20 18:05 ` Tony Lindgren 2015-01-20 18:05 ` Tony Lindgren 2015-01-21 12:41 ` Ohad Ben-Cohen 2015-01-21 12:41 ` Ohad Ben-Cohen 2015-01-21 12:41 ` Ohad Ben-Cohen 2015-01-21 17:56 ` Suman Anna 2015-01-21 17:56 ` Suman Anna 2015-01-21 17:56 ` Suman Anna 2015-01-22 18:56 ` Mark Rutland 2015-01-22 18:56 ` Mark Rutland 2015-01-22 18:56 ` Mark Rutland 2015-01-29 3:58 ` Suman Anna 2015-01-29 3:58 ` Suman Anna 2015-01-29 3:58 ` Suman Anna 2015-02-11 11:29 ` Mark Rutland 2015-02-11 11:29 ` Mark Rutland 2015-02-11 11:29 ` Mark Rutland 2015-02-16 18:06 ` Bjorn Andersson [this message] 2015-02-16 18:06 ` Bjorn Andersson 2015-02-16 18:06 ` Bjorn Andersson 2015-01-30 23:29 ` Bjorn Andersson 2015-01-30 23:29 ` Bjorn Andersson 2015-01-30 23:29 ` Bjorn Andersson 2015-01-31 5:41 ` Ohad Ben-Cohen 2015-01-31 5:41 ` Ohad Ben-Cohen 2015-01-31 5:41 ` Ohad Ben-Cohen 2015-02-01 11:00 ` Ohad Ben-Cohen 2015-02-01 11:00 ` Ohad Ben-Cohen 2015-02-01 11:00 ` Ohad Ben-Cohen 2015-02-02 21:14 ` Suman Anna 2015-02-02 21:14 ` Suman Anna 2015-02-02 21:14 ` Suman Anna 2015-02-01 17:55 ` Bjorn Andersson 2015-02-01 17:55 ` Bjorn Andersson 2015-02-01 17:55 ` Bjorn Andersson 2015-02-02 21:07 ` Suman Anna 2015-02-02 21:07 ` Suman Anna 2015-02-02 21:07 ` Suman Anna 2015-02-05 23:01 ` Bjorn Andersson 2015-02-05 23:01 ` Bjorn Andersson 2015-02-05 23:01 ` Bjorn Andersson 2015-02-06 0:11 ` Suman Anna 2015-02-06 0:11 ` Suman Anna 2015-02-06 0:11 ` Suman Anna 2015-02-06 0:34 ` Bjorn Andersson 2015-02-06 0:34 ` Bjorn Andersson 2015-02-06 0:34 ` Bjorn Andersson 2015-02-11 10:29 ` Ohad Ben-Cohen 2015-02-11 10:29 ` Ohad Ben-Cohen 2015-02-11 10:29 ` Ohad Ben-Cohen 2015-02-11 11:35 ` Mark Rutland 2015-02-11 11:35 ` Mark Rutland 2015-02-11 11:35 ` Mark Rutland 2015-02-16 20:30 ` Bjorn Andersson 2015-02-16 20:30 ` Bjorn Andersson 2015-02-16 20:30 ` Bjorn Andersson 2015-01-16 10:19 ` Mark Rutland 2015-01-16 10:19 ` Mark Rutland 2015-01-16 10:19 ` Mark Rutland 2015-01-16 17:49 ` Suman Anna 2015-01-16 17:49 ` Suman Anna 2015-01-16 17:49 ` Suman Anna 2015-01-14 20:58 ` [PATCH v7 2/4] Documentation: dt: add the omap hwspinlock bindings document Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` [PATCH v7 3/4] hwspinlock/core: add common OF helpers Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` [PATCH v7 4/4] hwspinlock/omap: add support for dt nodes Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-14 20:58 ` Suman Anna 2015-01-15 10:13 ` [PATCH v7 0/4] hwspinlock core & omap dt support Ohad Ben-Cohen 2015-01-15 10:13 ` Ohad Ben-Cohen
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='CAJAp7OgCs2kyF+ZdSzbf02qNHDdd_g=Nyf54akiAjAd1uK6cEA@mail.gmail.com' \ --to=bjorn@kryo.se \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=joshc@codeaurora.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=ohad@wizery.com \ --cc=robh+dt@kernel.org \ --cc=robherring2@gmail.com \ --cc=s-anna@ti.com \ --cc=tony@atomide.com \ /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.