On Thu, 2012-07-19 at 05:27 -0500, Menon, Nishanth wrote: > On Thu, Jul 19, 2012 at 4:49 AM, Tero Kristo <t-kristo@xxxxxx> wrote: > > > > Zero doesn't mean no context loss. If counter was previous MAX_INT, if > > it goes to zero it is still a context loss, as the counter value > > differs. Drivers do check against diff in the context loss counter, and > > if there is one, they do restore which is the right way to handle it. No > > need to unnecessarily make this more complicated than it is. > > so we flip the responsibility of overflow to drivers. considering a > similar scenario of jiffies > /* > * These inlines deal with timer wrapping correctly. You are > * strongly encouraged to use them > * 1. Because people otherwise forget > * 2. Because if the timer wrap changes in future you won't have to > * alter your driver code. > * > * time_after(a,b) returns true if the time a is after time b. > ... > */ > from past experience, it is highly possible that drivers never get > this right. if the intent is just to let the drivers know context was > lost, why not go back to the alternate possibility of a bool > lost_context which tells the driver if it lost context since it last > called the lost_context api. This goes to the discussion whether the API of lost context stuff is correct or not, and goes out of scope for this set. I am just attempting to bring omap4 to omap3 level in the first place, we can discuss about the potential API problems separately, and a change like that should be relatively easy to implement anyway.... but will break several drivers. -Tero -- 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
