Need some guidance on adhering to the sysfs standards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Juerg Haefliger wrote:
> Hi Jean,
> 
> On 4/22/07, Jean Delvare <khali at linux-fr.org> wrote:
>> Hi Juerg,
>>
>> On Thu, 19 Apr 2007 12:04:28 -0700, Juerg Haefliger wrote:
>>> George, Jean,
>>>
>>> I'm struggling with the same issue for the DME1737 I'm currently
>>> working on. This chip also features temp zones and "hottest of x,y,z"
>>> PWM control. The current sysfs standard is not flexible enough to
>>> handle these features, especially the combination of a single PWM
>>> being controlled by multiple temp inputs and multiple PMWs being
>>> controlled by the same temp input. I believe we need another layer of
>>> mapping. I.e. temp->pwm is not sufficient, but rather temp->zone->pwm.
>>>
>>> I therefore propose the add the following sysfs attributes to our standard:
>>>
>>> zone[1-*]_auto_channels_temp   for temp-to-zone mapping
>>> pwm[1-*]_auto_channels_zone   for zone-to-pwm mapping
>>> zone[1-*]_auto_point[1-*]_temp   for zone temp auto points.
>> I don't see what value it adds compared to what we currently have.
>>
>> We have pwm[1-*]_auto_channels_temp, which is a bit vector. We have one
>> file per PWM, one bit per temperature channel, so all in all we have a
>> Npwm x Ntemp matrix, or N-N relation between PWM and temperatures. This
>> already allows us to handle cases such as "the hottest of tempA and
>> tempB control pwmC" or "tempD controls pwmE and pwmF".
> 
> Yes, I understand that.
> 
> 
>> You propose to add the concept of zone. According to the above, each
>> zone could include any temperature channel, so we have a N-N relation
>> between zones and temperatures. Then you express another N-N relation
>> between PWM channels and zones. As far as I can see, this results in a
>> N-N relation between temperatures and PWM, just expressed differently.
>> Am I missing something? What do you think it would let us express,
>> which the current model doesn't?
> 
> What I can't seem to map to our current standard (or maybe I just
> don't see it) is the concept of multiple sets of thermal thresholds
> for a single temp input. Example: pwm2 is controlled by zone2 and pwm3
> is controlled by zone3 but both zone2 and zone3 are controlled by
> temp3. Both zone2 & 3 have different thermal thresholds.
> 
> With the current standard I can only apply one set of thresholds to
> temp3 via temp3_auto_point[1-*]_temp.
> 

Thats easy, AFAIK you can have either temp[1-*]_auto_point[1-*]_temp,
or pwm[1-*]_auto_point[1-*]_temp, iow you can couple the autopoints
to either a temp channel or a pwm channel depending on if the
thresholds are set per temp channel or per pwm channel.

I'm not 100% sure though, so lets wait what others have to say too.

Regards,

Hans




[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux