* Ohad Ben-Cohen <ohad@xxxxxxxxxx> [150116 16:50]: > 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. > > - 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
