On Fri, Feb 22, 2019 at 12:32:08AM +0530, Vinay Simha B N wrote: > On Fri, Feb 22, 2019 at 12:18 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > On Thu, Feb 21, 2019 at 11:46:32PM +0530, Vinay Simha B N wrote: > > > guenter, > > > > > > i want to use these three tmp102 temp1_input, max and max_hys in > > > dsi2hdmi(adv7533) driver to enable or disabled based on temperature > > > range. > > > > > > https://github.com/vinaysimha/kernel-msm/commit/8ee2b9104fa56765320d4846086d91b8271f5609 > > > > > > dsi2hdmi operating temperature range is -10 to 85 deg C, we will > > > enable dsi2hdmi only when temperate in operating range otherwise will > > > disable the chip. > > > > > Do you envision a system utilizing this chip that would have an operating range > > outsize -10 .. +85 degrees C ? That seems to be quite unlikely. > this system sits in a place below this temperature range, cpu can > handle upto -30, but the adv7535(dsi2hdmi) operating range -10 to +85, > so we want the system to be on and disable and enable display based on > temp range. > > > > Your solution will only work for a system with exactly one tempperature sensor; > > otherwise there is no guarantee that the sensor will be instantiated as hwmon1 > we do have two temperature sensor, currently i had used hwmon1 for testing, > i have to read hwmon1 otherwise interrupt will not get cleared. > thought to have polling method also, since in this code reading from > userspace is not feasible, is it possible to optimize, any suggestion? > either i need to have global variable declared in adv7511_drv.c and > export it to tmp102.c driver . please suggest You might want to consider attaching the tmp102 to a thermal zone, and then use thermal_zone_get_temp() to read the temperature. > > > > Either case, a decison like this would not only apply to a single chip, > > but to other chips in the system. It might be in the scope of power > > or thermal management, though it seems to me that it might make more > > sense to control it from user space. > > > > Overall, with the above in mind, I don't think a hwmon specific solution > > would make sense. If a solution is really warranted in the first place > > (I really wonder about that operating range), it should be implemented > > as generic solution which applies to the rest of the system as well. > > > > There are some pieces which should be implemented in the hwmon driver - > > for example, it looks like your code implements interrupt handling for > > the tmp102. That should be handled in the tmp102 driver, which would > > then read the alert bit and report the status as temp1_alarm. > initially i had implemented irq in tmp102.c , but how to inform this > information to dsi2hdmi(adv7511_drv.c) > any references how temp1_alarm is used. This would require some work, since the infrastructure does not currently support handling thermal alarms. In a nutshell, - the tmp102 driver would implement an interrupt handler - the interrupt handler would notify the hwmon core that an interrupt was observed. This notification callback would have to be implemented. It would notify userspace using sysfs_notify() and possibly with a udev event, and it would notify the thermal core by calling thermal_zone_device_update(). I don't know how the thermal core would then notify the dsi2hdmi driver. Guenter > > > > Thanks, > > Guenter > > > > > > > > On Thu, Feb 21, 2019 at 11:25 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > > > > > On Thu, Feb 21, 2019 at 08:21:09PM +0530, Vinay Simha B N wrote: > > > > > hi, > > > > > > > > > > could you please suggest, how to export_symbol the tmp102 temp1_input, max > > > > > and max_hyst values to another kernel driver? > > > > > > > > > > We can acess the values > > > > > from filp_open("/sys/class/hwmon/hwmon1/temp1_input", O_RDONLY, 0); in > > > > > kernel space, but is there better apporach to access the values in the > > > > > kernel space. > > > > > > > > > There is no in-kernel API to do that, and I do not immediately see > > > > the purpose. Either case, accessing the sysfs attribute directly is > > > > as wrong as it can get, if for nothing else since there is no guarantee > > > > that this will always be the hwmon1 device. > > > > > > > > Can you explain what you are trying to do ? > > > > > > > > Thanks, > > > > Guenter > > > > > > > > > > > > -- > > > regards, > > > vinaysimha > > > > -- > regards, > vinaysimha
