Hi Suman, On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna <s-anna@xxxxxx> wrote: > So far, we have not come across multiple controllers. I see your point, > and I think this also depends on the semantics of how you exchange the > lock id number. The agreement at the moment is on base_ids across > multiple SoC components. If the semantics involve exchanging the > controller instance, for example, then we might get away with it. But > that probably involves adding additional helpers to retrieve controller > instance in addition to lock number, or some other similar functions. Yes, this could be done too, but I agree it is less simple with no real win. > Sorry, I should have rephrased it better - by order, I meant the > inherent order between board early code and other drivers. With DT, we > cannot guarantee that right, as specific locks are requested from drivers. Yeah. > Understood. And we may have to assign the client association with a lock > as well. These are core changes that were actually not needed in the > non-DT case due to the inherent order as stated above. So, are you > suggesting that we add one more property to the controller node to mark > which are reserved, or rely on constructing this through DT tree parsing? I guess this is a question to the DT folks; both approaches work from hwspinlock perspective. In the past Arnd Benoit and myself were happy with adding one more property to the controller node, but this might be somewhat error prone as it leaves room for mistakes - developers can add hwlock phandles and forget to update the reserved property in the controller node. Thanks, Ohad. -- 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
