Tomasz, On Fri, Oct 11, 2013 at 7:06 PM, Tomasz Figa <t.figa@xxxxxxxxxxx> wrote: > Well, it's some kind of difference indeed. However, how often can > a frequency transition happen? > > I believe that ondemand allows minimum sampling period of > 100 * transition latency, so even without considering the PLL lock time, > we would have at most a single delay of ~400 us every ~40 ms, during > which remaining CPUs are operating normally, because of switching to > MPLL temporarily. > > A bit more interesting case would be the Android interactive governor, > which scales up the CPU on any wake-up event, but I don't believe any > user would notice the extra 17,5 us from touching the screen to seeing > a menu animation, for example. OK. You've clearly looked at this more than I. :) I was merely recalling conversations that others had over a year ago and remembering some of our engineers being concerned about latencies even at this level, but I'm not sure if they had hard data. I added Sonny to see if he might remember more, though I don't think he was the one pushing for optimizations in the past. Note that we actually are using the Interactive governor in our systems, and it is the interactive "time to spin up on user input" that I'm most worried about. ...but you're right that I think the user perceivable values are in the 10s of milliseconds and not in the 10s of microseconds. > Please correct me if I'm missing something here. > >> Anyway, when it's something as simple as passing in a parameter to get >> it right, it seems worth doing. > > Sure, any patches improving things are welcome, I was just wondering > whether the improvement will be of any significance. Looking forward > to respective patches, hoping that they will not complicate the code > too much (although we already have a struct for PLL parameters, so they > should not). I'd still love to see the change land that allows this to be right. 17.5us may not matter much, but with the PLL parameter struct it should be pretty easy / clean. ...and it also allows us to map the number back the user manual, which can make it easier to understand (there's currently nothing documenting why the number is 270, not 250 or 200). -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |