On Thu, Sep 1, 2011 at 9:39 AM, Paul Walmsley <p...@pwsan.com> wrote: > On Wed, 31 Aug 2011, Guenter Roeck wrote: > >> On Wed, Aug 31, 2011 at 08:36:43PM -0400, Paul Walmsley wrote: >> > Hi >> > >> > Some comments. >> > >> > On Wed, 31 Aug 2011, Keerthy wrote: >> > >> [ ... ] >> > >> > > +} >> > > + >> > > +/* Sysfs hook functions */ >> > >> > These should be conditionally compiled out if sysfs isn't compiled in. >> > >> The whole point of the hwmon subsystem is to expose hardware monitoring >> information >> to userland using sysfs. hwmon without sysfs doesn't make sense. >> >> So, if anything, it might make sense to disable the entire hwmon tree if >> sysfs is disabled. >> But please no conditionals in the code. > > Hmm. This IP block is more than just a sensor. It also can interrupt the > CPU and/or trigger a GPIO line (to shut down the chip) if the chip > temperature crosses some thresholds. On some OMAPs, the thresholds are > fixed; on others, they are software-programmable. That functionality > shouldn't require sysfs; it's almost closer to an x86 MCE.
The TSHUT thresholds are not even exposed through the sysfs nodes. This driver only creates sysfs nodes for TALERT thresholds. > > So based on your comments, it sounds like we should move that part of the > code to a different driver, and just leave the basic software thermal > monitoring here? What part of code should be moved? This driver does just the basic hardware monitoring and exposes configurable thresholds for t_hot and t_cold. This does not include t_shut configuration and handling. This is a simple hardware monitoring driver which does not cater to Thermal management. That is being discussed separately in other thread. > > > - Paul > -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
