driver design question

Philip Edelbrock phil at
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
>telling us?

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 mailing list