Received: by 10.223.176.5 with SMTP id f5csp823192wra; Fri, 2 Feb 2018 06:43:57 -0800 (PST) X-Google-Smtp-Source: AH8x226Wu1TeWgdiuP267sz87uQBsQlw+Pf1XUh0bEDVeLM9s7Wm16jVEGE7CoUrfDHFIL85Gp1B X-Received: by 10.98.69.209 with SMTP id n78mr40787718pfi.6.1517582636966; Fri, 02 Feb 2018 06:43:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517582636; cv=none; d=google.com; s=arc-20160816; b=zzBRqBFo59VlWfvz5CkqCDjxiBqUgRCxjF/Y+zYc+EiPHMLn3x/KXjQrCtyLVdi6RC kuiP868uwROXdTXLdKaVSXzI+RY0tAbl//Aq3gokGn+dvtgNmSqfl+wtiIvb43Ta2yf4 tQS+0cJVUG010WaI2/bssWtdCBVdQhfxrUTbUhtSSW8+ZVTmvcz8R6j3v7ZJfGIVQ6YI +D1EEqUl8UKa0SdP0sSh+HaDRJDLgoAr6bFLSFeMxTjsOycFieiJutlwNy+gGzZfBCZ+ 5d0qKFDeYfXS2LPO8fVTWYwDW+3fP+wxga2MUSMy16k/41bdchGn8ed1rFH7+jytoH01 0W8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=dyeUPpmz2kZ/oT5EpVPGKR1EzAKHdsDcRzjoEHeoQtc=; b=kd2+JUU0jG91na6yS59m6uxyMvsGjhoN5LfEqWXBxll332ixqcvqa3WisYqKuIAii9 Sc0+pQeIev6NXao6bL5EzLH9ynuH0ef+NQDpnRj6htREZReUe+Ltr/f1DhAWRSUE8Rye YoScQXGfqRWFvWlh+vTZ1JqAQG3VlQ25iUC5meMQt4a7F8uulEgAXF4FpFq9XLRV+SOl jDfocFQ+XIFzpJ4+Y2CB/F9WNYvU+Vrnm7lMcxzzxYUdH3qHwzbEPUJbNMqCxW4vkUya z2k/eoOguy3Fbb6Sp+s+d6/kVgkW7dsq4xe8d0wSJqDFokvrAytGJRyxm+X0Q9gPHGZk w9QQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QmZuCnGh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u19si1873411pfh.154.2018.02.02.06.43.42; Fri, 02 Feb 2018 06:43:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QmZuCnGh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbeBBOml (ORCPT + 99 others); Fri, 2 Feb 2018 09:42:41 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:50495 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751629AbeBBOmf (ORCPT ); Fri, 2 Feb 2018 09:42:35 -0500 Received: by mail-wm0-f66.google.com with SMTP id f71so13114469wmf.0; Fri, 02 Feb 2018 06:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dyeUPpmz2kZ/oT5EpVPGKR1EzAKHdsDcRzjoEHeoQtc=; b=QmZuCnGh56ddR7chJzOeORFgF3FGlyvHzNWWY0Rv4n96HusBPHIiHK9vln5m4Kf4aB BdiK01yjEDomWfJlGq8Rq16u/Fs7hTaZH4rm+gwkXiT2R3xt59uJU3F0Pedr4yOrULgO 8qUjP/hoA2KaM3kjmismEWeHJ1a+qfYyv35JhzbgwNpH6sNNIQ97IopJ8V5+ZJrf7rpM hII96NC0r5Ii1KX+OxlqcQm90k4w/EAwW/P5XRUdNg+moRxcU0le+uG7KzEKHaGlHKHr 4wtJvDdvI58QJ5CgKO9hRDUhQlLTtd3ZnPh5KHL0xYkrmcLQCmSMwGa0EImL33whJbfm xJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dyeUPpmz2kZ/oT5EpVPGKR1EzAKHdsDcRzjoEHeoQtc=; b=G5cnAuDJxBpom8JVvErO/hkau89NfODvu3xRUJW6btMikDINpsznLEA+rF/FluKbXK Nvujci9j0Luohu2UhP8ySQglCSvV+TTDPtZSFPQSn+1MPTSiY/Px5zhwVwRrGLmIj5UG CAzVDMK3br+0PumgBwDmhANBXx1nS48AIs+/QoFvAvswbkFgxlNYYCR1NCctt6mMwkQw 1fGn9qOAzoynf3Zrlwjvd24nBhT59vkwZF27sL7MOBl8k+EXPR4F2C0sFx2TkatYkN4U u+vsPvmfi49A82PcwdkbFXkyaGpctqdM7PGZJeMo+0Obj91xb0VZWc/WutcvzV1Quqr8 KYuQ== X-Gm-Message-State: AKwxytePLKMDRpg1rHdJYfu1D6aMxJIDSbx9E/3+b8lO/z9Ds2hsKghk pWmr2E1QUKoBayKcy5YyT7s= X-Received: by 10.80.174.245 with SMTP id f50mr65728058edd.28.1517582553427; Fri, 02 Feb 2018 06:42:33 -0800 (PST) Received: from [134.60.183.180] (eduroam183-180.wlan.uni-ulm.de. [134.60.183.180]) by smtp.gmail.com with ESMTPSA id d21sm2186346edb.13.2018.02.02.06.42.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 06:42:32 -0800 (PST) Subject: Re: [PATCH v2 09/16] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor To: Quentin Schulz Cc: lee.jones@linaro.org, robh+dt@kernel.org, mark.rutland@arm.com, maxime.ripard@free-electrons.com, wens@csie.org, linux@armlinux.org.uk, jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, davem@davemloft.net, hans.verkuil@cisco.com, mchehab@kernel.org, rask@formelder.dk, clabbe.montjoie@gmail.com, sean@mess.org, krzk@kernel.org, icenowy@aosc.io, edu.molinas@gmail.com, singhalsimran0@gmail.com, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com References: <20180128232919.12639-1-embed3d@gmail.com> <20180128232919.12639-10-embed3d@gmail.com> <20180131192354.sb7zmcwc6c3eisqj@qschulz> From: Philipp Rossak Message-ID: Date: Fri, 2 Feb 2018 15:42:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180131192354.sb7zmcwc6c3eisqj@qschulz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31.01.2018 20:23, Quentin Schulz wrote: > Hi Philipp, > > On Mon, Jan 29, 2018 at 12:29:12AM +0100, Philipp Rossak wrote: >> This patch adds support for the H3 ths sensor. >> >> The H3 supports interrupts. The interrupt is configured to update the >> the sensor values every second. The calibration data is writen at the >> begin of the init process. >> >> Signed-off-by: Philipp Rossak >> --- >> drivers/iio/adc/sun4i-gpadc-iio.c | 86 +++++++++++++++++++++++++++++++++++++++ >> include/linux/mfd/sun4i-gpadc.h | 22 ++++++++++ >> 2 files changed, 108 insertions(+) >> >> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c >> index b7b5451226b0..8196203d65fe 100644 >> --- a/drivers/iio/adc/sun4i-gpadc-iio.c >> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c >> @@ -61,6 +61,9 @@ struct sun4i_gpadc_iio; >> static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info); >> static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info); >> >> +static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info); >> +static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info); >> + > > We try to avoid using the generic sunxi prefix. > >> struct gpadc_data { >> int temp_offset; >> int temp_scale; >> @@ -71,6 +74,10 @@ struct gpadc_data { >> unsigned int temp_data[MAX_SENSOR_COUNT]; >> int (*sample_start)(struct sun4i_gpadc_iio *info); >> int (*sample_end)(struct sun4i_gpadc_iio *info); >> + u32 ctrl0_map; >> + u32 ctrl2_map; >> + u32 sensor_en_map; >> + u32 filter_map; >> u32 irq_clear_map; >> u32 irq_control_map; >> bool has_bus_clk; >> @@ -138,6 +145,31 @@ static const struct gpadc_data sun8i_a33_gpadc_data = { >> .support_irq = false, >> }; >> >> +static const struct gpadc_data sun8i_h3_ths_data = { >> + .temp_offset = -1791, >> + .temp_scale = -121, >> + .temp_data = {SUN8I_H3_THS_TDATA0, 0, 0, 0}, >> + .sample_start = sunxi_ths_sample_start, >> + .sample_end = sunxi_ths_sample_end, >> + .has_bus_clk = true, >> + .has_bus_rst = true, >> + .has_mod_clk = true, >> + .sensor_count = 1, >> + .supports_nvmem = true, >> + .support_irq = true, >> + .ctrl0_map = SUN4I_GPADC_CTRL0_T_ACQ(0xff), >> + .ctrl2_map = SUN8I_H3_THS_ACQ1(0x3f), >> + .sensor_en_map = SUN8I_H3_THS_TEMP_SENSE_EN0, >> + .filter_map = SUN4I_GPADC_CTRL3_FILTER_EN | >> + SUN4I_GPADC_CTRL3_FILTER_TYPE(0x2), >> + .irq_clear_map = SUN8I_H3_THS_INTS_ALARM_INT_0 | >> + SUN8I_H3_THS_INTS_SHUT_INT_0 | >> + SUN8I_H3_THS_INTS_TDATA_IRQ_0 | >> + SUN8I_H3_THS_INTS_ALARM_OFF_0, >> + .irq_control_map = SUN8I_H3_THS_INTC_TDATA_IRQ_EN0 | >> + SUN8I_H3_THS_TEMP_PERIOD(0x7), > > From what I've understood, ACQ regs are basically clock dividers. We > should make a better job at explaining it :) > I agree, I will add this in the next version in the commit message. >> +}; >> + >> struct sun4i_gpadc_iio { >> struct iio_dev *indio_dev; >> struct completion completion; >> @@ -462,6 +494,16 @@ static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info) >> return 0; >> } >> >> +static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info) >> +{ >> + /* Disable ths interrupt */ >> + regmap_write(info->regmap, SUN8I_H3_THS_INTC, 0x0); >> + /* Disable temperature sensor */ >> + regmap_write(info->regmap, SUN8I_H3_THS_CTRL2, 0x0); >> + >> + return 0; >> +} >> + >> static int sun4i_gpadc_runtime_suspend(struct device *dev) >> { >> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev)); >> @@ -473,6 +515,17 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev) >> return info->data->sample_end(info); >> } >> >> +static void sunxi_calibrate(struct sun4i_gpadc_iio *info) >> +{ >> + if (info->has_calibration_data[0]) >> + regmap_write(info->regmap, SUNXI_THS_CDATA_0_1, >> + info->calibration_data[0]); >> + >> + if (info->has_calibration_data[1]) >> + regmap_write(info->regmap, SUNXI_THS_CDATA_2_3, >> + info->calibration_data[1]); >> +} >> + >> static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info) >> { >> /* clkin = 6MHz */ >> @@ -492,6 +545,35 @@ static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info) >> return 0; >> } >> >> +static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info) >> +{ >> + u32 value; >> + sunxi_calibrate(info); >> + >> + if (info->data->ctrl0_map) >> + regmap_write(info->regmap, SUN8I_H3_THS_CTRL0, >> + info->data->ctrl0_map); >> + >> + regmap_write(info->regmap, SUN8I_H3_THS_CTRL2, >> + info->data->ctrl2_map); >> + >> + regmap_write(info->regmap, SUN8I_H3_THS_STAT, >> + info->data->irq_clear_map); >> + >> + regmap_write(info->regmap, SUN8I_H3_THS_FILTER, >> + info->data->filter_map); >> + >> + regmap_write(info->regmap, SUN8I_H3_THS_INTC, >> + info->data->irq_control_map); >> + >> + regmap_read(info->regmap, SUN8I_H3_THS_CTRL2, &value); >> + >> + regmap_write(info->regmap, SUN8I_H3_THS_CTRL2, >> + info->data->sensor_en_map | value); >> + >> + return 0; >> +} >> + > > I'm a bit worried. Will all the sensors have the same sample start? Or > will we need at some point also entries in info->data for register > addresses, if they have ctrl2 or filter, etc... > > Maybe we could define a sample_start for the h3 only and reuse-it if > possible and if not declare another sample start? All depends if the > sample start is most likely to change in the near future or not. If it > is, then we should avoid adding a lot of variables in info->data and > just go for a single sample_start per SoC. > for H3, A83T, H5, A64 we can use the same sample start. So I would use here a H3 sample start function and reuse it. A80 is special since it has no crtl0 register, thus it would get also its own function. H6 will need also an own sample start function (looking in the near future). >> static int sun4i_gpadc_runtime_resume(struct device *dev) >> { >> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev)); >> @@ -582,6 +664,10 @@ static const struct of_device_id sun4i_gpadc_of_id[] = { >> .compatible = "allwinner,sun8i-a33-ths", >> .data = &sun8i_a33_gpadc_data, >> }, >> + { >> + .compatible = "allwinner,sun8i-h3-ths", >> + .data = &sun8i_h3_ths_data, >> + }, >> { /* sentinel */ } >> }; >> >> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h >> index 458f2159a95a..80b79c31cea3 100644 >> --- a/include/linux/mfd/sun4i-gpadc.h >> +++ b/include/linux/mfd/sun4i-gpadc.h >> @@ -91,7 +91,29 @@ >> #define SUN4I_GPADC_AUTOSUSPEND_DELAY 10000 >> >> /* SUNXI_THS COMMON REGISTERS + DEFINES */ >> +#define SUN8I_H3_THS_CTRL0 0x00 >> +#define SUN8I_H3_THS_CTRL2 0x40 >> #define SUN8I_H3_THS_INTC 0x44 >> +#define SUN8I_H3_THS_STAT 0x48 >> +#define SUN8I_H3_THS_FILTER 0x70 >> +#define SUNXI_THS_CDATA_0_1 0x74 >> +#define SUNXI_THS_CDATA_2_3 0x78 >> +#define SUN8I_H3_THS_TDATA0 0x80 >> + >> +#define SUN8I_H3_THS_ACQ1(x) (GENMASK(31, 16) & ((x) << 16)) >> + >> +#define SUN8I_H3_THS_TEMP_SENSE_EN0 BIT(0) >> + >> +#define SUN8I_H3_THS_TEMP_PERIOD(x) (GENMASK(31, 12) & ((x) << 12)) >> + >> +#define SUN8I_H3_THS_INTS_ALARM_INT_0 BIT(0) >> +#define SUN8I_H3_THS_INTS_SHUT_INT_0 BIT(4) >> +#define SUN8I_H3_THS_INTS_TDATA_IRQ_0 BIT(8) >> +#define SUN8I_H3_THS_INTS_ALARM_OFF_0 BIT(12) >> + >> +#define SUN8I_H3_THS_INTC_ALARM_INT_EN0 BIT(0) >> +#define SUN8I_H3_THS_INTC_SHUT_INT_EN0 BIT(4) >> +#define SUN8I_H3_THS_INTC_TDATA_IRQ_EN0 BIT(8) >> > > Personal taste here but I prefer the register bits to be defined just > below the register address define. > > i.e.: > > #define SUN8I_H3_THS_CTRL2 0x40 > #define SUN8I_H3_THS_ACQ1(x) (GENMASK(31, 16) & ((x) << 16)) > #define SUN8I_H3_THS_TEMP_SENSE_EN0 BIT(0) > > that way we know for which register we should use which constants. > > Quentin > I agree, this the better way to do it. Thanks, Philipp