On Fri, Jan 16, 2015 at 06:09:00AM +0000, Ohad Ben-Cohen wrote: > On Thu, Jan 15, 2015 at 4:42 PM, Rob Herring <robherring2@xxxxxxxxx> wrote: > > On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > >> On Thu, Jan 15, 2015 at 01:52:01PM +0000, Mark Rutland wrote: > >>> On Wed, Jan 14, 2015 at 08:58:18PM +0000, Suman Anna wrote: > >>> > +- hwlock-base-id: An unique base Id for the locks for a particular hwlock > >>> > + device. This property is mandatory for all platform > >>> > + implementations. > >>> > >>> This property makes no sense. The ID encoded in the hwlock cells is > >>> relative to the instance (identified by phandle), not global. So the DT > >>> has no global ID space. > >>> > >>> Why do you think you need this? > >> > >> Having looked at the way this proeprty is used, NAK. > >> > >> If you need to carve up a Linux-internal ID space, do that dynamically. > >> There is no need for this property. > > > > Better yet, don't create a Linux ID space for this. Everywhere we have > > one, we want to get rid of it. > > Rob, Mark, > > 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. > Given that these id numbers are global, system-wide, static and > predefined, where Linux may just be one user of them, please > reconsider the approach as implemented by Suman, or suggest an > alternative one you may prefer. To communicate with the other processors, Linux will need to understand the protocol. So there will need to be nodes in the DT describing the protocol. Those nodes can refer to the relevant locks using phandle + args (with a hwlock-names list if indexing is not appropriate). The entire point of the hwlock-cells is to allow individual locks to be referred to in this way. Thanks, Mark. -- 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
