On Fri, Oct 22, 2010 at 11:59 AM, Kamoolkar, Mugdha <mugdha@xxxxxx> wrote: >> From: Ohad Ben-Cohen [mailto:ohad@xxxxxxxxxx] >> I agree. >> >> But we seem to have this sort of problem anyway: >> ... > That is true. Perhaps we should consider adding a software > implementation over HW spinlocks. Yes, this is probably inevitable. It would also be useful for the user space implementation of TI's RingIO and FrameQueue protocols coming in Syslink 3.0, which will also not be able to directly use the hwspinlock because of the same reasons. This layer would maintain the owner of each (virtual) lock in a non-cacheable shared memory entry, together with the id of the hwspinlock that would protect that 'owner' entry. This way we no longer need to use predefined hwspinlocks (the id of the hwspinlock is announced in the shared memory entry). So we can ditch the _request_specific() API, and we can move to arch_initcall (just to beat the current race with i2c-omap). > We were anyway considering doing this, > because the number of hw spinlocks available for our usage are not > sufficient when we look at multi-channel use-cases. Sure, this layer can provide any number of locks over a single hwspinlock (with the obvious price of hwspinlock contention). -- 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
