devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Peter Rosin <peda@axentia.se>, linux-kernel@vger.kernel.org
Cc: Wolfram Sang <wsa@the-dreams.de>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Jonathan Corbet <corbet@lwn.net>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v6 9/9] misc: mux-adg792a: add mux controller driver for ADG792A/G
Date: Sun, 1 Jan 2017 11:24:03 +0000	[thread overview]
Message-ID: <fb8a7864-a6cf-351f-b9c5-a5036c30474e@kernel.org> (raw)
In-Reply-To: <1480493823-21462-10-git-send-email-peda@axentia.se>

On 30/11/16 08:17, Peter Rosin wrote:
> Analog Devices ADG792A/G is a triple 4:1 mux.
> 
> Signed-off-by: Peter Rosin <peda@axentia.se>
Looks pretty good. Some minor suggestions inline.

This convinced me of two things:
1. Need a separate subsystem directory for muxes - having them under misc
is going to lead to long term mess.
2. Devm alloc and registration functions will make the drivers all simpler.

Also, browsing through ADIs list of muxes and switches it's clear that
one classic case will be where an i2c octal or similar switch is used with
outputs wired together in weird combinations to act as a mux.  Going to
be 'fun' describing that.

There are also potentially cross point switches to be described ;)
(I had to look up what one of those was ;)

Crosspoints aren't implausible as front ends for ADCs as you might
want to be able rapidly sample any 2 of say 16 channels coming from
for example a max14661.  We'd have to figure out how to add buffered
capture support with sensible restrictions to the iio-mux driver
to do that - realistically I think we would just not allow buffered
capture with the mux having to switch.  Without hardware support
(i.e. an ADC with external mux control) it would be too slow.

Always good to bury some idle thoughts deep in the review of a random
driver ;) I'll never be able to remember where they were let alone
anyone else.

Jonathan

