attached the tmp102 to thermal zone, i am able to read the
thermal_zone_get_temp, tz_dev->ops->get_trip_temp, get_trip_hyst.
the trip point of temperature and hystersis values does not get
updated in hwmon/hwmon1/temp1_max_hyst and hwmon/hwmon1/temp1_max.
Do we need to manually set these values, though we are attaching the
tmp102 to thermal_zone? otherwise will not get the interrupt.
please suggest.
&thermal_zones {
hdmi-thermal {
polling-delay-passive = <250>;
polling-delay = <1000>;
thermal-sensors = <&temp_sensor_u49 0>;
trips {
hdmi_alert: trip0 {
temperature = <75000>;
hysteresis = <2000>;
type = "passive";
};
hdmi_crit: trip1 {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
};
};
};
};
On Fri, Feb 22, 2019 at 1:19 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> 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
--
regards,
vinaysimha
