driver design question
phil at edgedesign.us
Tue Jul 29 00:27:16 CEST 2003
BTW- I'm glad you're looking for optimizations and clean-ups. I
appreciate your efforts. I think this is a topic which is really has
valid points either way. As you suggest, I think I am more leaning
towards playing it safe. :')
I'll make a few comments and clarifications inline, and perhaps Mark and
some others can weigh in.
Jean Delvare wrote:
>Is there any way values can be written to the driver's register without
I think any other communication with the chip which isn't through our
driver (Bios? or some other code?) might change the values, although it
is unlikely. It's also possible that a driver may be misdetected or
forced. It would be odd if the driver gave misleading 'correct' limit
readings in these cases. I don't think it is worth the risl
In a nutshell, I think lower level drivers which talk to hardware
shouldn't do any internal caching or optimizing which isn't nessesary.
I.e., when values are asked for, it should talk directly with the
hardware to ask for them and not make any assumptions.
Now, for user-space apps, it could be more justifiable to cache or
assume values. At least, I'd rather see those sorts of hacks done in
user-space than kernel driver space. For this paricular issue (if we
are trying to optimize speed or limit transaction numbers over the I2C
bus), it doesn't buy anything so it is a moot point.
>No (at least none I am aware of). But I don't like the idea of our
>driver doing something that could be avoided with no drawback. Please
>realize that for each update, which can occur typically as often as once
>every 1.5 second, 1/3 of the work is for the current values, which is
>legitimate, and 2/3 of the work is for limits, which 100% of the time
>AFAIK did not change. Multiplying the amount of work by three is more
>than just overhead, isn't it?
>Thus my question, and I ask it again, maybe more clearly than the first
>time. How could the chip's register be changed without using our driver?
Well, I guess it is a matter of ideals. I've thought of kernel hardware
drivers as being an inbetween for the user-space apps and the actual
hardware with absolutely as little tainting of the data as possible.
Even if the values in the hardware's registers are unlikely to change or
change infrequently, we still should pass values straight through and
not make any assumptions on the data in code.
As long as overhead and processor loading isn't an issue, I'd suggest we
not cache or code in any value/limit assumptions into the code. I2C
transactions are slow, but they cause little (if any) CPU loading or
resource hogging. Even as far as percentage usage of the I2C bus, it is
small. I can't see any possible significant performance gains by
caching things like limits. Also, there are at least some potential
drawbacks (at least marginally more than simply 'no drawbacks'), so I
see some additional risk with no gain.
BTW- The worst offender of reading values over and over with little
chance of change is the eeprom driver. For each device, if I remember
correctly, each byte read takes two I2C transactions for 256 bytes! So,
if you have 4 dimms (with an eeprom on each), you are doing over 2
thousand transactions. Still, though, this take little time and almost
no CPU overhead, so it doesn't seem to hurt anything.
Anyways, that's my $0.02. :')
More information about the lm-sensors