Mugdha, > > >> > > >> This does not require any smart IPC and it will allow us to get > > rid of > > >> the omap_hwspinlock_request_specific() API and its early-callers > > >> requirement. > > > > > > Yes, that would indeed simplify things. > > > > Balaji, Nishant, are you OK with this ? > > > The problem with this approach is that the i2c driver would have to > sync up on the shared memory location that it uses to share the > information of the spinlock ID. What location would this be? How would > the i2c driver on the m3 know about this location? Does this mean > hard-coding of the shared memory address? If yes, then there would be > an impact to users if they wanted to change their memory map. Any kind > of hard-coding of this sort can be painful in such cases, especially > if it happens in multiple drivers. On the other hand, hard-coding > (reserving) spinlock IDs is a much safer option and does not impact > anything else. >
We can avoid the hard-coding of shared memory location if I2C Driver maps using iommu some dynamic memory for shared memory location to M3 virtual address and shares this information to I2c driver counter-part on M3 using the IPC call. But this might not be trivial and this would be against what Ohad mentioned about not requiring any smart IPC :). I prefer hard-coding of spinlock id to keep things simple. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
