On Fri, Apr 01, 2011 at 08:39:43AM -0400, J, KEERTHY wrote: > Hello All, > > I am trying to implement a driver for the OMAP temperature sensor. > It is an on chip sensor. > > The sensor is responsible for reporting the temperature. The sensor > has configurable thresholds. The user can configure the thresholds. > An interrupt will be generated as soon as there the temperature > thresholds are crossed. > > Two possible approaches for the driver: > > 1) The entire driver resides in drivers/hwmon directory. The driver > containing all the sysfs nodes to be exposed to the user. > The interrupt handlers are also part of this driver. The device > registration happens in a OMAP arch specific file residing > in arch/arm/mach-omap2 directory. > > 2) The intialization and the interrupt handling done in a > separate driver file residing in in arch/arm/mach-omap2 or > drivers/misc directory. > The device registration happens in a OMAP arch specific file residing > in arch/arm/mach-omap2 directory. > Only the sysfs nodes will be exposed through a hwmon > driver residing in drivers/hwmon. > That really depends if it does anything else besides hw monitoring. A hw monitoring driver can support interrupts, and trigger a poll event on an alarm file if it gets one. But it should only perform hw monitoring functionality. If that interrupt triggers other activity, a thermal subsystem driver may be more appropriate. Thanks, Guenter > Please suggest the best alternative among the two or if any new > design for the requirements is better. > > -- > Regards and Thanks, > Keerthy > > _______________________________________________ > lm-sensors mailing list > lm-sensors@xxxxxxxxxxxxxx > http://lists.lm-sensors.org/mailman/listinfo/lm-sensors -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
