Message ID | 20230524082744.3215427-1-bigunclemax@gmail.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2688481vqo; Wed, 24 May 2023 01:39:15 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6F3n2f7Bl2cRhgsCy1F05MvR7UB+FcOv2AO4kYFxIg2pxZRxM/9xMo4Dp9qXHfmO4DUFj4 X-Received: by 2002:a05:6a00:178f:b0:645:ac97:5295 with SMTP id s15-20020a056a00178f00b00645ac975295mr2409513pfg.9.1684917555429; Wed, 24 May 2023 01:39:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684917555; cv=none; d=google.com; s=arc-20160816; b=HEtLPDLsBbZim8JA6h6byt2IoS6iskivaUT0F2Vf19HWAeb3M3yp3gY9wyH+Owf7/4 1YroAa2W6TtJi0yvw3byn18TPnC5LeRAM7Y5rdnVB+PaokiQP49zTL69j5a9Mw2rMvN4 2B5NIP4GQP8KXo/vuJxDPJW+8Udu3moo9aZlhjfm23ZuzuyZtHrdAx/VwdfEhnnesWk+ Rfas3Y/DqtMEvjL3gfxtRoqRXVk2qFDHd+Q+eqzWlBg3YIKmEeVCAlatDRhZnBzlhvrB Gf9mpfvtLqlCVE7PIoUOohnfgF4kF5Z0sDeDL5nd+FQwOfzSkfLiAb+edEQiZLKtI+yA Ab4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=yqn5qRBwLcinfNxv6VW9L+IL+2b4SfMx1zWHSgO399s=; b=XNI8yllLDOuPcSAaek/wS4GhRr2VfpyQgxrjaDXo9VM8FA15UjYI05zfueqJnXE3A2 v43Xa/3NW0/geKdFl3u8L0iJWawNN8L1rnHElfV1GR/eRnwjdlFpgU6ZIPyx1sqLMK0/ iY50BZz4igZ/Z9rL+VUKDRHpPlVncAnTJmKlBL7Vp7duQBVAGPa7KQs+kAcaDMSnIr07 HIpe3MgaV7reWB0v0ONAX8kMwo83JnKxuB2hL34x9YR6VIEpoONnkQxDc/bW3bmjBBsR Y2/1Xf/JUhsC9hZ4jdm3N5AeN5hrPhYTqj9al4tHE9E4G7C1D5jmfM9kDHx38WgvLGKV b0Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=k37Hh7n1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y68-20020a626447000000b0064f4eb8dd2dsi1600085pfb.204.2023.05.24.01.39.00; Wed, 24 May 2023 01:39:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=k37Hh7n1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240112AbjEXI2B (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Wed, 24 May 2023 04:28:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234973AbjEXI17 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 24 May 2023 04:27:59 -0400 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37FDA12B; Wed, 24 May 2023 01:27:58 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4f3a873476bso538719e87.1; Wed, 24 May 2023 01:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684916876; x=1687508876; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yqn5qRBwLcinfNxv6VW9L+IL+2b4SfMx1zWHSgO399s=; b=k37Hh7n14UGVGV4NE3zQCYH3l1evQJSVPVb/+G9Fq3cASkwC273FAbYkuSHoClOScS yA70k8n8prh1aJmXgtbPAM6tF5BCuA2Y08lsRsHprvLhRH/1coP0RHOdcNoJFQ6XHFCB hrgsGRMXtTVQ2JLzKF1XZr7d4E9DL80Lz+afMRbfEv0wvO7NxfPAMu5iSn/3irBjhGbj eydEcIzBH1K33G9q2oya4vzq2Q597lx/luBgn80hMPlge5F5MvFydT7TjoCorzMzqiaf hWIAysdO/FZy4YQCtGIknBlv8ZvAS8nU+UsUdHXMK81dBH6vhDq3xM0Zr14l367gLMu6 Z0DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684916876; x=1687508876; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yqn5qRBwLcinfNxv6VW9L+IL+2b4SfMx1zWHSgO399s=; b=V18+d39STzr4yvIe6XxsQeidJSf57h4wku4YqnLTJZs3gIP7NwkD+m7w1p54xAQQ7b 1Mxb2jGIl2dO/fz45fWgxuhhhG9PpRpnRtbqNPOhwfgc7HF/NOfwKoXvqN5Npdl7JRKJ zWnXYuNKf+UQWPJBhVAWMdTzCxihggvVUByTD8T7Gzj6EeAT+ezHyo5OQwVivwbb3Bxx yoUDQN36Ura1Bq4roIthI6EcHxj48r69gSrTU77YVjhhFWcXsWv1yEKoJkgKnfpi6A4w 55tZcNI3sCL3D8XPjmbLwhzbowMPi69fpqhxayhmYPy+OuSlZVjkd8cdOJy96UwywX7d pF/A== X-Gm-Message-State: AC+VfDxVD9mBPhez91m9xk3QiW4giQNgW22bk9NmRUQl8DFeBrNtM8p9 ESvf7p9jeZ7fhPdEAnwn8qCkTgda21s7BSdy X-Received: by 2002:ac2:434a:0:b0:4f3:a483:557 with SMTP id o10-20020ac2434a000000b004f3a4830557mr4741266lfl.5.1684916875768; Wed, 24 May 2023 01:27:55 -0700 (PDT) Received: from pc.. (mail.pulsar-telecom.ru. [94.181.180.60]) by smtp.googlemail.com with ESMTPSA id c18-20020a197612000000b004f378fbb358sm1614049lff.112.2023.05.24.01.27.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 01:27:55 -0700 (PDT) From: Maxim Kiselev <bigunclemax@gmail.com> To: linux-iio@vger.kernel.org Cc: Maxim Kiselev <bigunclemax@gmail.com>, Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, Conor Dooley <conor@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Philipp Zabel <p.zabel@pengutronix.de>, Heiko Stuebner <heiko.stuebner@vrull.eu>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Cosmin Tanislav <demonsingur@gmail.com>, Mike Looijmans <mike.looijmans@topic.nl>, Haibo Chen <haibo.chen@nxp.com>, ChiYuan Huang <cy_huang@richtek.com>, Ramona Bolboaca <ramona.bolboaca@analog.com>, Ibrahim Tilki <Ibrahim.Tilki@analog.com>, Caleb Connolly <caleb.connolly@linaro.org>, William Breathitt Gray <william.gray@linaro.org>, Arnd Bergmann <arnd@arndb.de>, =?utf-8?q?Leonard_G=C3=B6hrs?= <l.goehrs@pengutronix.de>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Hugo Villeneuve <hvilleneuve@dimonoff.com>, ChiaEn Wu <chiaen_wu@richtek.com>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: [RFC PATCH v1 0/4] Add support for Allwinner GPADC on D1/T113s/R329 SoCs Date: Wed, 24 May 2023 11:27:29 +0300 Message-Id: <20230524082744.3215427-1-bigunclemax@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766764110418699463?= X-GMAIL-MSGID: =?utf-8?q?1766764110418699463?= |
Series |
Add support for Allwinner GPADC on D1/T113s/R329 SoCs
|
|
Message
Maxim Kiselev
May 24, 2023, 8:27 a.m. UTC
Hi, This series adds support for general purpose ADC (GPADC) on new Allwinner's SoCs, such as D1, T113s and R329. The implemented driver provides basic functionality for getting ADC channels data. All of the listed SoCs have the same IP. The only difference is the number of available channels: T113 - 1 channel D1 - 2 channels R329 - 4 channels This series is just an RFC and I would be glad to see any comments about it. Maxim Kiselev (4): iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC dt-bindings: iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC ARM: dts: sun8i: t113s: Add GPADC node riscv: dts: allwinner: d1: Add GPADC node .../iio/adc/allwinner,sun20i-d1-gpadc.yaml | 52 ++++ arch/arm/boot/dts/sun8i-t113s.dtsi | 12 + arch/riscv/boot/dts/allwinner/sun20i-d1.dtsi | 10 + drivers/iio/adc/Kconfig | 10 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/sun20i-gpadc-iio.c | 275 ++++++++++++++++++ 6 files changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml create mode 100644 drivers/iio/adc/sun20i-gpadc-iio.c
Comments
On Wed, 24 May 2023 11:27:29 +0300 Maxim Kiselev <bigunclemax@gmail.com> wrote: Hi Maxim, many thanks for your work on this and for posting it! > This series adds support for general purpose ADC (GPADC) on new > Allwinner's SoCs, such as D1, T113s and R329. The implemented driver > provides basic functionality for getting ADC channels data. > > All of the listed SoCs have the same IP. The only difference is the number > of available channels: > T113 - 1 channel > D1 - 2 channels > R329 - 4 channels This may sound kind of obvious, but wouldn't it be easier to model this with one compatible string, and have the number of channels as a DT property? Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's only one ADC anyway? And btw: it seems that the T507 (the H616 die with a different pinout) has the same IP, with four channels: http://dl.linux-sunxi.org/T507/ Cheers, Andre > This series is just an RFC and I would be glad to see any comments > about it. > > > Maxim Kiselev (4): > iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC > dt-bindings: iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC > ARM: dts: sun8i: t113s: Add GPADC node > riscv: dts: allwinner: d1: Add GPADC node > > .../iio/adc/allwinner,sun20i-d1-gpadc.yaml | 52 ++++ > arch/arm/boot/dts/sun8i-t113s.dtsi | 12 + > arch/riscv/boot/dts/allwinner/sun20i-d1.dtsi | 10 + > drivers/iio/adc/Kconfig | 10 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/sun20i-gpadc-iio.c | 275 ++++++++++++++++++ > 6 files changed, 360 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml > create mode 100644 drivers/iio/adc/sun20i-gpadc-iio.c >
Hi Andre, thanks for you comments > This may sound kind of obvious, but wouldn't it be easier to model this > with one compatible string, and have the number of channels as a DT > property? Yes, I completely agree that using separate config for each SoCs is looks overcomplicated because the only difference is the number of channels. I thought about a DT property with channels number but I didn't find another ADC driver with the same approach (except i2c ADC's with child nodes). > Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's > only one ADC anyway? I'm sorry, I didn't quite understand what you're suggesting. > And btw: it seems that the T507 (the H616 die with a different pinout) has > the same IP, with four channels: > http://dl.linux-sunxi.org/T507/ Oh, thanks for pointing that. I'll add it to the list in the next version.
On Wed, 24 May 2023 14:36:28 +0300 Maxim Kiselev <bigunclemax@gmail.com> wrote: > Hi Andre, > > thanks for you comments > > > This may sound kind of obvious, but wouldn't it be easier to model this > > with one compatible string, and have the number of channels as a DT > > property? > > Yes, I completely agree that using separate config for each SoCs is looks > overcomplicated because the only difference is the number of channels. > I thought about a DT property with channels number but I didn't find > another ADC driver with the same approach (except i2c ADC's with child nodes). If you are 100% sure that that devices are either 1) Detectable at runtime 2) Identical in functionality. So that in neither case will any changes on driver support expose differences in the future then a single compatible is fine. The back up is that you use fallback compatibles - list more than one. Whilst it doesn't matter (as no differences found) the driver can use the first one. If differences become apparent later, others may be used. I'm not however keen on a simple channel count parameter. If you want to go that way, it's better to provide the fine control of individual channel child nodes (see Documentation/devicetree/bindings/iio/adc/adc.yaml) That way the control is on which channels are wired to something useful, rather than whether the device can read them or not (which is pointless if no one wired them up. > > > Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's > > only one ADC anyway? > I'm sorry, I didn't quite understand what you're suggesting. That's normally only used for a separate MUX where we need a separate driver to handle it. If used on a device like this it would expose additional complexity to userspace with no benefits in generality etc. > > > And btw: it seems that the T507 (the H616 die with a different pinout) has > > the same IP, with four channels: > > http://dl.linux-sunxi.org/T507/ > > Oh, thanks for pointing that. I'll add it to the list in the next version.
On Sun, 28 May 2023 16:22:57 +0100 Jonathan Cameron <jic23@kernel.org> wrote: > On Wed, 24 May 2023 14:36:28 +0300 > Maxim Kiselev <bigunclemax@gmail.com> wrote: > > > Hi Andre, > > > > thanks for you comments > > > > > This may sound kind of obvious, but wouldn't it be easier to model this > > > with one compatible string, and have the number of channels as a DT > > > property? > > > > Yes, I completely agree that using separate config for each SoCs is looks > > overcomplicated because the only difference is the number of channels. > > I thought about a DT property with channels number but I didn't find > > another ADC driver with the same approach (except i2c ADC's with child nodes). > If you are 100% sure that that devices are either > 1) Detectable at runtime > 2) Identical in functionality. > > So that in neither case will any changes on driver support expose differences > in the future then a single compatible is fine. > > The back up is that you use fallback compatibles - list more than one. > Whilst it doesn't matter (as no differences found) the driver can use > the first one. If differences become apparent later, others may be used. > > I'm not however keen on a simple channel count parameter. If you want > to go that way, it's better to provide the fine control of individual channel > child nodes (see Documentation/devicetree/bindings/iio/adc/adc.yaml) > > That way the control is on which channels are wired to something useful, rather > than whether the device can read them or not (which is pointless if no one > wired them up. Another thing to note is that with generic compatibles you loose the ability to have the dt-schmema validate that sets of parameters make sense. If it's just the channels available that may not matter however. > > > > > > > Or, alternatively, using iio/multiplexer/io-channel-mux.yaml, since it's > > > only one ADC anyway? > > I'm sorry, I didn't quite understand what you're suggesting. > > That's normally only used for a separate MUX where we need a separate driver > to handle it. If used on a device like this it would expose additional complexity > to userspace with no benefits in generality etc. > > > > > > And btw: it seems that the T507 (the H616 die with a different pinout) has > > > the same IP, with four channels: > > > http://dl.linux-sunxi.org/T507/ > > > > Oh, thanks for pointing that. I'll add it to the list in the next version. >
On Wed, 24 May 2023 11:27:29 +0300 Maxim Kiselev <bigunclemax@gmail.com> wrote: > Hi, > > This series adds support for general purpose ADC (GPADC) on new > Allwinner's SoCs, such as D1, T113s and R329. The implemented driver > provides basic functionality for getting ADC channels data. > > All of the listed SoCs have the same IP. The only difference is the number > of available channels: > T113 - 1 channel > D1 - 2 channels > R329 - 4 channels > > This series is just an RFC and I would be glad to see any comments > about it. Why 'just an RFC'? Normal to call out aspects that mean it doesn't yet make sense for it to be picked up for upstream. Looks pretty good to me in general rather than RFC material so perhaps I'm missing something. Jonathan > > > Maxim Kiselev (4): > iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC > dt-bindings: iio: adc: Add Allwinner D1/T113s/R329 SoCs GPADC > ARM: dts: sun8i: t113s: Add GPADC node > riscv: dts: allwinner: d1: Add GPADC node > > .../iio/adc/allwinner,sun20i-d1-gpadc.yaml | 52 ++++ > arch/arm/boot/dts/sun8i-t113s.dtsi | 12 + > arch/riscv/boot/dts/allwinner/sun20i-d1.dtsi | 10 + > drivers/iio/adc/Kconfig | 10 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/sun20i-gpadc-iio.c | 275 ++++++++++++++++++ > 6 files changed, 360 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/adc/allwinner,sun20i-d1-gpadc.yaml > create mode 100644 drivers/iio/adc/sun20i-gpadc-iio.c >