linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653
Date: Sun, 4 Jan 2015 10:00:36 +0100	[thread overview]
Message-ID: <20150104090036.GA30683@amd> (raw)
In-Reply-To: <20141230135701.GN17565@valkosipuli.retiisi.org.uk>

Hi!

> Thanks for the patch! A few comments below.
> 
> On Wed, Dec 24, 2014 at 11:34:34PM +0100, 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>
> > 
> > ---
> > 
> > Changed -microsec to -us, as requested by devicetree people.
> > 
> > Fixed checkpatch issues.
> > 
> > diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> > index 2d88816..2c6c7c5 100644
> > --- a/Documentation/devicetree/bindings/leds/common.txt
> > +++ b/Documentation/devicetree/bindings/leds/common.txt
> > @@ -14,6 +14,15 @@ Optional properties for child nodes:
> >       "ide-disk" - LED indicates disk activity
> >       "timer" - LED flashes at a fixed, configurable rate
> >  
> > +- max-microamp : maximum intensity in microamperes of the LED
> > +	         (torch LED for flash devices)
> 
> s/torch LED/torch mode/
> 
> > +- flash-max-microamp : maximum intensity in microamperes of the
> > +                       flash LED; it is mandatory if the LED should
> > +		       support the flash mode
> > +- flash-timeout-microsec : timeout in microseconds after which the flash
> > +                           LED is turned off
> 
> These should go to a different patch.

Actually these both should not be in this patch in the first place.

> > +  - 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".
> 
> 80 characters per line.

Count them. It is.

> > +
> > +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
> > +
> > +Example:
> > +
> > +        adp1653: led-controller at 30 {
> > +                compatible = "adi,adp1653";
> > +		reg = <0x30>;
> > +                gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>; /* 88 */
> 
> Please use tabs for indentation above (and below).

Ok.

> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -553,6 +558,22 @@
> >  
> >  		ti,usb-charger-detection = <&isp1704>;
> >  	};
> > +
> > +	adp1653: led-controller at 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>;
> > +		};
> > +	};
> 
> This should go to a separate patch as well.

How many patches do I need to do for one trivial change? :-(.


> > +	if (flash->platform_data->power)
> > +		ret = flash->platform_data->power(&flash->subdev, on);
> 
> if () {
> } else {
> }

Ok.

> > +	else {
> > +		gpio_set_value(flash->platform_data->power_gpio, on);
> 
> Shouldn't you add this to the platform data struct?

I don't see what you mean.

> power_gpio is actually a poor name for this, as is the "power" callback.
> This is really "EN" gpio in the spec, I'd call it perhaps just "gpio", or
> "enable_gpio".

Feel free to clean that that up in followup patch.

> > +		if (on) {
> > +			/* Some delay is apparently required. */
> > +			udelay(20);
> 
> The driver should always handle the delay, platform data or not. This
> reminds me --- is there a need to retain the support for platform data? I
> don't think it's being used anywhere. I'm fine with both keeping and
> removing it.

Lets do that in followup patch, if needed.

> > +	child = of_get_child_by_name(node, "indicator");
> > +	if (!child)
> > +		return -EINVAL;
> 
> Do you require an indicator to be connected? I think it shouldn't be
> mandatory, at least the driver should work without it, even if it
> exposes
> the control (making that conditional would be a subject for another patch,
> but that doesn't need to be done now).

Another patch, if someone needs it, yes.	

> > +	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;
> > +	}
> > +
> > +	gpio = of_get_gpio_flags(node, 0, &flags);
> 
> You could assign to pd->... here.

Ok.
								Pavel

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

  reply	other threads:[~2015-01-04  9:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 21:46 [PATCH] media: i2c/adp1653: devicetree support for adp1653 Pavel Machek
2014-12-23 17:23 ` Mauro Carvalho Chehab
2014-12-23 20:49   ` Pavel Machek
2014-12-24 22:35     ` Pavel Machek
2014-12-24 22:34 ` [PATCHv2] " Pavel Machek
2014-12-26 19:02   ` Rob Herring
2014-12-26 20:33     ` Pavel Machek
2014-12-26 20:52       ` Rob Herring
2014-12-30 13:57   ` Sakari Ailus
2015-01-04  9:00     ` Pavel Machek [this message]
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=20150104090036.GA30683@amd \
    --to=pavel@ucw.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).