From: Heyi Guo <guoheyi@linux.alibaba.com>
To: Ed Tanous <edtanous@google.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Does it make sense to create a centralized fan control module?
Date: Sun, 20 Jun 2021 16:48:59 +0800 [thread overview]
Message-ID: <2badabf6-1b45-f32d-856d-fe4023577ca7@linux.alibaba.com> (raw)
In-Reply-To: <CAH2-KxBJkBA1G6J5iMJ8nPEaX6qbO0qQGQ4ujhZ-TrZPjAS7oQ@mail.gmail.com>
Thanks for your comments; that sounds reasonable.
Heyi
On 2021/6/17 上午12:26, Ed Tanous wrote:
> On Thu, Jun 10, 2021 at 6:19 PM Heyi Guo <guoheyi@linux.alibaba.com> wrote:
>
>> Hi All,
>>
>> Right now fan related data like tacho and PWM is fetched in
>> dbus-sensors, and published to d-bus as sensor data, while fan control
>> is made in another module like pid-control, which can fetch data and set
>> value via d-bus.
>>
>> In some common sense, we may think about putting all fan related work
>> into one single module (which may be based on pid-control), i.e. it can
>> read tacho and PWM from hardware directly, calculate the required PWM by
>> some algorithm like PID, and then write to PWM hardware directly; the
>> data will also be published to d-bus for other modules to consume, like
>> fansensor from dbus-sensors.
>>
> To some extent, this design revolves around flexibility. Fans aren't
> necessarily tacho devices, and sensors aren't necessarily hwmon devices, so
> dbus is used as an abstraction to be able to make them all look the same.
> For example, an NCSI NIC might have both a temperature and a fan that
> phosphor-pid-control might want to control, but we don't want
> phosphor-pid-control to take a dependency on NCSI. While we could put all
> code for all possible sensor types into one daemon, that opens us up to the
> possibility that crashes could take down all of fan and thermal control,
> including the failsafe behavior. That would be an issue.
>
> It might be possible to handle these issues in a single daemon, but I
> haven't really seen a design that covered all the cases; Most
> implementations tend to take the simple approach (hwmon sensor + tacho
> device) and ignore the more complex setups.
>
>
>> Does it make sense to do that? Or is there any reason for the current
>> design?
>>
>> I'm new to OpenBMC and some of my understanding may be totally wrong.
>>
>> Looking forward to your expert advice.
>>
>> Thanks,
>>
>> Heyi
>>
>>
prev parent reply other threads:[~2021-06-20 8:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 1:14 Does it make sense to create a centralized fan control module? Heyi Guo
2021-06-11 1:23 ` Heyi Guo
2021-06-16 2:02 ` Heyi Guo
2021-06-16 2:49 ` [Phishing Risk] [External] " John Wang
2021-06-16 11:03 ` Heyi Guo
2021-06-16 16:26 ` Ed Tanous
2021-06-20 8:48 ` Heyi Guo [this message]
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=2badabf6-1b45-f32d-856d-fe4023577ca7@linux.alibaba.com \
--to=guoheyi@linux.alibaba.com \
--cc=edtanous@google.com \
--cc=openbmc@lists.ozlabs.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.