> ---
>  drivers/misc/Kconfig       |  12 ++++
>  drivers/misc/Makefile      |   1 +
>  drivers/misc/mux-adg792a.c | 154 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 167 insertions(+)
>  create mode 100644 drivers/misc/mux-adg792a.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 2ce675e410c5..45567a444bbf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -780,6 +780,18 @@ menuconfig MULTIPLEXER
>  
>  if MULTIPLEXER
>  
> +config MUX_ADG792A
> +	tristate "Analog Devices ADG792A/ADG792G Multiplexers"
> +	depends on I2C
> +	help
> +	  ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
> +
> +	  The driver supports both operating the three multiplexers in
> +	  parellel and operating them independently.
parallel
> +
> +	  To compile the driver as a module, choose M here: the module will
> +	  be called mux-adg792a.
> +
>  config MUX_GPIO
>  	tristate "GPIO-controlled Multiplexer"
>  	depends on OF && GPIOLIB
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 0befa2bba762..10ab8d34c9e5 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG)	+= vexpress-syscfg.o
>  obj-$(CONFIG_CXL_BASE)		+= cxl/
>  obj-$(CONFIG_PANEL)             += panel.o
>  obj-$(CONFIG_MULTIPLEXER)      	+= mux-core.o
> +obj-$(CONFIG_MUX_ADG792A)	+= mux-adg792a.o
>  obj-$(CONFIG_MUX_GPIO)		+= mux-gpio.o
>  
>  lkdtm-$(CONFIG_LKDTM)		+= lkdtm_core.o
> diff --git a/drivers/misc/mux-adg792a.c b/drivers/misc/mux-adg792a.c
> new file mode 100644
> index 000000000000..7d309a78af65
> --- /dev/null
> +++ b/drivers/misc/mux-adg792a.c
> @@ -0,0 +1,154 @@
> +/*
> + * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
> + *
> + * Copyright (C) 2016 Axentia Technologies AB
> + *
> + * Author: Peter Rosin <peda@axentia.se>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/mux.h>
> +
> +#define ADG792A_LDSW		BIT(0)
> +#define ADG792A_RESET		BIT(1)
> +#define ADG792A_DISABLE(mux)	(0x50 | (mux))
> +#define ADG792A_DISABLE_ALL	(0x5f)
> +#define ADG792A_MUX(mux, state)	(0xc0 | (((mux) + 1) << 2) | (state))
> +#define ADG792A_MUX_ALL(state)	(0xc0 | (state))
> +
> +#define ADG792A_DISABLE_STATE	(4)
> +#define ADG792A_KEEP_STATE	(5)
> +
> +static int adg792a_set(struct mux_control *mux, int state)
> +{
> +	struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
> +	u8 cmd;
> +
> +	if (mux->chip->controllers == 1) {
> +		/* parallel mux controller operation */
> +		if (state == ADG792A_DISABLE_STATE)
> +			cmd = ADG792A_DISABLE_ALL;
> +		else
> +			cmd = ADG792A_MUX_ALL(state);
> +	} else {
> +		unsigned int controller = mux_control_get_index(mux);
> +
> +		if (state == ADG792A_DISABLE_STATE)
> +			cmd = ADG792A_DISABLE(controller);
> +		else
> +			cmd = ADG792A_MUX(controller, state);
> +	}
> +
> +	return i2c_smbus_write_byte_data(i2c, cmd, ADG792A_LDSW);
> +}
> +
> +static const struct mux_control_ops adg792a_ops = {
> +	.set = adg792a_set,
> +};
> +
> +static int adg792a_probe(struct i2c_client *i2c,
> +			 const struct i2c_device_id *id)
> +{
> +	struct device *dev = &i2c->dev;
> +	struct mux_chip *mux_chip;
> +	bool parallel;
> +	int ret;
> +	int i;
> +
> +	parallel = of_property_read_bool(i2c->dev.of_node, "adi,parallel");
> +
> +	mux_chip = mux_chip_alloc(dev, parallel ? 1 : 3, 0);
This makes me wonder if we can have a more generic binding.
mux-poles = 3 vs mux-poles = 1?

> +	if (!mux_chip)
> +		return -ENOMEM;
> +
> +	mux_chip->ops = &adg792a_ops;
> +	dev_set_drvdata(dev, mux_chip);
> +
> +	ret = i2c_smbus_write_byte_data(i2c, ADG792A_DISABLE_ALL,
> +					ADG792A_RESET | ADG792A_LDSW);
> +	if (ret < 0)
> +		goto free_mux_chip;
> +
> +	for (i = 0; i < mux_chip->controllers; ++i) {
> +		struct mux_control *mux = &mux_chip->mux[i];
> +		u32 idle_state;
> +
> +		mux->states = 4;
> +
> +		ret = of_property_read_u32_index(i2c->dev.of_node,
> +						 "adi,idle-state", i,
> +						 &idle_state);
> +		if (ret >= 0) {
> +			if (idle_state > ADG792A_KEEP_STATE) {
> +				dev_err(dev, "invalid idle-state %u\n",
> +					idle_state);
> +				ret = -EINVAL;
> +				goto free_mux_chip;
> +			}
> +			if (idle_state != ADG792A_KEEP_STATE)
> +				mux->idle_state = idle_state;
> +		}
> +	}
> +
> +	ret = mux_chip_register(mux_chip);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to register mux-chip\n");
> +		goto free_mux_chip;
> +	}
> +
> +	if (parallel)
> +		dev_info(dev, "1 triple 4-way mux-controller registered\n");
I'd use the relay / switch standard description for this so 
'triple pole, quadruple throw mux registered'.
> +	else
> +		dev_info(dev, "3 4-way mux-controllers registered\n");
'3x single pole, quadruple throw muxes registered'.
> +
> +	return 0;
> +
> +free_mux_chip:
> +	mux_chip_free(mux_chip);
> +	return ret;
> +}
> +
> +static int adg792a_remove(struct i2c_client *i2c)
> +{
> +	struct mux_chip *mux_chip = dev_get_drvdata(&i2c->dev);
> +
Definitely looking like it's worth managed versions of mux_chip_register and
mux_chip_alloc given this is another case where they would let us get rid
of the remove function entirely.
> +	mux_chip_unregister(mux_chip);
> +	mux_chip_free(mux_chip);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id adg792a_id[] = {
> +	{ .name = "adg792a", },
> +	{ .name = "adg792g", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, adg792a_id);
> +
> +static const struct of_device_id adg792a_of_match[] = {
> +	{ .compatible = "adi,adg792a", },
> +	{ .compatible = "adi,adg792g", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, adg792a_of_match);
> +
> +static struct i2c_driver adg792a_driver = {
> +	.driver		= {
> +		.name		= "adg792a",
> +		.of_match_table = of_match_ptr(adg792a_of_match),
> +	},
> +	.probe		= adg792a_probe,
> +	.remove		= adg792a_remove,
> +	.id_table	= adg792a_id,
> +};
> +module_i2c_driver(adg792a_driver);
> +
> +MODULE_DESCRIPTION("Analog Devices ADG792A/G Triple 4:1 mux driver");
> +MODULE_AUTHOR("Peter Rosin <peda@axentia.se");
> +MODULE_LICENSE("GPL v2");
> 


  reply	other threads:[~2017-01-01 11:24 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30  8:16 [PATCH v6 0/9] mux controller abstraction and iio/i2c muxes Peter Rosin
     [not found] ` <1480493823-21462-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
2016-11-30  8:16   ` [PATCH v6 1/9] dt-bindings: document devicetree bindings for mux-controllers and mux-gpio Peter Rosin
2016-12-31 16:10     ` Jonathan Cameron
2016-11-30  8:17   ` [PATCH v6 7/9] i2c: i2c-mux-simple: new driver Peter Rosin
     [not found]     ` <1480493823-21462-8-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
2017-01-01 10:31       ` Jonathan Cameron
2017-01-01 15:38     ` Andy Shevchenko
     [not found]       ` <CAHp75Vc2uYhaYJu_eU-uBq_PZrUgaoNt8sxpuRF8eEEs2kPUwg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-02 15:30         ` Peter Rosin
2016-11-30  8:17   ` [PATCH v6 8/9] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux Peter Rosin
2017-01-01 11:00     ` Jonathan Cameron
2017-01-02 16:01       ` Peter Rosin
2017-01-02 18:05         ` Jonathan Cameron
2017-01-02 20:47           ` Peter Rosin
2017-01-02 21:13             ` Jonathan Cameron
     [not found]               ` <90A8A4B3-670B-4409-B7AB-47BF4B2ABDDA-tko9wxEg+fIOOJlXag/Snyp2UmYkHbXO@public.gmane.org>
2017-01-03  6:44                 ` Peter Rosin
2016-11-30  8:17   ` [PATCH v6 9/9] misc: mux-adg792a: add mux controller driver for ADG792A/G Peter Rosin
2017-01-01 11:24     ` Jonathan Cameron [this message]
2017-01-02 11:00       ` Peter Rosin
2017-01-02 18:08         ` Jonathan Cameron
2017-01-01 11:28   ` [PATCH v6 0/9] mux controller abstraction and iio/i2c muxes Jonathan Cameron
2016-11-30  8:16 ` [PATCH v6 2/9] misc: minimal mux subsystem and gpio-based mux controller Peter Rosin
2016-12-31 16:19   ` Jonathan Cameron
2017-01-02  9:14     ` Peter Rosin
     [not found]       ` <7080f03c-0ee3-13b2-b242-21f80052e479-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
2017-01-02  9:20         ` Jonathan Cameron
2016-11-30  8:16 ` [PATCH v6 3/9] iio: inkern: api for manipulating ext_info of iio channels Peter Rosin
     [not found]   ` <1480493823-21462-4-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
2016-12-31 15:51     ` Jonathan Cameron
2016-11-30  8:16 ` [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings Peter Rosin
2016-11-30  8:52   ` Peter Rosin
2016-11-30  8:57     ` Peter Rosin
2016-12-05 23:26   ` Rob Herring
2016-12-06  9:18     ` Peter Rosin
     [not found]       ` <ea58cfe1-88ed-f215-59df-e9ffba485eaa-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
2016-12-10 18:21         ` Jonathan Cameron
     [not found]           ` <d2726499-4034-8d5d-4cff-61da86af5add-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-12-12 12:18             ` Peter Rosin
2016-12-31 16:01               ` Jonathan Cameron
2016-11-30  8:16 ` [PATCH v6 5/9] iio: multiplexer: new iio category and iio-mux driver Peter Rosin
2016-12-31 16:21   ` Jonathan Cameron
2016-11-30  8:17 ` [PATCH v6 6/9] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings Peter Rosin

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=fb8a7864-a6cf-351f-b9c5-a5036c30474e@kernel.org \
    --to=jic23@kernel.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peda@axentia.se \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    --cc=wsa@the-dreams.de \
    /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;
as well as URLs for NNTP newsgroup(s).