On Fri, Jan 16, 2015 at 4:46 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > Mark, > > On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland <mark.rutland@xxxxxxx> 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. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
