All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Sakari Ailus <sakari.ailus@iki.fi>
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 22:30:44 +0200	[thread overview]
Message-ID: <20150402203043.GB29963@amd> (raw)
In-Reply-To: <20150402161453.GH20756@valkosipuli.retiisi.org.uk>

Hi!

> 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

Well.. Being busy is ok. Nitpicking is also ok. But both at the same
time... is not good. 

> > 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.
> 

> > +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.

I'd rather not: when you make a typo in dts, it would supply maximum
available current, potentially damaging the LED. You will not be able
to tell brightness difference with naked eye...

> >  __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.

I'd prefer to do it later; we want to keep functionality on N900
without DTS, too.

> >  	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.

Ok.

> > @@ -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. :-)

Ok.

> > @@ -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.

Corresponding change to the dts will come in separate patch. Or do you
have n900 for testing?

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

It actually worked for me, which means device tree somehow does it
magic.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Cc: Andrew Morton <akpm-3NddpPZAyC0@public.gmane.org>,
	pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org,
	sre-GFxCN5SEZAc@public.gmane.org,
	kernel list
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-arm-kernel
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
	khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	aaro.koskinen-X3B1VOXEql0@public.gmane.org,
	ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	patrikbachan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
	m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
Date: Thu, 2 Apr 2015 22:30:44 +0200	[thread overview]
Message-ID: <20150402203043.GB29963@amd> (raw)
In-Reply-To: <20150402161453.GH20756-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>

Hi!

> 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-+ZI9xUNit7I@public.gmane.org>
> > 
> > ---
> > 
> > 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

Well.. Being busy is ok. Nitpicking is also ok. But both at the same
time... is not good. 

> > 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.
> 

> > +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.

I'd rather not: when you make a typo in dts, it would supply maximum
available current, potentially damaging the LED. You will not be able
to tell brightness difference with naked eye...

> >  __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.

I'd prefer to do it later; we want to keep functionality on N900
without DTS, too.

> >  	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.

Ok.

> > @@ -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. :-)

Ok.

> > @@ -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.

Corresponding change to the dts will come in separate patch. Or do you
have n900 for testing?

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

It actually worked for me, which means device tree somehow does it
magic.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
Date: Thu, 2 Apr 2015 22:30:44 +0200	[thread overview]
Message-ID: <20150402203043.GB29963@amd> (raw)
In-Reply-To: <20150402161453.GH20756@valkosipuli.retiisi.org.uk>

Hi!

> 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

Well.. Being busy is ok. Nitpicking is also ok. But both at the same
time... is not good. 

> > 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.
> 

> > +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.

I'd rather not: when you make a typo in dts, it would supply maximum
available current, potentially damaging the LED. You will not be able
to tell brightness difference with naked eye...

> >  __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.

I'd prefer to do it later; we want to keep functionality on N900
without DTS, too.

> >  	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.

Ok.

> > @@ -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. :-)

Ok.

> > @@ -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.

Corresponding change to the dts will come in separate patch. Or do you
have n900 for testing?

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

It actually worked for me, which means device tree somehow does it
magic.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2015-04-02 20:30 UTC|newest]

