linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ohad Ben-Cohen <ohad@wizery.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Rob Herring <robherring2@gmail.com>, Suman Anna <s-anna@ti.com>,
	Kumar Gala <galak@codeaurora.org>,
	Bjorn Andersson <bjorn@kryo.se>,
	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: Sat, 17 Jan 2015 02:46:46 +0200	[thread overview]
Message-ID: <CAK=WgbYBqPoUm9byx0du_g5ZmHdYaUVLpSPZYHoCVzNoatNKpw@mail.gmail.com> (raw)
In-Reply-To: <20150116101746.GA21809@leverpostej>

Mark,

On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> The hwlock is a basic hardware primitive that allow synchronization
>> between different processors in the system, which may be running Linux
>> as well as other operating systems, and may have no other means of
>> communication.
>>
>> The hwlock id numbers are predefined, global and static across the
>> entire system: Linux may boot well after other operating systems are
>> already running and using these hwlocks to communicate, and therefore,
>> in order to use these hardware devices, it must not enumerate them
>> differently than the rest of the system.
>
> That's not true.
>
> In order to communicate it must agree with the other users as to the
> meaning of each instance, and the protocol for use. That doesn't
> necessarily mean that Linux needs to know the numerical ID from a
> datasheet, and regardless that ID is separate from the logical ID Linux
> uses internally.

Let me describe hwspinlocks a bit more so we all get to know it better
and can then agree on a proper solution.

- What makes handling of hwspinlock ID numbers convenient is the fact
that it's not based on random datasheet numbers. In fact, hwspinlocks
is just special memory: usually datasheets just define the base
address and the size of the hwspinlock area. So any numerical ID we
use to call the locks themselves are already logical and sane, similar
to the way we handle memory (i.e. if we have 32 locks we'll always use
0..31). So hwlocks ids are very much like memory addressing, and not
irq numbers.

- Sometimes Linux will have to dynamically allocate a hwlock, and send
the ID of the allocated lock to a remote processor (which may not be
running Linux).
- Sometimes a remote processor, which may not be running Linux, will
have to dynamically allocate a hwlock, and send the ID of the
allocated lock to us (another processor running Linux)

We cannot tell in advance what kind of IPC is going to be used for
sending and receiving this hwlock ID. Some are handled by Linux
(kernel) and some by the user space. So we must be able to expose an
ID the system will understand as well as receive one.

Thanks,
Ohad.

  reply	other threads:[~2015-01-17  0:47 UTC|newest]

Thread overview: 34+ 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 ` [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock Suman Anna
2015-01-15 13:52   ` Mark Rutland
2015-01-15 13:55     ` Mark Rutland
2015-01-15 14:42       ` Rob Herring
2015-01-15 20:16         ` Suman Anna
2015-01-16  6:09         ` Ohad Ben-Cohen
2015-01-16 10:17           ` Mark Rutland
2015-01-17  0:46             ` Ohad Ben-Cohen [this message]
2015-01-20 18:05               ` Tony Lindgren
2015-01-21 12:41                 ` Ohad Ben-Cohen
2015-01-21 17:56                   ` Suman Anna
2015-01-22 18:56                     ` Mark Rutland
2015-01-29  3:58                       ` Suman Anna
2015-02-11 11:29                         ` Mark Rutland
2015-02-16 18:06                           ` Bjorn Andersson
2015-01-30 23:29               ` Bjorn Andersson
2015-01-31  5:41                 ` Ohad Ben-Cohen
2015-02-01 11:00                   ` Ohad Ben-Cohen
2015-02-02 21:14                     ` Suman Anna
2015-02-01 17:55                   ` Bjorn Andersson
2015-02-02 21:07                     ` Suman Anna
2015-02-05 23:01                       ` Bjorn Andersson
2015-02-06  0:11                         ` Suman Anna
2015-02-06  0:34                           ` Bjorn Andersson
2015-02-11 10:29                             ` Ohad Ben-Cohen
2015-02-11 11:35                               ` Mark Rutland
2015-02-16 20:30                   ` Bjorn Andersson
2015-01-16 10:19         ` Mark Rutland
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 ` [PATCH v7 3/4] hwspinlock/core: add common OF helpers Suman Anna
2015-01-14 20:58 ` [PATCH v7 4/4] hwspinlock/omap: add support for dt nodes Suman Anna
2015-01-15 10:13 ` [PATCH v7 0/4] hwspinlock core & omap dt support 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='CAK=WgbYBqPoUm9byx0du_g5ZmHdYaUVLpSPZYHoCVzNoatNKpw@mail.gmail.com' \
    --to=ohad@wizery.com \
    --cc=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=robh+dt@kernel.org \
    --cc=robherring2@gmail.com \
    --cc=s-anna@ti.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).