[lkml]   [2015]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Fri, Jan 16, 2015 at 4:46 PM, Ohad Ben-Cohen <> wrote:
> Mark,
> On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland <> 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.

But that's exactly how irqs or gpios work as well. If you have 32
gpios in a system they used to be numbered 0-31 and people would
reference them directly by that number. Every one of the systems that
was designed in this way is moving away from it.

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

In a system where you have two hwlock blocks lckA and lckB, each
consisting of 8 locks and you have dspB that can only access lckB;
will you tell the firmware engineers to always subtract 8 from the
numbers you pass them?

Wouldn't it make much more sense to have local indexes here and pass
them e.g lckB:2?

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

I'm sorry but you cannot have a system on both sides that is allowed
to do dynamic allocation from a limited set of resources.

Further more this dynamic allocation leads to interesting race
conditions as what happens if you dynamically allocate a hwlock that
is statically allocated by another part of the system?
The only solution I can think of is to have a static allocation of ids
that the dynamic allocator might use, and then we're just carrying
extra code when the system is already statically configured...

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

Designing this interface to take into consideration that someone might
send us something completely crazy isn't productive.

The only reason for having num-locks and base-id in device tree is
because of the current Linux implementation. base-id is not a property
of the hardware and num-locks is not needed for anything but book
keeping of base-id's in the hwlock framework.

This is why I preferred Sumans earlier suggestion of having the
binding consist of #hwlock-cells = <X> and the necessary accessor
functions for resolving a hwlock based on a dt reference.


 \ /
  Last update: 2015-01-31 00:41    [W:0.125 / U:14.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site