lkml.org 
[lkml]   [2020]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 3/3] hwmon: Add Baikal-T1 PVT sensor driver
From
Date
On 5/27/20 10:05 AM, Serge Semin wrote:
> On Wed, May 27, 2020 at 09:58:00AM -0700, Guenter Roeck wrote:
>> On 5/27/20 9:52 AM, Serge Semin wrote:
>>> On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
>>>> On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
>>>
>>> [nip]
>>>
>>>>> +
>>>>> +=============================== ======= =======================================
>>>>> +Name Perm Description
>>>>> +=============================== ======= =======================================
>>>>> +update_interval RW Measurements update interval per
>>>>> + sensor.
>>>>> +temp1_type RO Sensor type (always 1 as CPU embedded
>>>>> + diode).
>>>>> +temp1_label RO CPU Core Temperature sensor.
>>>>> +temp1_input RO Measured temperature in millidegree
>>>>> + Celsius.
>>>>> +temp1_min RW Low limit for temp input.
>>>>> +temp1_max RW High limit for temp input.
>>>>> +temp1_min_alarm RO Temperature input alarm. Returns 1 if
>>>>> + temperature input went below min limit,
>>>>> + 0 otherwise.
>>>>> +temp1_max_alarm RO Temperature input alarm. Returns 1 if
>>>>> + temperature input went above max limit,
>>>>> + 0 otherwise.
>>>>> +temp1_trim RW Temperature sensor trimming factor in
>>>>> + millidegree Celsius. It can be used to
>>>>> + manually adjust the temperature
>>>>> + measurements within 7.130 degrees
>>>>> + Celsius.
>>>>
>>>> vs. standard ABI:
>>>>
>>>> temp[1-*]_offset`
>>>> Temperature offset which is added to the temperature reading
>>>> by the chip.
>>>>
>>>> Unit: millidegree Celsius
>>>>
>>>> If you really think this is necessary, why not use the standard ABI ?
>>>
>>> That would have made much more sense.) I'll replace the handwritten temp1_trim
>>> with the standard temp1_offset attribute in v4 shortly today. Thanks for pointing
>>> this out.
>>>
>>
>> Sorry for not realizing this earlier. The added explanation
>> made all the difference.
>
> No worries. I'll fix it in v4. What about the clk_get_rate() part of the code?
> You had a comment regarding it in v2. I responded with justification that we can
> leave it as is. If you still disagree, then I create the clock rate caching in the
> private data at the probe() stage.
>
Reason asking for it is that clk_get_rate() is unnecessarily costly if the rate
doesn't change. But it isn't worth bike shedding about it.

Guenter

> -Sergey
>
>>
>> Guenter

\
 
 \ /
  Last update: 2020-05-27 20:49    [W:0.093 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site