* Ohad Ben-Cohen <ohad@xxxxxxxxxx> [101020 12:12]: > On Wed, Oct 20, 2010 at 8:37 PM, Kevin Hilman > <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > >> Let's take the i2c-omap for example. > >> > >> It sounds like it must have a predefined hwspinlock, but what if: > >> > >> 1. It will use omap_hwspinlock_request() to dynamically allocate a hwspinlock > >> 2. Obviously, the hwspinlock id number must be communicated to the M3 > >> BIOS, so the i2c-omap will publish that id using a small shared memory > >> entry that will be allocated for this sole purpose > >> 3. we will make sure that 1+2 completes before the remote processor is > >> taken out of reset Guys, let's try to come up with a generic interface for this instead of polluting the device drivers with more omap specific interfaces. We really want to keep the drivers generic and platform independent. Sure we still have some omap specific stuff in the drivers, like cpu_is_omapxxxx, and omap specific dma calls, but those will be going away. Unless somebody has better ideas, I suggest we pass a lock function in the platform_data to the drivers that need it, and do the omap specific nasty stuff in the platform code. Regards, Tony -- 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
