public inbox for linux-iio@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: linux-iio@vger.kernel.org, jic23@kernel.org,
	linux-hwmon@vger.kernel.org, linux@roeck-us.net,
	jdelvare@suse.com, kernel@pengutronix.de, linux-imx@nxp.com
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	letux-kernel@goldelico.com
Subject: [Q] tps65185 EPD PMIC temperature interface - which subsystem
Date: Fri, 30 Apr 2021 23:24:04 +0200	[thread overview]
Message-ID: <20210430232404.26d60fef@aktux> (raw)

Hi,

I am going about to clean up stuff to further upstream support for my
ebook readers. One question arises about the temperature interface of
the EPD PMIC. Vendor code uses regulator_get_voltage in the EPDC
driver to read a temperature in celsius and provides temperature through
the regulator interface (besides sysfs/hwmon). That is ugly. But what
are the options, if a kernel consumer should be able to reference it via
devicetree phandle and read out from it? I see temperature sensors
both in the iio and the hwmon subsystem, but do not find a description
why these things are there. If I put it into the iio-subsystem
iio_channel_get() and friends can be used, if I understand things
correctly, there are no such functions in the hwmon subsystem, so I
would not be able to use it there. So the better choice is to put it
into the iio subsystem?

On the consumer side, the temperature, which is pratically the ambient
temperature, is used to choose the right waveform for the corresponding
temperature range. Here are some code snippets in the vendor kernel:

temperature = regulator_get_voltage(fb_data->tmst_regulator);
dev_dbg(fb_data->dev, "auto temperature reading = %d\n", temperature);

if (temperature != 0xFF) {
	fb_data->last_time_temp_auto_update = now;
	fb_data->temp_index = mxc_epdc_fb_get_temp_index(fb_data, temperature);
}

static int mxc_epdc_fb_get_temp_index(struct mxc_epdc_fb_data *fb_data, int temp
)
{
        int i;
        int index = -1;

        if (fb_data->trt_entries == 0) {
                dev_err(fb_data->dev,
                        "No TRT exists...using default temp index\n");
                return DEFAULT_TEMP_INDEX;
        }

        /* Search temperature ranges for a match */
        for (i = 0; i < fb_data->trt_entries - 1; i++) {
                if ((temp >= fb_data->temp_range_bounds[i])
                        && (temp < fb_data->temp_range_bounds[i+1])) {
                        index = i;
                        break;
                }
        }

... and writing that index to some register in the EPDC.

As the consumer is not upstream (I have a basic drm-based variant also
in my clean-up queue), compatibilty to existing systems does not matter
that much. Also I see no drivers for similar chips upstream.

Regards,
Andreas

             reply	other threads:[~2021-04-30 21:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 21:24 Andreas Kemnade [this message]
2021-05-01  3:02 ` [Q] tps65185 EPD PMIC temperature interface - which subsystem Guenter Roeck
2021-05-01  8:21   ` Andreas Kemnade
2021-05-01 19:05     ` Guenter Roeck
2021-05-02 18:56       ` Andreas Kemnade

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=20210430232404.26d60fef@aktux \
    --to=andreas@kemnade.info \
    --cc=j.neuschaefer@gmx.net \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=letux-kernel@goldelico.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux@roeck-us.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox