From: Heyi Guo <firstname.lastname@example.org> To: John Wang <email@example.com> Cc: Zhikui Ren <firstname.lastname@example.org>, Jae Hyun Yoo <email@example.com>, Vernon Mauery <firstname.lastname@example.org>, OpenBMC Maillist <email@example.com>, Ed Tanous <firstname.lastname@example.org>, Josh Lehan <email@example.com>, Ed Tanous <firstname.lastname@example.org>, Patrick Venture <email@example.com> Subject: Re: [Phishing Risk] [External] Re: Does it make sense to create a centralized fan control module? Date: Wed, 16 Jun 2021 19:03:49 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAH0XSJupSg54T_6qpPPHHBjHcR5OFZ3+VcaGEaP+PR+6F5ny1g@mail.gmail.com> Hi John, Thanks for your reply. Please see my comments inline. On 2021/6/16 上午10:49, John Wang wrote: > On Wed, Jun 16, 2021 at 10:02 AM Heyi Guo <email@example.com> wrote: >> Hi All, >> >> Any comments for my questions at the top of this thread? >> >> Thanks, >> >> Heyi >> >> >> On 2021/6/11 上午9:23, Heyi Guo wrote: >>> Please ignore my early emails; only this one is the final version. I >>> must have misused some shortcut key to send the unfinished versions >>> while I wanted to save it locally... >>> >>> Sorry for the noise. >>> >>> Heyi >>> >>> On 2021/6/11 上午9:14, Heyi Guo 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 > As I understand it, if you just want to bypass dbus and read pwm/tach > directly you can refer to this. > https://github.com/openbmc/openbmc/blob/master/meta-quanta/meta-gsj/recipes-phosphor/fans/phosphor-pid-control/config-2ssd.json#L6-L7 Do you suggest to use sysfs interface to access pwm/tach? However, we are using a I2C centralized fan controller and we don't have corresponding kernel driver for it. We propose to access this device by using /dev/i2c-<bus> interface directly in user mode. > >>>> 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. >>>> >>>> Does it make sense to do that? Or is there any reason for the current >>>> design? > I don't know why it's designed this way, but are you experiencing any problems? Not really. > According to our past experience, pid-control reads/writes pwm/tach > quite smoothly, > but pid-control has some trouble reading the temperature of some > sensors via dbus.(eg psusensors). > That's another topic... As I mentioned above, there is no sysfs interface for fan pwm/tach on our platform. We can only rely on dbus interfaces if using the upstream phosphor-pid-control. Then we think about centralizing all fan related hardware access into one module (like pid-control), but not sure if there's any problem for this idea. Thanks, Heyi > >>>> I'm new to OpenBMC and some of my understanding may be totally wrong. >>>> >>>> Looking forward to your expert advice. >>>> >>>> Thanks, >>>> >>>> Heyi
next prev parent reply other threads:[~2021-06-16 11:04 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-11 1:14 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 [this message] 2021-06-16 16:26 ` Ed Tanous 2021-06-20 8:48 ` Heyi Guo
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [Phishing Risk] [External] Re: Does it make sense to create a centralized fan control module?' \ /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
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.