Jean Delvare wrote: > Hi Matthew, > > On Sun, 19 Oct 2008 19:02:57 +0100, Matthew Garrett wrote: >> On Sun, Oct 19, 2008 at 06:20:00PM +0200, Jean Delvare wrote: >> >>> If you instead refer to a board-specific offset that should be applied >>> to compensate for the distance between the thermal sensor and the >>> graphics core, or for a non-standard thermal diode, the lm90 driver >>> exposes attribute temp2_offset so user-space can set and read the >>> temperature offset. >> Right. My kernel driver is in the privileged position of knowing >> precisely what offset should be applied to the lm90 readings, so doing >> this in-kernel would be advantageous :) > > There's nothing preventing you from accessing the LM99's registers > directly and retrieve the temperature that way. Alternatively, we could > add an internal interface to access some of the hwmon device features. I think that we really should be thinking about adding an internal interface, I think other parts of the kernel poking at IC registers where the IC is managed by another driver is a *bad* idea. With that said, I have no experience in this field and no idea where to start. >>> Why do you want to retrieve the temperature value from the kernel? >>> Please explain your use case. >> I'm implementing power management for GPUs. These typically have several >> different performance constraints, but one of them is chip temperature. >> The maximum supported temperature is generally exported via tables in >> the graphics card BIOS, so it's necesssary for the kernel driver to be >> aware of the current temperature in order to limit the available >> performance modes to ensure the GPU stays within its thermal envelope. > > OK, I see. Then indeed it makes sense to deviate from the traditional > hwmon model. You could prevent auto-detection of the hwmon device (by > dropping I2C_CLASS_HWMON from i2c_adapter.class) and instantiate the > lm99 device manually instead (using i2c_new_device()). This gives you > two things: a handle on the created device (so that you can access the > chip registers directly if needed, and its private data too) and the > possibility to pass platform data to the driver for specific > initialization purposes. The lm90 driver doesn't implement the later > yet, but we have another driver doing that (lm87) so it could be added > if needed. > +1 Regards, Hans
