On Fri, Jan 30, 2015 at 9:41 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson <bjorn@xxxxxxx> wrote: >> 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 > > This is a good example - thanks. To be able to cope with such cases we > will have to pass a hwlock block reference and its relative lock id. > Correct, so the #hwlock-cells and hwlock part from the proposal are the important one. Having an optional hwlock-names will make things easier to read as well, but is not necessary. > The DT binding should definitely be prepared for such cases (just kill > the base-id field?), but let's see what it means about the Linux > implementation. > >From the dt binding PoV, we should be able to skip num-locks as well. It seems most hwlock blocks have a fixed amount of locks provided and the drivers are reporting this to the core when registering. So I think we can reduce the binding to: Providers: #hwlock-cells Consumers: hwlocks hwlock-names For the hardware where number of locks is actually variable (e.g. different variants of same block) there can be driver specific entries for this. > Since the existence of several hwblocks is still fictional (Bjorn, > please confirm too?), we may prefer to introduce changes to support it > only when it shows up; it all depends on the amount of changes needed. > Suman, care to take a look please? > I haven't seen any such systems yet. We could introduce the logic found in other subsystems of allowing -1 as base_id and having the core find a available range. This will work for all cases where the global ids doesn't have to be static; either due to the fact that we use block:local-id or that the indices are hard coded. (Referencing locks via dt is equivalent of the block:local-id case) >>> - 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. > > Of course not. On such systems, Linux is not the one responsible for > allocating the hwlocks, at least not during part of the time or from > part of the hwlocks. There were a few different use cases, with > different semantics, that required communicating to Linux an hwlock > id, but since none of them have reached mainline, we should only > remember they may show up one day, but not put too much effort to > support them right now. > That makes more sense, although I still believe that you end up with a system wide setup where locks are statically allocated in some document beforehand. Either that or you will have to feed that other system with the list of constraints. Non the less, that's "unrelated". If we get an incoming message saying lckX:Y (or the global lckZ), we probably wouldn't define that in DT. We would need a way to resolve the hwlock-block "lckX" so we can request lock Y from that block. We would basically build the DT reference on the fly. I think this is a future problem to be solved and more importantly I don't think it's limited to hwlocks. If a system architect designs a system where a remote entity will do allocation of resources for us, they will most likely do so not only for hwlocks but also for gpios, irqs and other resources that we today reference with arguments in DT. Hopefully that will not happen anytime soon, so let's just ignore that problem for now and go for a simple binding that will cover todays use cases (with some thought into multi-block support). Regards, Bjorn -- 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
