tmp102 hwmon accessing temp1_input, max, max_hyst

tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

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.

 --
regards,
vinaysimha



-- 
regards,
vinaysimha

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Guenter Roeck]

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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

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.


On Thu, Feb 21, 2019 at 11:25 PM Guenter Roeck <linux@roeck-us.net> 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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Guenter Roeck]

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.

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.

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.

Thanks,
Guenter

> 
> On Thu, Feb 21, 2019 at 11:25 PM Guenter Roeck <linux@roeck-us.net> 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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

On Fri, Feb 22, 2019 at 12:18 AM Guenter Roeck <linux@roeck-us.net> 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
>
> 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.
>
> Thanks,
> Guenter
>
> >
> > On Thu, Feb 21, 2019 at 11:25 PM Guenter Roeck <linux@roeck-us.net> 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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Guenter Roeck]

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@roeck-us.net> 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@roeck-us.net> 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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

fyi,
this solution works with polling context.
https://github.com/vinaysimha/kernel-msm/commit/8d010a82ab5c2e3bd1f536c8bf5ea0bfe55eee55


On Mon, Feb 25, 2019 at 4:00 PM Vinay Simha B N <simhavcs@gmail.com> wrote:
>
> 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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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



--
regards,
vinaysimha

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

hi,

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.

On Mon, Feb 25, 2019 at 4:00 PM Vinay Simha B N <simhavcs@gmail.com> wrote:
>
> 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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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



-- 
regards,
vinaysimha

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Guenter Roeck]

On Wed, Feb 27, 2019 at 12:14:44PM +0530, Vinay Simha B N wrote:
> hi,
> 
> 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 zone data/configuration does not update thermal sensor limits,
primarily because the thermal subsystem's notion of zones does not match
the typical thermal sensor hardware. Thermal sensor hardware assumes
that limits are set to fixed values, but the thermal subsystem assumes
they are freely programmable. This can cause real trouble if a thermal
sensor's alarm signal is directly wired to some action. It also interfers
with the hwmon subsystem's notion of alarms, which also assume fixed
limits.

Guenter

> On Mon, Feb 25, 2019 at 4:00 PM Vinay Simha B N <simhavcs@gmail.com> wrote:
> >
> > 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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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
> 
> 
> 
> -- 
> regards,
> vinaysimha

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Vinay Simha B N]

hi,

how to set - deg C for the temperature/hysteresis in device tree , i
tried setting  hysteresis = <-8000>; , -8 deg C, but this leads to
syntax error. please suggest.

   trips {
                        hdmi_alert: trip0 {
                                temperature = <50000>;
                                hysteresis = <30000>;
                                type = "active";
                        };
        };

regards,
vinaysimha

On Thu, Feb 28, 2019 at 2:20 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Wed, Feb 27, 2019 at 12:14:44PM +0530, Vinay Simha B N wrote:
> > hi,
> >
> > 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 zone data/configuration does not update thermal sensor limits,
> primarily because the thermal subsystem's notion of zones does not match
> the typical thermal sensor hardware. Thermal sensor hardware assumes
> that limits are set to fixed values, but the thermal subsystem assumes
> they are freely programmable. This can cause real trouble if a thermal
> sensor's alarm signal is directly wired to some action. It also interfers
> with the hwmon subsystem's notion of alarms, which also assume fixed
> limits.
>
> Guenter
>
> > On Mon, Feb 25, 2019 at 4:00 PM Vinay Simha B N <simhavcs@gmail.com> wrote:
> > >
> > > 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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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
> >
> >
> >
> > --
> > regards,
> > vinaysimha



-- 
regards,
vinaysimha

Re: tmp102 hwmon accessing temp1_input, max, max_hyst

[Guenter Roeck]

On 4/2/19 1:36 AM, Vinay Simha B N wrote:
> hi,
> 
> how to set - deg C for the temperature/hysteresis in device tree , i
> tried setting  hysteresis = <-8000>; , -8 deg C, but this leads to
> syntax error. please suggest.
> 
>     trips {
>                          hdmi_alert: trip0 {
>                                  temperature = <50000>;
>                                  hysteresis = <30000>;
>                                  type = "active";
>                          };
>          };
> 

In general, negative numbers must be surrounded by ().

	x = <(-15)>;

However, such values must be read with of_property_read_s32(), and the "hysteresis"
property is not read this way. Providing it with a negative number won't work.
I assume it has to be positive.

Guenter

> regards,
> vinaysimha
> 
> On Thu, Feb 28, 2019 at 2:20 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Wed, Feb 27, 2019 at 12:14:44PM +0530, Vinay Simha B N wrote:
>>> hi,
>>>
>>> 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 zone data/configuration does not update thermal sensor limits,
>> primarily because the thermal subsystem's notion of zones does not match
>> the typical thermal sensor hardware. Thermal sensor hardware assumes
>> that limits are set to fixed values, but the thermal subsystem assumes
>> they are freely programmable. This can cause real trouble if a thermal
>> sensor's alarm signal is directly wired to some action. It also interfers
>> with the hwmon subsystem's notion of alarms, which also assume fixed
>> limits.
>>
>> Guenter
>>
>>> On Mon, Feb 25, 2019 at 4:00 PM Vinay Simha B N <simhavcs@gmail.com> wrote:
>>>>
>>>> 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@roeck-us.net> 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@roeck-us.net> 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@roeck-us.net> 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
>>>
>>>
>>>
>>> --
>>> regards,
>>> vinaysimha
> 
> 
>