All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Guinot <simon@sequanux.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [lm-sensors] [PATCH 1/2] hwmon: add generic GPIO fan driver
Date: Tue, 19 Oct 2010 08:36:56 +0000	[thread overview]
Message-ID: <20101019083656.GE29120@kw.sim.vm.gnt> (raw)
In-Reply-To: <20101019065221.GA12406@ericsson.com>


[-- Attachment #1.1: Type: text/plain, Size: 2588 bytes --]

Hi Guenter,

On Mon, Oct 18, 2010 at 11:52:21PM -0700, Guenter Roeck wrote:
> On Mon, Oct 18, 2010 at 04:36:10PM -0400, Simon Guinot wrote:
> [ ... ]
> > > I don't really understand the value of supporting pwm attributes,
> > > since you have to convert those to rpm anyway. Why not just stick
> > > with fan1_input and fan1_target ? This would simplify the code a lot.
> > 
> > I don't know very well the hwmon API. I have simply been fooled by the
> > sysfs-interface document which claim that fan[1-*]_target only make
> > sense for a closed-loop fan. Moreover, I was expecting gpio-fan to be
> > compliant with the fancontrol shell script...
> > 
> > But anyway, you are right. I just don't want the pwm interface.
> > 
> Thinking more about this, another option might be to keep using
> the pwm interface (for fancontrol), but simplify your code.
> Your transitions are currently pwm -> rpm -> ctrl and vice versa.
> However, direct conversion pwm -> ctrl should also be possible
> and would be much simpler than the two-stage conversion.
> 
> To do that, you could map num_speed directly to the pwm range of (0..255).
> Something like
> 
> 	pwm = DIV_ROUND_CLOSEST(speed_index * 255, num_speed - 1);
> and
> 	speed_index = pwm * (num_speed - 1) / 255;
> 
> Then use speed_index to get control value and rpm from the speed table.
> 
> Would that make sense ? You could then also provide fan1_target
> for direct fan speed control.

Unfortunately, I believe this approximation is not possible. Take a look
at the Network Space Max fan speed array:

/* Designed for fan 40x40x16: ADDA AD0412LB-D50 6000rpm@12v */
static struct gpio_fan_speed netspace_max_v2_fan_speed[] = {
        {    0,  0 },
        { 1500, 15 },
        { 1700, 14 },
        { 1800, 13 },
        { 2100, 12 },
        { 3100, 11 },
        { 3300, 10 },
        { 4300,  9 },
        { 5500,  8 },
};

The function rpm_speed(index) is really not linear. I am not sure about
the resulting behaviour when this will be used by a userland fan control
process...

If the pwm interface must be exported, I think we have to respect the
fan speed array. But as you said, maybe the work is rather on the
fancontrol script side.

As a first step, we could keep the heavy pwm interface. Once the
fancontrol script (or something else) will be able to handle the rpm
attributes, we will drop the pwm compatibility.
Simply remove the gpio-fan pwm interface seems a good option too...

Both make sense for me. Let me know your favourite way.

Thanks,

Simon

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: simon@sequanux.org (Simon Guinot)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] hwmon: add generic GPIO fan driver
Date: Tue, 19 Oct 2010 08:36:56 +0000	[thread overview]
Message-ID: <20101019083656.GE29120@kw.sim.vm.gnt> (raw)
In-Reply-To: <20101019065221.GA12406@ericsson.com>

Hi Guenter,

On Mon, Oct 18, 2010 at 11:52:21PM -0700, Guenter Roeck wrote:
> On Mon, Oct 18, 2010 at 04:36:10PM -0400, Simon Guinot wrote:
> [ ... ]
> > > I don't really understand the value of supporting pwm attributes,
> > > since you have to convert those to rpm anyway. Why not just stick
> > > with fan1_input and fan1_target ? This would simplify the code a lot.
> > 
> > I don't know very well the hwmon API. I have simply been fooled by the
> > sysfs-interface document which claim that fan[1-*]_target only make
> > sense for a closed-loop fan. Moreover, I was expecting gpio-fan to be
> > compliant with the fancontrol shell script...
> > 
> > But anyway, you are right. I just don't want the pwm interface.
> > 
> Thinking more about this, another option might be to keep using
> the pwm interface (for fancontrol), but simplify your code.
> Your transitions are currently pwm -> rpm -> ctrl and vice versa.
> However, direct conversion pwm -> ctrl should also be possible
> and would be much simpler than the two-stage conversion.
> 
> To do that, you could map num_speed directly to the pwm range of (0..255).
> Something like
> 
> 	pwm = DIV_ROUND_CLOSEST(speed_index * 255, num_speed - 1);
> and
> 	speed_index = pwm * (num_speed - 1) / 255;
> 
> Then use speed_index to get control value and rpm from the speed table.
> 
> Would that make sense ? You could then also provide fan1_target
> for direct fan speed control.

Unfortunately, I believe this approximation is not possible. Take a look
at the Network Space Max fan speed array:

/* Designed for fan 40x40x16: ADDA AD0412LB-D50 6000rpm at 12v */
static struct gpio_fan_speed netspace_max_v2_fan_speed[] = {
        {    0,  0 },
        { 1500, 15 },
        { 1700, 14 },
        { 1800, 13 },
        { 2100, 12 },
        { 3100, 11 },
        { 3300, 10 },
        { 4300,  9 },
        { 5500,  8 },
};

The function rpm_speed(index) is really not linear. I am not sure about
the resulting behaviour when this will be used by a userland fan control
process...

