[1/2] Input: Add binding document for a generic ADC keypad

Add a binding document for a generic ADC keypad.  Buttons on an ADC
keypad are connected in a resistor ladder to an ADC.  The binding
describes the mapping of ADC channel and voltage ranges to buttons.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
---
 .../devicetree/bindings/input/adc-keys.txt         | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt

On 28/03/15 00:43, Andrew Bresticker wrote:
> Add a polled input driver for a keypad in which the buttons are connected
> in resistor ladders to an ADC.  The IIO framework is used to claim and
> read the ADC channels.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
The IIO side of things looks fine.
> ---
>  drivers/input/keyboard/Kconfig    |  13 ++
>  drivers/input/keyboard/Makefile   |   1 +
>  drivers/input/keyboard/adc-keys.c | 291 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 305 insertions(+)
>  create mode 100644 drivers/input/keyboard/adc-keys.c
> 
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index a89ba7c..bbaff9e 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -12,6 +12,19 @@ menuconfig INPUT_KEYBOARD
>  
>  if INPUT_KEYBOARD
>  
> +config KEYBOARD_ADC
> +	tristate "ADC Keypad"
> +	depends on IIO
> +	select INPUT_POLLDEV
> +	help
> +	  This driver supports generic ADC keypads using IIO.
> +
> +	  Say Y here if your device has buttons connected in a resistor ladder
> +	  to an ADC.
> +
> +	  To compile this driver as a module, choose M here: the module will
> +	  be called adc-keys.
> +
>  config KEYBOARD_ADP5520
>  	tristate "Keypad Support for ADP5520 PMIC"
>  	depends on PMIC_ADP5520
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 4707678..888fa62 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -4,6 +4,7 @@
>  
>  # Each configuration option enables a list of files.
>  
> +obj-$(CONFIG_KEYBOARD_ADC)		+= adc-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5520)		+= adp5520-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5588)		+= adp5588-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5589)		+= adp5589-keys.o
> diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> new file mode 100644
> index 0000000..1b9bcad
> --- /dev/null
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -0,0 +1,291 @@
> +/*
> + * ADC keypad driver
> + *
> + * Copyright (C) 2015 Google, Inc.
> + *
> + * Based on /drivers/input/keybaord/gpio_keys_polled.c:
> + *  Copyright (C) 2007-2010 Gabor Juhos <juhosg@openwrt.org>
> + *  Copyright (C) 2010 Nuno Goncalves <nunojpg@gmail.com>
> + *
> + * 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/iio/consumer.h>
> +#include <linux/input.h>
> +#include <linux/input-polldev.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +struct adc_key {
> +	const char *desc;
> +	unsigned int type;
> +	unsigned int code;
> +	unsigned int min_uV;
> +	unsigned int max_uV;
> +};
> +
> +struct adc_chan_map {
> +	struct adc_key *keys;
> +	unsigned int num_keys;
> +	int last_key;
> +};
> +
> +struct adc_keypad {
> +	struct device *dev;
> +	struct input_polled_dev *poll_dev;
> +	unsigned int poll_interval;
> +	bool autorepeat;
> +	struct iio_channel *iio_chans;
> +	unsigned int num_chans;
> +	struct adc_chan_map *chan_map;
> +};
> +
> +static void adc_keypad_poll_chan(struct adc_keypad *keypad, unsigned int chan)
> +{
> +	struct adc_chan_map *chan_map = &keypad->chan_map[chan];
> +	struct input_dev *input = keypad->poll_dev->input;
> +	struct adc_key *key;
> +	unsigned int adc_uV;
> +	int ret, val, i;
> +
> +	ret = iio_read_channel_processed(&keypad->iio_chans[chan], &val);
> +	if (ret < 0) {
> +		dev_err(keypad->dev, "Failed to read ADC: %d\n", ret);
> +		return;
> +	}
> +	adc_uV = val * 1000;
> +
> +	for (i = 0; i < chan_map->num_keys; i++) {
> +		if (adc_uV >= chan_map->keys[i].min_uV &&
> +		    adc_uV <= chan_map->keys[i].max_uV)
> +			break;
> +	}
> +	if (i >= chan_map->num_keys)
> +		i = -1;
> +
> +	if (i != chan_map->last_key) {
> +		if (chan_map->last_key >= 0) {
> +			key = &chan_map->keys[chan_map->last_key];
> +			input_event(input, key->type, key->code, 0);
> +		}
> +		if (i >= 0) {
> +			key = &chan_map->keys[i];
> +			input_event(input, key->type, key->code, 1);
> +		}
> +		input_sync(input);
> +		chan_map->last_key = i;
> +	}
> +}
> +
> +static void adc_keypad_poll(struct input_polled_dev *poll_dev)
> +{
> +	struct adc_keypad *keypad = poll_dev->private;
> +	unsigned int i;
> +
> +	for (i = 0; i < keypad->num_chans; i++)
> +		adc_keypad_poll_chan(keypad, i);
> +}
> +
> +static int adc_keypad_of_parse_chan(struct adc_keypad *keypad,
> +				    unsigned int chan)
> +{
> +	struct device_node *child, *np = keypad->dev->of_node;
> +	struct adc_key *keys;
> +	unsigned int i = 0;
> +	int ret;
> +
> +	for_each_child_of_node(np, child) {
> +		unsigned int c;
> +
> +		ret = of_property_read_u32(child, "channel", &c);
> +		if (ret < 0)
> +			continue;
> +		if (c != chan)
> +			continue;
> +		i++;
> +	}
> +
> +	keys = devm_kcalloc(keypad->dev, i, sizeof(*keys), GFP_KERNEL);
> +	if (!keys)
> +		return -ENOMEM;
> +	keypad->chan_map[chan].keys = keys;
> +	keypad->chan_map[chan].num_keys = i;
> +
> +	i = 0;
> +	for_each_child_of_node(np, child) {
> +		struct adc_key *key = &keys[i];
> +		unsigned int c;
> +
> +		ret = of_property_read_u32(child, "channel", &c);
> +		if (ret < 0)
> +			continue;
> +		if (c != chan)
> +			continue;
> +
> +		ret = of_property_read_string(child, "label", &key->desc);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = of_property_read_u32(child, "min-voltage", &key->min_uV);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = of_property_read_u32(child, "max-voltage", &key->max_uV);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = of_property_read_u32(child, "linux,code", &key->code);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = of_property_read_u32(child, "linux,input-type",
> +					   &key->type);
> +		if (ret < 0)
> +			key->type = EV_KEY;
> +
> +		i++;
> +		if (i >= keypad->chan_map[chan].num_keys)
> +			break;
> +	}
> +
> +	return 0;
> +}
> +
> +static int adc_keypad_of_parse(struct adc_keypad *keypad)
> +{
> +	struct device_node *np = keypad->dev->of_node;
> +	unsigned int i;
> +	int ret;
> +
> +	keypad->autorepeat = of_property_read_bool(np, "autorepeat");
> +	ret = of_property_read_u32(np, "poll-interval", &keypad->poll_interval);
> +	if (ret < 0)
> +		return ret;
> +
> +	for (i = 0; i < keypad->num_chans; i++) {
> +		ret = adc_keypad_of_parse_chan(keypad, i);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int adc_keypad_probe(struct platform_device *pdev)
> +{
> +	struct adc_keypad *keypad;
> +	struct input_polled_dev *poll_dev;
> +	struct input_dev *input;
> +	unsigned int i;
> +	int ret;
> +
> +	keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> +	if (!keypad)
> +		return -ENOMEM;
> +	keypad->dev = &pdev->dev;
> +	platform_set_drvdata(pdev, keypad);
> +
> +	keypad->iio_chans = iio_channel_get_all(&pdev->dev);
> +	if (IS_ERR(keypad->iio_chans)) {
> +		dev_err(&pdev->dev, "Failed to get IIO channels: %ld\n",
> +			PTR_ERR(keypad->iio_chans));
> +		return PTR_ERR(keypad->iio_chans);
> +	}
> +
> +	i = 0;
> +	while (keypad->iio_chans[i].channel != NULL)
> +		i++;
> +	keypad->num_chans = i;
> +	keypad->chan_map = devm_kcalloc(&pdev->dev, keypad->num_chans,
> +					sizeof(*keypad->chan_map), GFP_KERNEL);
> +	if (!keypad->chan_map) {
> +		ret = -ENOMEM;
> +		goto put_chans;
> +	}
> +
> +	ret = adc_keypad_of_parse(keypad);
> +	if (ret < 0)
> +		goto put_chans;
> +
> +	poll_dev = devm_input_allocate_polled_device(&pdev->dev);
> +	if (!poll_dev) {
> +		ret = -ENOMEM;
> +		goto put_chans;
> +	}
> +	keypad->poll_dev = poll_dev;
> +
> +	poll_dev->private = keypad;
> +	poll_dev->poll = adc_keypad_poll;
> +	poll_dev->poll_interval = keypad->poll_interval;
> +
> +	input = poll_dev->input;
> +	input->name = pdev->name;
> +	input->phys = "adc-keys/input0";
> +
> +	input->id.bustype = BUS_HOST;
> +	input->id.vendor = 0x0001;
> +	input->id.product = 0x0001;
> +	input->id.version = 0x0100;
Why these particular values?
> +
> +	__set_bit(EV_KEY, input->evbit);
> +	if (keypad->autorepeat)
> +		__set_bit(EV_REP, input->evbit);
> +
> +	for (i = 0; i < keypad->num_chans; i++) {
> +		struct adc_chan_map *chan_map = &keypad->chan_map[i];
> +		unsigned int j;
> +
> +		for (j = 0; j < chan_map->num_keys; j++)
> +			input_set_capability(input, chan_map->keys[j].type,
> +					     chan_map->keys[j].code);
> +	}
> +
> +	ret = input_register_polled_device(poll_dev);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to register polled device: %d\n",
> +			ret);
> +		goto put_chans;
> +	}
> +
> +	return 0;
> +
> +put_chans:
> +	iio_channel_release_all(keypad->iio_chans);
> +	return ret;
> +}
> +
> +static int adc_keypad_remove(struct platform_device *pdev)
> +{
> +	struct adc_keypad *keypad = platform_get_drvdata(pdev);
> +
> +	input_unregister_polled_device(keypad->poll_dev);
> +
> +	iio_channel_release_all(keypad->iio_chans);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id adc_keypad_of_match[] = {
> +	{ .compatible = "adc-keys", },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, adc_keypad_of_match);
> +
> +static struct platform_driver adc_keypad_driver = {
> +	.probe	= adc_keypad_probe,
> +	.remove	= adc_keypad_remove,
> +	.driver	= {
> +		.name = "adc-keys",
> +		.of_match_table	= adc_keypad_of_match,
> +	},
> +};
> +module_platform_driver(adc_keypad_driver);
> +
> +MODULE_DESCRIPTION("ADC keypad driver");
> +MODULE_AUTHOR("Andrew Bresticker <abrestic@chromium.org>");
> +MODULE_LICENSE("GPL v2");
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 28/03/15 00:43, Andrew Bresticker wrote:
> Add a binding document for a generic ADC keypad.  Buttons on an ADC
> keypad are connected in a resistor ladder to an ADC.  The binding
> describes the mapping of ADC channel and voltage ranges to buttons.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>

Just thinking about this, what options do we have for how such a keypad might
be wired.  The interesting cases are the more than one key at a time ones.

If that happens, then we end up with a voltage that should allow us to 
work out which combination of keys is pressed.

http://en.wikipedia.org/wiki/Resistor_ladder

The binding as it stands only works for single keys being pressed at a time
(I think!)

Do we want to make it flexible enough to cope with multiple keys?
I guess we'd need to model the common resistor ladder forms and provide
a way of specifying the different setups in the device tree.

J
> ---
>  .../devicetree/bindings/input/adc-keys.txt         | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt b/Documentation/devicetree/bindings/input/adc-keys.txt
> new file mode 100644
> index 0000000..c9a57de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
> @@ -0,0 +1,43 @@
> +Generic ADC keypad
> +==================
> +
> +Required properties:
> + - compatible: "adc-keys"
> + - poll-interval: Polling interval time in ms.
> + - io-channels: List of IIO channels used by the keypad.
> +   See ../iio/iio-bindings.txt for details.
> +
> +Optional properties:
> + - autorepeat: Enable auto-repeat.
> +
> +Each button on the ADC keypad is represented by a sub-node.
> +
> +Required sub-node properties:
> + - label: Descriptive name for the key.
> + - linux,code: Keycode to emit.
> + - channel: IIO channel (index into the 'io-channels' above) to which this
> +   button is attached.
> + - min-voltage: Minimum voltage in uV when this key is pressed.
> + - max-voltage: Maximum voltage in uV when this key is pressed.
> +
> +Optional sub-node properties:
> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) if
> +   not specified.
> +
> +Example:
> +
> +adc-keypad {
> +	compatible = "adc-keys";
> +	poll-interval = <100>;
> +	io-channels = <&adc 0>, <&adc 1>;
> +
> +	vol-up-button {
> +		label = "Volume Up";
> +		linux,code = <KEY_VOLUMEUP>;
> +		channel = <0>;
> +		min-voltage = <1600000>;
> +		max-voltage = <1640000>;
> +	};
> +
> +	...
> +};
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Mar 27, 2015 at 05:43:17PM -0700, Andrew Bresticker wrote:
> Add a binding document for a generic ADC keypad.  Buttons on an ADC
> keypad are connected in a resistor ladder to an ADC.  The binding
> describes the mapping of ADC channel and voltage ranges to buttons.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> ---
>  .../devicetree/bindings/input/adc-keys.txt         | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt b/Documentation/devicetree/bindings/input/adc-keys.txt
> new file mode 100644
> index 0000000..c9a57de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
> @@ -0,0 +1,43 @@
> +Generic ADC keypad
> +==================
> +
> +Required properties:
> + - compatible: "adc-keys"
> + - poll-interval: Polling interval time in ms.
> + - io-channels: List of IIO channels used by the keypad.
> +   See ../iio/iio-bindings.txt for details.
> +
> +Optional properties:
> + - autorepeat: Enable auto-repeat.
> +
> +Each button on the ADC keypad is represented by a sub-node.
> +
> +Required sub-node properties:
> + - label: Descriptive name for the key.
> + - linux,code: Keycode to emit.
> + - channel: IIO channel (index into the 'io-channels' above) to which this
> +   button is attached.
> + - min-voltage: Minimum voltage in uV when this key is pressed.
> + - max-voltage: Maximum voltage in uV when this key is pressed.
> +
> +Optional sub-node properties:
> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) if
> +   not specified.

I'd rather we have it defined explicitly in the binding, i.e. make it a
required property?

> +
> +Example:
> +
> +adc-keypad {
> +	compatible = "adc-keys";
> +	poll-interval = <100>;
> +	io-channels = <&adc 0>, <&adc 1>;
> +
> +	vol-up-button {
> +		label = "Volume Up";
> +		linux,code = <KEY_VOLUMEUP>;
> +		channel = <0>;
> +		min-voltage = <1600000>;
> +		max-voltage = <1640000>;
> +	};
> +
> +	...
> +};
> -- 
> 2.2.0.rc0.207.ga3a616c
>

On Sat, Mar 28, 2015 at 7:03 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 28/03/15 00:43, Andrew Bresticker wrote:
>> Add a binding document for a generic ADC keypad.  Buttons on an ADC
>> keypad are connected in a resistor ladder to an ADC.  The binding
>> describes the mapping of ADC channel and voltage ranges to buttons.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>
> Just thinking about this, what options do we have for how such a keypad might
> be wired.  The interesting cases are the more than one key at a time ones.
>
> If that happens, then we end up with a voltage that should allow us to
> work out which combination of keys is pressed.
>
> http://en.wikipedia.org/wiki/Resistor_ladder
>
> The binding as it stands only works for single keys being pressed at a time
> (I think!)

Right.  The binding was meant for the simplest resistor ladder case,
something like http://linksprite.com/wiki/images/d/d2/Lcd-button-ladder.png
where only a single button press can be detected.  It will also work
with the more complex resistor ladders, but will only be able to
detect if a single button is pressed.

> Do we want to make it flexible enough to cope with multiple keys?
> I guess we'd need to model the common resistor ladder forms and provide
> a way of specifying the different setups in the device tree.

Given that the hardware I'm dealing with doesn't support this, I'd
prefer to leave it as a possible future extension :).  That said, one
way to do this would be to specify a table mapping the possible
combinations to voltages in the DT, though that table would grow
exponentially.  Another way would be to describe the circuit (R-2R,
logarithmic, etc.) with resistor values in the DT and then have the
driver do the math.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Mar 28, 2015 at 9:00 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Fri, Mar 27, 2015 at 05:43:17PM -0700, Andrew Bresticker wrote:
>> Add a binding document for a generic ADC keypad.  Buttons on an ADC
>> keypad are connected in a resistor ladder to an ADC.  The binding
>> describes the mapping of ADC channel and voltage ranges to buttons.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> ---
>>  .../devicetree/bindings/input/adc-keys.txt         | 43 ++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
>>
>> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt b/Documentation/devicetree/bindings/input/adc-keys.txt
>> new file mode 100644
>> index 0000000..c9a57de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
>> @@ -0,0 +1,43 @@
>> +Generic ADC keypad
>> +==================
>> +
>> +Required properties:
>> + - compatible: "adc-keys"
>> + - poll-interval: Polling interval time in ms.
>> + - io-channels: List of IIO channels used by the keypad.
>> +   See ../iio/iio-bindings.txt for details.
>> +
>> +Optional properties:
>> + - autorepeat: Enable auto-repeat.
>> +
>> +Each button on the ADC keypad is represented by a sub-node.
>> +
>> +Required sub-node properties:
>> + - label: Descriptive name for the key.
>> + - linux,code: Keycode to emit.
>> + - channel: IIO channel (index into the 'io-channels' above) to which this
>> +   button is attached.
>> + - min-voltage: Minimum voltage in uV when this key is pressed.
>> + - max-voltage: Maximum voltage in uV when this key is pressed.
>> +
>> +Optional sub-node properties:
>> + - linux,input-type: Event type this key generates.  Defaults to 1 (EV_KEY) if
>> +   not specified.
>
> I'd rather we have it defined explicitly in the binding, i.e. make it a
> required property?

Sure, will do.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sat, Mar 28, 2015 at 7:02 AM, Jonathan Cameron <jic23@kernel.org> wrote:
> On 28/03/15 00:43, Andrew Bresticker wrote:
>> Add a polled input driver for a keypad in which the buttons are connected
>> in resistor ladders to an ADC.  The IIO framework is used to claim and
>> read the ADC channels.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>

>> +static int adc_keypad_probe(struct platform_device *pdev)
>> +{
>> +     struct adc_keypad *keypad;
>> +     struct input_polled_dev *poll_dev;
>> +     struct input_dev *input;
>> +     unsigned int i;
>> +     int ret;
>> +
>> +     keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
>> +     if (!keypad)
>> +             return -ENOMEM;
>> +     keypad->dev = &pdev->dev;
>> +     platform_set_drvdata(pdev, keypad);
>> +
>> +     keypad->iio_chans = iio_channel_get_all(&pdev->dev);
>> +     if (IS_ERR(keypad->iio_chans)) {
>> +             dev_err(&pdev->dev, "Failed to get IIO channels: %ld\n",
>> +                     PTR_ERR(keypad->iio_chans));
>> +             return PTR_ERR(keypad->iio_chans);
>> +     }
>> +
>> +     i = 0;
>> +     while (keypad->iio_chans[i].channel != NULL)
>> +             i++;
>> +     keypad->num_chans = i;
>> +     keypad->chan_map = devm_kcalloc(&pdev->dev, keypad->num_chans,
>> +                                     sizeof(*keypad->chan_map), GFP_KERNEL);
>> +     if (!keypad->chan_map) {
>> +             ret = -ENOMEM;
>> +             goto put_chans;
>> +     }
>> +
>> +     ret = adc_keypad_of_parse(keypad);
>> +     if (ret < 0)
>> +             goto put_chans;
>> +
>> +     poll_dev = devm_input_allocate_polled_device(&pdev->dev);
>> +     if (!poll_dev) {
>> +             ret = -ENOMEM;
>> +             goto put_chans;
>> +     }
>> +     keypad->poll_dev = poll_dev;
>> +
>> +     poll_dev->private = keypad;
>> +     poll_dev->poll = adc_keypad_poll;
>> +     poll_dev->poll_interval = keypad->poll_interval;
>> +
>> +     input = poll_dev->input;
>> +     input->name = pdev->name;
>> +     input->phys = "adc-keys/input0";
>> +
>> +     input->id.bustype = BUS_HOST;
>> +     input->id.vendor = 0x0001;
>> +     input->id.product = 0x0001;
>> +     input->id.version = 0x0100;

> Why these particular values?

I just chose these because these are the values most other platform
input devices use, including gpio_keys and gpio_keys_polled.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Andrew,

On Mon, Mar 30, 2015 at 1:56 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:

>> I'd rather we have it defined explicitly in the binding, i.e. make it a
>> required property?
>
> Sure, will do.

Do you plan to send a v2 of the generic ADC keypad series?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Fabio,

On Sun, Nov 1, 2015 at 5:55 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Andrew,
>
> On Mon, Mar 30, 2015 at 1:56 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>
>>> I'd rather we have it defined explicitly in the binding, i.e. make it a
>>> required property?
>>
>> Sure, will do.
>
> Do you plan to send a v2 of the generic ADC keypad series?

We ended up not needing this driver, so I didn't send up a v2.

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html