On Thursday 08 September 2011, Ohad Ben-Cohen wrote: > On Thu, Sep 8, 2011 at 5:47 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > I think a number would work here but is not optimal for the device tree > > representation. I think a better binding would be to encode it like > > interrupt numbers, where every device that uses a hwspinlock will describe > > that as a combination of phandle to the hwspinlock controller and > > identifier to be used by that controller > > I'm not sure. > > This implies that devices are hardwired to the specific > controller+identifier, which is true for interrupts, but not for > hwspinlocks. As a result the hardware depicted by such representation > would be imprecise and might unnecessarily limit the software. > > hwspinlock devices are really just a pool of locks, which are not > inherently bound to any device: any master that can initiate > read/write bus access can use any of the locks (hardware-wise). One > just needs to make sure that ownership of the locks, even if > determined dynamically at runtime, is managed correctly. ok > I think the phandle+identifier approach is very elegant to achieve > static allocation of the hwspinlocks, and some boards will definitely > need it (e.g. those unlucky designs which arbiter i2c access using an > hwspinlock). > > But wouldn't that limit us from providing dynamic allocation of > hwspinlocks ? I was told about teams working on complex multimedia use > cases which involves numerous object sharing and require actually more > hwspinlocks than exist (so they're planning on multiplexing several > logical locks on a single hwspinlock). They use dynamic allocation of > hwspinlocks in order to allow different hwspinlocks users to co-exist > (but naturally not run together at the same time). Good point. I guess we will need both static and dynamic allocation then. You need the static allocation for cases where the other user of the spinlock is not under the control of Linux, but is known at boot time. For dynamic allocation, my impression is that we don't need any link from the spinlock user device to the controller at all, but instead the controller should have a list of the available spinlocks. In a case where you have three operating systems running independently on the same hardware and each of the shares one spinlock with the other two, you want to be able to model in the device tree which spinlocks are already known to the other instances and therefore fixed, which ones are available to the local OS and which ones are not available. Arnd -- 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
