From: Andrew Jeffery <andrew@aj.id.au>
To: Patrick Venture <venture@google.com>,
Brad Bishop <bradleyb@fuzziesquirrel.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: GPIO Centralized Control Daemon
Date: Mon, 18 Sep 2017 17:02:34 +0930 [thread overview]
Message-ID: <1505719954.4080.20.camel@aj.id.au> (raw)
In-Reply-To: <CAO=notwfcPJiEjtQ_n1jxFQpwtPwtvPisOZpiV64DbVHrk0qfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]
On Sun, 2017-09-17 at 14:49 -0700, Patrick Venture wrote:
> > > Those are particulars of a board that now get factored into the
> > > value. I'm not suggesting something beyond the norms of hwmon. It
> > > would be convenient however, if the ADC driver could be programmed to
> > > know that some sensor is gated by a GPIO and handled flipping,
> >
> > Can you reach out to Guenter or the relevant maintainer (is this an IIO
> > device?) for ideas here? I hadn't mentioned it but in the back of my
> > head this whole time I've been wondering about a completely in-kernel
> > solution.
>
> I'll reach out and see if this should go into the adc driver or the
> iio-hwmon. Since those are the paths that are involved. The sensor
> itself it plugged into the aspeed adc, and then controlled by a
> gpio. My initial thought is the adc should be configured to know if
> such things are required for its sensors, so that iio-hwmon wouldn't
> need to know.
My gut feeling is the other way around. There should be some higher-
level driver (i.e. still in the kernel, not in userspace) coordinating
the GPIO and the ADC such that we sample values at the appropriate time
after the GPIO has been set. The ADC driver should be well defined in
terms of the function the ADC hardware provides - gluing in random
GPIOs makes the ADC driver do things the ADC hardware itself does not
do.
I'm not across how the iio-hwmon bridge works so I don't know how
trivial it would be to re-export the sampled ADC values from this
higher-level driver as another IIO channel, but that's probably the
approach I would look at to glue it into hwmon.
That's all just off-the-cuff opinion though, so take it with a grain of
salt. Certainly talking to the IIO and hwmon maintainers is the right
approach.
Cheers,
Andrew
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2017-09-18 7:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 22:02 GPIO Centralized Control Daemon Patrick Venture
2017-09-14 22:29 ` Rick Altherr
2017-09-14 22:55 ` Patrick Venture
2017-09-16 22:12 ` Brad Bishop
2017-09-17 4:22 ` Patrick Venture
2017-09-17 16:26 ` Brad Bishop
2017-09-17 16:39 ` Patrick Venture
2017-09-17 17:33 ` Brad Bishop
2017-09-17 21:04 ` Patrick Venture
2017-09-17 21:38 ` Brad Bishop
2017-09-17 21:49 ` Patrick Venture
2017-09-17 22:10 ` Brad Bishop
2017-09-18 7:32 ` Andrew Jeffery [this message]
2017-09-18 14:52 ` Patrick Venture
2017-09-18 7:07 ` Andrew Jeffery
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=1505719954.4080.20.camel@aj.id.au \
--to=andrew@aj.id.au \
--cc=bradleyb@fuzziesquirrel.com \
--cc=openbmc@lists.ozlabs.org \
--cc=venture@google.com \
/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.