Hi, On Wed, 2008-06-04 at 17:11 -0700, ext Kevin Hilman wrote: > The same can happen even with the locking. If someone asks for the > rate, and then another thread changes the rate right after, the thread > who asked for the rate has an out-of-date value. I don't understand how this would materialize in practice: - if the rate is beign changed by 2 threads from the same driver, then the driver itself needs to take care of its internal state and coherency - if 2 different drivers are contending the same clock, then 2 children clocks should be created and the clock fw would take care of failing the request of the 2nd child, if it is incompatible with the rate set by the 1st one - if a dvfs change is responsible of changing the rate supplied to a driver which asked it with clk_get_rate(), the dvfs transition has no reason to happen in case it would violate the constraints set by clock users. Does this make sense? -- Cheers, Igor --- Igor Stoppa Nokia Devices R&D - Helsinki -- 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
