linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>,
	pali.rohar@gmail.com, sre@debian.org, sre@ring0.de,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org,
	aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com,
	patrikbachan@gmail.com, galak@codeaurora.org,
	bcousson@baylibre.com, m.chehab@samsung.com,
	devicetree@vger.kernel.org
Subject: Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
Date: Thu, 2 Apr 2015 19:14:53 +0300	[thread overview]
Message-ID: <20150402161453.GH20756@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <20150402143846.GA11687@amd>

Hi Pawel,

My apologies for the very late reply.

On Thu, Apr 02, 2015 at 04:38:46PM +0200, Pavel Machek wrote:
> 
> 
> We are moving to device tree support on OMAP3, but that currently
> breaks ADP1653 driver. This adds device tree support, plus required
> documentation.
> 
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> ---
> 
> I'm not sure if it is device tree or media framework, either everyone
> waits for someone else, or noone really cares.

Neither. Some people are unfortuantely very busy with many other things as
well. :-P

> Andrew, can you just merge it?
> 
> Please apply,

Please wait just a while.

I think we can merge this eventually through the linux-media tree, but
please first see the comments below.

> 							Pavel
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> new file mode 100644
> index 0000000..0fc28a9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
> @@ -0,0 +1,37 @@
> +* Analog Devices ADP1653 flash LED driver
> +
> +Required Properties:
> +
> +  - compatible: Must contain be "adi,adp1653"
> +
> +  - reg: I2C slave address
> +
> +  - gpios: References to the GPIO that controls the power for the chip.
> +
> +There are two led outputs available - flash and indicator. One led is
> +represented by one child node, nodes need to be named "flash" and "indicator".
> +
> +Required properties of the LED child node:
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +
> +Required properties of the flash LED child node:
> +
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt

The documentation says that the maximum value is used if these values are
not specified. I think I'd make these optional.

