[PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

[Tony Lindgren]

* Ohad Ben-Cohen <ohad at wizery.com> [150116 16:50]:
> Mark,
> 
> On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland <mark.rutland at 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.

How about default to Linux id space and allow overriding that with
a module param option if needed?

Regards,

Tony