Thread overview: 86+ 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 14:38 ` Pavel Machek
2015-04-02 16:14 ` Sakari Ailus
2015-04-02 16:14   ` Sakari Ailus
2015-04-02 16:14   ` Sakari Ailus
2015-04-02 20:30   ` Pavel Machek [this message]
2015-04-02 20:30     ` Pavel Machek
2015-04-02 20:30     ` Pavel Machek
2015-04-02 23:48     ` Sakari Ailus
2015-04-02 23:48       ` Sakari Ailus
2015-04-02 23:48       ` Sakari Ailus
2015-04-03  8:23       ` Pavel Machek
2015-04-03  8:23         ` Pavel Machek
2015-04-03 11:23         ` Sakari Ailus
2015-04-03 11:23           ` Sakari Ailus
2015-04-03 11:23           ` Sakari Ailus
2015-04-03 20:29           ` Pavel Machek
2015-04-03 20:29             ` Pavel Machek
2015-04-03 21:35             ` Sakari Ailus
2015-04-03 21:35               ` Sakari Ailus
2015-04-02 20:34 ` [PATCHv4] " Pavel Machek
2015-04-02 20:34   ` Pavel Machek
2015-04-02 20:34   ` Pavel Machek
2015-04-02 22:18   ` Javier Martinez Canillas
2015-04-02 22:18     ` Javier Martinez Canillas
2015-04-03  8:21     ` Pavel Machek
2015-04-03  8:21       ` Pavel Machek
2015-04-03  8:21       ` Pavel Machek
2015-04-03  8:49       ` Javier Martinez Canillas
2015-04-03  8:49         ` Javier Martinez Canillas
2015-04-03 14:22         ` Sebastian Reichel
2015-04-03 14:22           ` Sebastian Reichel
2015-04-03  8:33   ` [PATCHv5] " Pavel Machek
2015-04-03  8:33     ` Pavel Machek
2015-04-03 11:32     ` Sakari Ailus
2015-04-03 11:32       ` Sakari Ailus
2015-04-03 20:26       ` [PATCHv6] media: i2c/adp1653: Documentation for " Pavel Machek
2015-04-03 20:26         ` Pavel Machek
2015-04-03 21:36         ` Sakari Ailus
2015-04-03 21:36           ` Sakari Ailus
2015-04-04  7:43           ` Pavel Machek
2015-04-04  7:43             ` Pavel Machek
2015-04-04 10:24             ` Sakari Ailus
2015-04-04 10:24               ` Sakari Ailus
2015-04-04 10:24               ` Sakari Ailus
2015-04-04 17:11               ` Pavel Machek
2015-04-04 17:11                 ` Pavel Machek
2015-04-04 17:11                 ` Pavel Machek
2015-04-04 20:03                 ` Sakari Ailus
2015-04-04 20:03                   ` Sakari Ailus
2015-04-04 20:03                   ` Sakari Ailus
2015-04-09  7:42                   ` [PATCHv7] media: i2c/adp1653: Devicetree " Pavel Machek
2015-04-09  7:42                     ` Pavel Machek
2015-04-09  9:10                     ` Sebastian Reichel
2015-04-09  9:10                       ` Sebastian Reichel
2015-04-09  9:10                       ` Sebastian Reichel
2015-04-09 11:29                       ` Pavel Machek
2015-04-09 11:29                         ` Pavel Machek
2015-04-09 12:19                         ` Sebastian Reichel
2015-04-09 12:19                           ` Sebastian Reichel
2015-04-09 12:19                           ` Sebastian Reichel
2015-04-09 12:31                           ` [PATCHv7] media: i2c/adp1653: fix includes Pavel Machek
2015-04-09 12:31                             ` Pavel Machek
2015-04-09 12:31                             ` Pavel Machek
2015-04-09 12:43                             ` Javier Martinez Canillas
2015-04-09 12:43                               ` Javier Martinez Canillas
2015-04-09 12:59                               ` Pali Rohár
2015-04-09 12:59                                 ` Pali Rohár
2015-04-09 12:59                                 ` Pali Rohár
2015-04-13  8:32                                 ` Javier Martinez Canillas
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-09 21:47                       ` Sakari Ailus
2015-04-13 13:00                       ` Pavel Machek
2015-04-13 13:00                         ` Pavel Machek
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:39           ` Sakari Ailus
2015-04-03 21:39           ` Sakari Ailus
2015-04-03 21:04       ` [PATCHv5] media: i2c/adp1653: " Pavel Machek
2015-04-03 21:04         ` Pavel Machek
2015-04-03 21:04         ` 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-04  9:43     ` Pavel Machek
2015-01-18 22:02     ` 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=20150402203043.GB29963@amd \
    --to=pavel@ucw.cz \
    --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=sakari.ailus@iki.fi \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.