> +
> +Example:
> +
> +	adp1653: led-controller@30 {
> +		compatible = "adi,adp1653";
> +		reg = <0x30>;
> +		gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> +
> +		flash {
> +			flash-timeout-us = <500000>;
> +			flash-max-microamp = <320000>;
> +			max-microamp = <50000>;
> +		};
> +		indicator {
> +			max-microamp = <17500>;
> +		};
> +	};
> diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> index 873fe19..0341009 100644
> --- a/drivers/media/i2c/adp1653.c
> +++ b/drivers/media/i2c/adp1653.c
> @@ -8,6 +8,7 @@
>   * Contributors:
>   *	Sakari Ailus <sakari.ailus@iki.fi>
>   *	Tuukka Toivonen <tuukkat76@gmail.com>
> + *	Pavel Machek <pavel@ucw.cz>
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License
> @@ -34,6 +35,8 @@
>  #include <linux/module.h>
>  #include <linux/i2c.h>
>  #include <linux/slab.h>
> +#include <linux/of_gpio.h>
> +#include <linux/gpio.h>
>  #include <media/adp1653.h>
>  #include <media/v4l2-device.h>
>  
> @@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
>  static int
>  __adp1653_set_power(struct adp1653_flash *flash, int on)
>  {
> -	int ret;
> +	int ret = 0;
> +
> +	if (flash->platform_data->power) {
> +		ret = flash->platform_data->power(&flash->subdev, on);

The power() callback should be dropped. It's controlling a GPIO. But that
can be done later on. The alternative is a patch before this one.

> +	} else {
> +		gpio_set_value(flash->platform_data->power_gpio, on);
> +		if (on)
> +			/* Some delay is apparently required. */
> +			udelay(20);
> +	}
>  
> -	ret = flash->platform_data->power(&flash->subdev, on);
>  	if (ret < 0)
>  		return ret;
>  
> @@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
>  		return 0;
>  
>  	ret = adp1653_init_device(flash);
> -	if (ret < 0)
> +	if (ret >= 0)
> +		return ret;
> +
> +	if (flash->platform_data->power)
>  		flash->platform_data->power(&flash->subdev, 0);
> +	else
> +		gpio_set_value(flash->platform_data->power_gpio, 0);
>  
>  	return ret;
>  }
> @@ -407,21 +423,77 @@ static int adp1653_resume(struct device *dev)
>  
>  #endif /* CONFIG_PM */
>  
> +static int adp1653_of_init(struct i2c_client *client,
> +			   struct adp1653_flash *flash,
> +			   struct device_node *node)
> +{
> +	u32 val;
> +	struct adp1653_platform_data *pd;
> +	enum of_gpio_flags flags;
> +	int gpio;
> +	struct device_node *child;
> +
> +	if (!node)
> +		return -EINVAL;
> +
> +	pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
> +	if (!pd)
> +		return -ENOMEM;
> +	flash->platform_data = pd;
> +
> +	child = of_get_child_by_name(node, "flash");
> +	if (!child)
> +		return -EINVAL;
> +	if (of_property_read_u32(child, "flash-timeout-microsec", &val))
> +		return -EINVAL;
> +
> +	pd->max_flash_timeout = val;
> +	if (of_property_read_u32(child, "flash-max-microamp", &val))
> +		return -EINVAL;
> +	pd->max_flash_intensity = val/1000;
> +
> +	if (of_property_read_u32(child, "max-microamp", &val))
> +		return -EINVAL;
> +	pd->max_torch_intensity = val/1000;
> +
> +	child = of_get_child_by_name(node, "indicator");
> +	if (!child)
> +		return -EINVAL;
> +	if (of_property_read_u32(child, "max-microamp", &val))
> +		return -EINVAL;
> +	pd->max_indicator_intensity = val;
> +
> +	if (!of_find_property(node, "gpios", NULL)) {
> +		dev_err(&client->dev, "No gpio node\n");
> +		return -EINVAL;
> +	}
> +
> +	pd->power_gpio = of_get_gpio_flags(node, 0, &flags);
> +	if (pd->power_gpio < 0) {
> +		dev_err(&client->dev, "Error getting GPIO\n");
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +
>  static int adp1653_probe(struct i2c_client *client,
>  			 const struct i2c_device_id *devid)
>  {
>  	struct adp1653_flash *flash;
>  	int ret;
>  
> -	/* we couldn't work without platform data */
> -	if (client->dev.platform_data == NULL)
> -		return -ENODEV;
> -
>  	flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
>  	if (flash == NULL)
>  		return -ENOMEM;
>  
>  	flash->platform_data = client->dev.platform_data;
> +	if (!flash->platform_data) {

I'd check whether dev->of_node is non-NULL instead.

> +		ret = adp1653_of_init(client, flash, client->dev.of_node);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	mutex_init(&flash->power_lock);
>  
> @@ -438,10 +510,10 @@ static int adp1653_probe(struct i2c_client *client,
>  		goto free_and_quit;
>  
>  	flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
> -

I rather liked the newline here. Please don't remove it. :-)

>  	return 0;
>  
>  free_and_quit:
> +	dev_err(&client->dev, "adp1653: failed to register device\n");
>  	v4l2_ctrl_handler_free(&flash->ctrls);
>  	return ret;
>  }
> @@ -464,7 +536,7 @@ static const struct i2c_device_id adp1653_id_table[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, adp1653_id_table);
>  
> -static struct dev_pm_ops adp1653_pm_ops = {
> +static const struct dev_pm_ops adp1653_pm_ops = {
>  	.suspend	= adp1653_suspend,
>  	.resume		= adp1653_resume,
>  };
>  
> 

A corresponding change to the N900 dts would be very nice.

I think you're missing change to adp1653_i2c_driver.driver.of_match_table.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

  reply	other threads:[~2015-04-02 16:15 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 14:38 [PATCHv3] media: i2c/adp1653: devicetree support for adp1653 Pavel Machek
2015-04-02 16:14 ` Sakari Ailus [this message]
2015-04-02 20:30   ` Pavel Machek
2015-04-02 23:48     ` Sakari Ailus
2015-04-03  8:23       ` Pavel Machek
2015-04-03 11:23         ` Sakari Ailus
2015-04-03 20:29           ` Pavel Machek
2015-04-03 21:35             ` Sakari Ailus
2015-04-02 20:34 ` [PATCHv4] " Pavel Machek
2015-04-02 22:18   ` Javier Martinez Canillas
2015-04-03  8:21     ` Pavel Machek
2015-04-03  8:49       ` Javier Martinez Canillas
2015-04-03 14:22         ` Sebastian Reichel
2015-04-03  8:33   ` [PATCHv5] " Pavel Machek
2015-04-03 11:32     ` Sakari Ailus
2015-04-03 20:26       ` [PATCHv6] media: i2c/adp1653: Documentation for " Pavel Machek
2015-04-03 21:36         ` Sakari Ailus
2015-04-04  7:43           ` Pavel Machek
2015-04-04 10:24             ` Sakari Ailus
2015-04-04 17:11               ` Pavel Machek
2015-04-04 20:03                 ` Sakari Ailus
2015-04-09  7:42                   ` [PATCHv7] media: i2c/adp1653: Devicetree " Pavel Machek
2015-04-09  9:10                     ` Sebastian Reichel
2015-04-09 11:29                       ` Pavel Machek
2015-04-09 12:19                         ` Sebastian Reichel
2015-04-09 12:31                           ` [PATCHv7] media: i2c/adp1653: fix includes Pavel Machek
2015-04-09 12:43                             ` Javier Martinez Canillas
2015-04-09 12:59                               ` Pali Rohár
2015-04-13  8:32                                 ` Javier Martinez Canillas
2015-04-09 21:47                     ` [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653 Sakari Ailus
2015-04-13 13:00                       ` Pavel Machek
2015-04-03 21:39         ` [PATCHv6] media: i2c/adp1653: Documentation for devicetree " Sakari Ailus
2015-04-03 21:04       ` [PATCHv5] media: i2c/adp1653: " Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2014-12-03 21:46 [PATCH] " Pavel Machek
2014-12-24 22:34 ` [PATCHv2] " Pavel Machek
2015-01-04  9:43   ` [PATCHv3] " Pavel Machek
2015-01-18 22:02     ` Pavel Machek

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=20150402161453.GH20756@valkosipuli.retiisi.org.uk \
    --to=sakari.ailus@iki.fi \
    --cc=aaro.koskinen@iki.fi \
    --cc=akpm@osdl.org \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=pali.rohar@gmail.com \
    --cc=patrikbachan@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=sre@debian.org \
    --cc=sre@ring0.de \
    --cc=tony@atomide.com \
    /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).