Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp65754imj; Wed, 13 Feb 2019 04:51:42 -0800 (PST) X-Google-Smtp-Source: AHgI3IZJwaUIxA9ARH272WJJHzyOY00t/DnDLythXu4kgzE4vTEUiree8j//hGBwTwSY7wBrtWZv X-Received: by 2002:a62:3c1:: with SMTP id 184mr392341pfd.56.1550062302232; Wed, 13 Feb 2019 04:51:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550062302; cv=none; d=google.com; s=arc-20160816; b=WhviljJLPARILanIYs4CeUn2xYAnLW5sQvBD6IXChREIc0q4kCm5O8eiQvNOiKJkVN Qm2mmIMnpPVy1u/hxVLFaF/v5aVE3y6KhUQ9e+TvoKOlm65/Vie0ZPfg2epHdYuXLWpq cfVIdOC1CMkhU81DM9PMdBMqXbHXeSXMTCfwHqC5G00VB55aLdoBbSAA4neHR0WIbBFY WEFaFmx8Y35TykLE6nWBoEX+ELhuE22Ros2zITTo93Q50+S81k6Z6FmKnU7rhzRc4p2k bV+k6uql2b+HsPHG/QcSVyuv5Xi6+O/c5SCfJZUpacnWPKskP88SOnVsbozUqFHuAxp+ c5Cw== 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; bh=bdurlxeqJ0bKi/cSvisd40pwu0knZ1FrIHy+CHywdxs=; b=XTnGnfB+Wdef/JS23nJ8vYuCqYliG74Z9WM4bA1NhYd60xGKQVX04PUwCCFwrA2OLx Iftpu702OgFFUyyToUjmJiXsJe6Ct6xPghXP4plDMwsYlluw4oLad2L/Lyx5pViL5hQD q/4vaUKdw6KFAGQKXcG5aR0+XLH84t9IvNm20kIsnqRIxRMjC+o/gphT6NLh7mDmDxOu 66bFhdjQrroAYjKCnBnukoYaHJGnuUymvXT6wRFc3WXKi0B8MG16yb8e1lHvKsV+OqKU AF4VZliAnHwS7Kwa8Zw5frMppwbxg1JdtWh37+amor74TM1e4zFFKem8n5wknxQ6hvch mqVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@lechnology.com header.s=default header.b=Ls4OrDmG; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i36si16590264plb.210.2019.02.13.04.51.26; Wed, 13 Feb 2019 04:51:42 -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=fail header.i=@lechnology.com header.s=default header.b=Ls4OrDmG; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390501AbfBMILD (ORCPT + 99 others); Wed, 13 Feb 2019 03:11:03 -0500 Received: from vern.gendns.com ([98.142.107.122]:60866 "EHLO vern.gendns.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730406AbfBMILC (ORCPT ); Wed, 13 Feb 2019 03:11:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lechnology.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bdurlxeqJ0bKi/cSvisd40pwu0knZ1FrIHy+CHywdxs=; b=Ls4OrDmGUsDruQm+zvoc8R7vA/ ThK8fF6Ib2z6Ja31X3Q15DF4EXGNnuyg7T+I/wI8KxdONUa+FSsEcwt1ZCFM+uE25kYYvNjSki9ny /f4gPRb58AQiFBsjO+jF5zBpD+cSVF3V97zF6cnglTKL/BOqH8S860QIhGv5nc9W/11V7xf1HHxve oUOunUFlf3wORpj5xHa/wKEwF+qrScm2TsK0W5GEK5TNiTMP9I372Wy1V4UNa0Zo2IStTz/yj0K03 Y2RK4odXx9/C2H5FG9P1Ec5HdV6TdMRa91EO0fjrWZFkMcFlRaukWOxGxW+3WzvbKAk9xBBQxkctw 3CGqLXwg==; Received: from 5f9a3e7e.rev.sefiber.dk ([95.154.62.126]:51601 helo=gerda-5.local) by vern.gendns.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gtpZN-0003TH-SQ; Wed, 13 Feb 2019 03:07:02 -0500 Subject: Re: [PATCH v3] iio: adc: ti-ads7950: add GPIO support To: justinpopo6@gmail.com, linux-iio@vger.kernel.org Cc: linux-gpio@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, f.fainelli@gmail.com, bgolaszewski@baylibre.com, linus.walleij@linaro.org, jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-kernel@vger.kernel.org References: <1550030242-5241-1-git-send-email-justinpopo6@gmail.com> From: David Lechner Message-ID: <9e0a8a08-9636-906b-08cf-d99947d6f51a@lechnology.com> Date: Wed, 13 Feb 2019 09:10:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <1550030242-5241-1-git-send-email-justinpopo6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/12/19 9:57 PM, justinpopo6@gmail.com wrote: > From: Justin Chen > > The ADS79XX has GPIO pins that can be used. Add support for the GPIO > pins using the GPIO chip framework. > > Signed-off-by: Justin Chen > --- It will be better to split this up into two patches[1]. One to replace all uses of indio_dev->mlock with the new local lock and then another to add GPIO support. How are you using/testing this patch? Do we need device tree bindings? It will also help reviewers if you add a note about what you changed in each revision of the patch when you resubmit. The usual way to do this is something like: v3 changes: - Fixed unlocking mutex too many times in ti_ads7950_init_gpio() It also is nice to wait a few days at least before submitting the next revision to give people some time to respond. [1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#split-changes > drivers/iio/adc/ti-ads7950.c | 169 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 166 insertions(+), 3 deletions(-) > > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c > index 0ad6359..9723d66 100644 > --- a/drivers/iio/adc/ti-ads7950.c > +++ b/drivers/iio/adc/ti-ads7950.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -36,10 +37,14 @@ > */ > #define TI_ADS7950_VA_MV_ACPI_DEFAULT 5000 > > +#define TI_ADS7950_CR_GPIO BIT(14) > #define TI_ADS7950_CR_MANUAL BIT(12) > #define TI_ADS7950_CR_WRITE BIT(11) > #define TI_ADS7950_CR_CHAN(ch) ((ch) << 7) > #define TI_ADS7950_CR_RANGE_5V BIT(6) > +#define TI_ADS7950_CR_GPIO_DATA BIT(5) > +#define TI_ADS7950_NUM_GPIOS 4 > +#define TI_ADS7950_GPIO_MASK GENMASK(TI_ADS7950_NUM_GPIOS - 1, 0) > > #define TI_ADS7950_MAX_CHAN 16 > > @@ -56,11 +61,17 @@ struct ti_ads7950_state { > struct spi_message ring_msg; > struct spi_message scan_single_msg; > > + struct gpio_chip chip; > + struct mutex slock; A comment stating what slock is protecting (i.e. the spi xfers and buffers) would be helpful. > + > struct regulator *reg; > unsigned int vref_mv; > > unsigned int settings; > > + unsigned int gpio_direction_bitmask; > + unsigned int gpio_signal_bitmask; > + > /* > * DMA (thus cache coherency maintenance) requires the > * transfer buffers to live in their own cache lines. > @@ -248,7 +259,8 @@ static int ti_ads7950_update_scan_mode(struct iio_dev *indio_dev, > > len = 0; > for_each_set_bit(i, active_scan_mask, indio_dev->num_channels) { > - cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(i) | st->settings; > + cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(i) | st->settings > + | (st->gpio_signal_bitmask & TI_ADS7950_GPIO_MASK); > st->tx_buf[len++] = cmd; > } > > @@ -287,8 +299,9 @@ static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch) > int ret, cmd; > > mutex_lock(&indio_dev->mlock); The use of mlock should be removed here since we are replacing it with slock. Also, ti_ads7950_trigger_handler() will need to be changed to use slock when the use of mlock is removed. (When ti_ads7950_trigger_handler() is called, mlock is already held by the calling function.) > - > - cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings; > + mutex_lock(&st->slock); > + cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings > + | (st->gpio_signal_bitmask & TI_ADS7950_GPIO_MASK); > st->single_tx = cmd; > > ret = spi_sync(st->spi, &st->scan_single_msg); > @@ -298,6 +311,7 @@ static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch) > ret = st->single_rx; > > out: > + mutex_unlock(&st->slock); > mutex_unlock(&indio_dev->mlock); > > return ret; > @@ -362,6 +376,145 @@ static const struct iio_info ti_ads7950_info = { > .update_scan_mode = ti_ads7950_update_scan_mode, > }; > > +static void ti_ads7950_set(struct gpio_chip *chip, unsigned int offset, > + int value) > +{ > + struct ti_ads7950_state *st = gpiochip_get_data(chip); > + > + mutex_lock(&st->slock); > + > + if (value) > + st->gpio_signal_bitmask |= BIT(offset); > + else > + st->gpio_signal_bitmask &= ~BIT(offset); > + > + st->single_tx = cpu_to_be16(TI_ADS7950_CR_MANUAL | TI_ADS7950_CR_WRITE | > + (st->gpio_signal_bitmask & TI_ADS7950_GPIO_MASK)); SPI xfers are CPU-endian, so cpu_to_be16() doesn't seem right here. > + spi_sync(st->spi, &st->scan_single_msg); > + > + mutex_unlock(&st->slock); > +} > + > +static int ti_ads7950_get(struct gpio_chip *chip, unsigned int offset) > +{ > + struct ti_ads7950_state *st = gpiochip_get_data(chip); > + int ret; > + > + mutex_lock(&st->slock); > + > + /* If set as output, return the output */ > + if (st->gpio_direction_bitmask & BIT(offset)) { > + ret = st->gpio_signal_bitmask & BIT(offset); > + goto out; > + } > + > + st->single_tx = cpu_to_be16(TI_ADS7950_CR_MANUAL | TI_ADS7950_CR_WRITE | > + TI_ADS7950_CR_GPIO_DATA); Again, cpu_to_be16() seems wrong. > + ret = spi_sync(st->spi, &st->scan_single_msg); > + if (ret) > + goto out; > + > + ret = ((st->single_rx >> 12) & BIT(offset)) ? 1 : 0; > + > +out: > + mutex_unlock(&st->slock); > + > + return ret; > +} > + > +static int ti_ads7950_get_direction(struct gpio_chip *chip, > + unsigned int offset) > +{ > + struct ti_ads7950_state *st = gpiochip_get_data(chip); > + > + return !(st->gpio_direction_bitmask & BIT(offset)); The use of `!` here seems odd. Why make gpio_direction_bitmask inverted compared to the gpio framework? > +} > + > +static int _ti_ads7950_set_direction(struct gpio_chip *chip, int offset, > + int input) > +{ > + struct ti_ads7950_state *st = gpiochip_get_data(chip); > + int ret = 0; > + > + mutex_lock(&st->slock); > + A comment explaining what is going on here (i.e. we only send an SPI message if the direction changes) would be helpful. It was not quite obvious to me at first glance. > + if (input && (st->gpio_direction_bitmask & BIT(offset))) > + st->gpio_direction_bitmask &= ~BIT(offset); > + else if (!input && !(st->gpio_direction_bitmask & BIT(offset))) > + st->gpio_direction_bitmask |= BIT(offset); > + else > + goto out; > + > + > + st->single_tx = cpu_to_be16(TI_ADS7950_CR_GPIO | > + (st->gpio_direction_bitmask & > + TI_ADS7950_GPIO_MASK)); > + ret = spi_sync(st->spi, &st->scan_single_msg); > + > +out: > + mutex_unlock(&st->slock); > + > + return ret; > +} > + > +static int ti_ads7950_direction_input(struct gpio_chip *chip, > + unsigned int offset) > +{ > + return _ti_ads7950_set_direction(chip, offset, 1); > +} > + > +static int ti_ads7950_direction_output(struct gpio_chip *chip, > + unsigned int offset, int value) > +{ > + ti_ads7950_set(chip, offset, value); > + > + return _ti_ads7950_set_direction(chip, offset, 0); > +} > + > +static int ti_ads7950_init_gpio(struct ti_ads7950_state *st) > +{ > + int ret; > + > + /* Initialize GPIO */ > + mutex_lock(&st->slock); > + > + /* Default to GPIO input */ > + st->gpio_direction_bitmask = 0x0; It is probably safe to leave this out since it should already be 0. > + st->single_tx = cpu_to_be16(TI_ADS7950_CR_GPIO | > + (st->gpio_direction_bitmask & > + TI_ADS7950_GPIO_MASK)); > + ret = spi_sync(st->spi, &st->scan_single_msg > + if (ret) { > + mutex_unlock(&st->slock); > + return ret; > + } > + > + /* Default to signal low */ > + st->gpio_signal_bitmask = 0x0; > + st->single_tx = cpu_to_be16(TI_ADS7950_CR_MANUAL | > + TI_ADS7950_CR_WRITE | > + (st->gpio_signal_bitmask & > + TI_ADS7950_GPIO_MASK)); > + ret = spi_sync(st->spi, &st->scan_single_msg); > + mutex_unlock(&st->slock); > + if (ret) > + return ret; > + > + /* Add GPIO chip */ > + st->chip.label = dev_name(&st->spi->dev); > + st->chip.parent = &st->spi->dev; > + st->chip.owner = THIS_MODULE; > + st->chip.base = -1; > + st->chip.ngpio = TI_ADS7950_NUM_GPIOS; > + st->chip.get_direction = ti_ads7950_get_direction; > + st->chip.direction_input = ti_ads7950_direction_input; > + st->chip.direction_output = ti_ads7950_direction_output; > + st->chip.get = ti_ads7950_get; > + st->chip.set = ti_ads7950_set; Does it make sense to also implement chip.get_multiple and chip.set_multiple to minimize SPI transactions? > + > + return gpiochip_add_data(&st->chip, st); > +} > + > static int ti_ads7950_probe(struct spi_device *spi) > { > struct ti_ads7950_state *st; > @@ -457,8 +610,17 @@ static int ti_ads7950_probe(struct spi_device *spi) > goto error_cleanup_ring; > } > > + mutex_init(&st->slock); This will probably never actually cause a problem, but the mutex should probably be inited before registering the iio device since it uses the mutex as well. > + ret = ti_ads7950_init_gpio(st); > + if (ret) { > + dev_err(&spi->dev, "Failed to initialize GPIOs\n"); > + goto error_destroy_mutex; > + } > + > return 0; > > +error_destroy_mutex: > + mutex_destroy(&st->slock); > error_cleanup_ring: > iio_triggered_buffer_cleanup(indio_dev); > error_disable_reg: > @@ -475,6 +637,7 @@ static int ti_ads7950_remove(struct spi_device *spi) > iio_device_unregister(indio_dev); > iio_triggered_buffer_cleanup(indio_dev); > regulator_disable(st->reg); > + mutex_destroy(&st->slock); > > return 0; > } >