> > Quick note: The refresh frequency limit was introduced because the > > hardware would give bad results if you polled it too fast. So, > > depending on what the datasheet for the chip says, we adjust the > > max polling frequency to match. So this was to ensure accurate > > results from the hardware, not as a performace optimization. > Take a look at the ADM1026 driver (by Phil P.) as a counter-example. > The update routine is apropos to this thread. He uses two different > refresh frequencies - the slower one for config data. I thought this > was a good idea when I first saw it. Exactly what I had in mind. I didn't know someone else already did that :) After some more thinking however, I'm not sure it's what we really want. We are talking (correct me if I'm wrong there) about data that should not change *at all*, not data that should not change *often*. So sampling their value every 5 minutes doesn't make much sense. If they change and we are not aware of the change, it's likely to cause trouble that will solve only up to 5 minutes later. The user will probably get mad about this (by the time he/she tries to figure out what's wrong, the problem will solve by itself). So I think we should opt for one of the following policy: 1* We refresh these values as often as the other ones (what most of our drivers do) and don't care about the performance cost. Play it safe, Phil E. said. 2* We say these values should *NOT* change, we don't sample them, and if something goes wrong, obviously it's not our fault (though the user will certainly complain to us). We can enable a check (that is, sampling the should-not-change data as in 1* and emit a warning if we see a change in the values) in debug mode (or additional parameter?) to catch the problem. One more thought though: remember that these things are very unlikely to happen. We have the adm1026 driver which as a different policy, now the adm1025 has its own one too. These are good tests. If we have no bad feedback about these, it must mean it's safe to change our global policy to either of those. > > Now, your point about reducing a significant amount of latency is a > > good one. That's a reasonable reason for such an optimization. I'm > > not sure if it is a strong enough reason, though. I think we'd need > > to do a little math to figure out exactly how much it 'costs' to > > read limits and what it would save us to poll them less frequently. > > It depends on the chip of course - but I think the ADM1026 driver > might be a good model to follow for others which are deemed worth > optimizing. What about trying some real-life tests (that's what it's all about after all)? I could try the different policies on the w83781d driver and measure how much time module loads and data refreshs take. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