If the pwm interface must be exported, I think we have to respect the
fan speed array. But as you said, maybe the work is rather on the
fancontrol script side.

As a first step, we could keep the heavy pwm interface. Once the
fancontrol script (or something else) will be able to handle the rpm
attributes, we will drop the pwm compatibility.
Simply remove the gpio-fan pwm interface seems a good option too...

Both make sense for me. Let me know your favourite way.

Thanks,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101019/bb23fe5a/attachment-0001.sig>

  reply	other threads:[~2010-10-19  8:36 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22 10:54 [lm-sensors] [PATCH 4/5] hwmon: DNS323 rev C1 fan support Benjamin Herrenschmidt
2010-05-22 10:54 ` Benjamin Herrenschmidt
2010-05-22 11:00 ` [lm-sensors] " Benjamin Herrenschmidt
2010-05-22 11:00   ` Benjamin Herrenschmidt
2010-10-13 11:59 ` [lm-sensors] " Simon Guinot
2010-10-13 11:59   ` Simon Guinot
2010-10-13 16:34   ` [lm-sensors] " Guenter Roeck
2010-10-13 16:34     ` Guenter Roeck
2010-10-17 15:40     ` Simon Guinot
2010-10-17 15:40       ` Simon Guinot
2010-10-17 15:50       ` [lm-sensors] [PATCH 1/2] hwmon: add generic GPIO fan driver Simon Guinot
2010-10-17 15:50         ` Simon Guinot
2010-10-17 15:50         ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Simon Guinot
2010-10-17 15:50           ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Simon Guinot
2010-10-22  1:53           ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Guenter Roeck
2010-10-22  1:53             ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Guenter Roeck
2010-10-22  2:08             ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Nicolas Pitre
2010-10-22  2:08               ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Nicolas Pitre
2010-10-22  4:30               ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Guenter Roeck
2010-10-22  4:30                 ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Guenter Roeck
2010-10-22  9:29                 ` [lm-sensors] [PATCH] [ARM] Kirkwood: add fan support for Network Simon Guinot
2010-10-22  9:29                   ` [PATCH] [ARM] Kirkwood: add fan support for Network Space Max v2 Simon Guinot
2010-10-22  9:59                   ` [lm-sensors] [PATCH] [ARM] Kirkwood: add fan support for Guenter Roeck
2010-10-22  9:59                     ` [PATCH] [ARM] Kirkwood: add fan support for Network Space Max v2 Guenter Roeck
2010-10-22  8:27               ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Simon Guinot
2010-10-22  8:27                 ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Simon Guinot
2010-10-22  9:58                 ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Guenter Roeck
2010-10-22  9:58                   ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Guenter Roeck
2010-10-22 18:39                 ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Guenter Roeck
2010-10-22 18:39                   ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Guenter Roeck
2010-10-22 18:50                   ` [lm-sensors] [PATCH 2/2] [ARM] Kirkwood: add fan support for Nicolas Pitre
2010-10-22 18:50                     ` [PATCH 2/2] [ARM] Kirkwood: add fan support for Network Space Max v2 Nicolas Pitre
2010-10-18 16:08         ` [lm-sensors] [PATCH 1/2] hwmon: add generic GPIO fan driver Guenter Roeck
2010-10-18 16:08           ` Guenter Roeck
2010-10-18 18:00           ` [lm-sensors] " Chris Moore
2010-10-18 18:00             ` Chris Moore
2010-10-18 18:35             ` [lm-sensors] " Guenter Roeck
2010-10-18 18:35               ` Guenter Roeck
2010-10-18 20:36           ` [lm-sensors] " Simon Guinot
2010-10-18 20:36             ` Simon Guinot
2010-10-18 20:50             ` [lm-sensors] " Guenter Roeck
2010-10-18 20:50               ` Guenter Roeck
2010-10-19 11:46               ` [lm-sensors] " Simon Guinot
2010-10-19 11:46                 ` Simon Guinot
2010-10-19 14:52                 ` [lm-sensors] " Guenter Roeck
2010-10-19 14:52                   ` Guenter Roeck
2010-10-19  6:52             ` [lm-sensors] " Guenter Roeck
2010-10-19  6:52               ` Guenter Roeck
2010-10-19  8:36               ` Simon Guinot [this message]
2010-10-19  8:36                 ` Simon Guinot
2010-10-19 15:15                 ` [lm-sensors] " Guenter Roeck
2010-10-19 15:15                   ` Guenter Roeck
2010-10-19 19:30                   ` [lm-sensors] " Simon Guinot
2010-10-19 19:30                     ` Simon Guinot
2010-10-21 20:07           ` [lm-sensors] " Simon Guinot
2010-10-21 20:07             ` Simon Guinot
2010-10-21 20:26             ` [lm-sensors] " Guenter Roeck
2010-10-21 20:26               ` Guenter Roeck
2010-10-19 22:03         ` [lm-sensors] " Guenter Roeck
2010-10-19 22:03           ` Guenter Roeck
2010-10-20  0:19           ` [lm-sensors] " Simon Guinot
2010-10-20  0:19             ` Simon Guinot
2010-10-20  0:50             ` [lm-sensors] " Guenter Roeck
2010-10-20  0:50               ` Guenter Roeck
2010-10-20  7:59               ` [lm-sensors] " Simon Guinot
2010-10-20  7:59                 ` Simon Guinot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101019083656.GE29120@kw.sim.vm.gnt \
    --to=simon@sequanux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.