From: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] media: i2c: adv7343: fix the DT binding properties
Date: Fri, 20 Sep 2013 11:52:32 +0200 [thread overview]
Message-ID: <523C1AE0.9020603@samsung.com> (raw)
In-Reply-To: <CA+V-a8s3PYr7qem6m8au0E7N2Xb_gD37_8uLcdXZjeHppBaC6g@mail.gmail.com>
Hi Prabhakar,
On 09/20/2013 10:11 AM, Prabhakar Lad wrote:
> OK I will, just send out a fix up patch which fixes the mismatch between
> names for the rc-cycle, and later send out a patch which removes the
> platform data usage for next release with proper DT bindings.
I think the binding need to be fully corrected now, I just meant to not
touch the board file, i.e. leave non-dt support unchanged.
> I'm OK with making regulator properties as optional, But still it would
> change the meaning of what DT is, we know that the VDD/VDD_IO .. etc
> pins are required properties (but still making them as optional) :-(
>
> I think there might several devices where this situation may arise so
> just thinking of a alternative solution.
>
> say we have property 'software-regulator' which takes true/false(0/1)
> If set to true we make the regulators as required property or else we
> assume it is handled and ignore it ?
I don't think this is a good idea. You would have to add a similar platform
data flag for non-dt, it doesn't sound right. I can see two options here:
1. Make the regulator properties mandatory and, e.g. define a fixed
voltage GPIO regulator in DT with an empty 'gpio' property. Then
pass a phandle to that regulator in the adv7343 *-supply properties.
For non-dt similarly a fixed voltage regulator(s) and voltage
supplies would need to be defined in the board files.
2. Make the properties optional and use (devm_)regulator_get_optional()
calls in the driver (a recently added function). I must admit I don't
fully understand description of this function, it currently looks
pretty much same as (devm_)regulator_get(). Thus the driver would
need to be handling regulator supplies only when non ERR_PTR() is
returned from regulator_get_optional() and otherwise assume a non
critical error. There is already quite a few example occurrences of
regulator_get_optional() usage.
--
Regards,
Sylwester
WARNING: multiple messages have this Message-ID (diff)
From: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Prabhakar Lad <prabhakar.csengg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
DLOS
<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
LMML <linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LAK
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>,
LDOC <linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Hans Verkuil
<hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Subject: Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
Date: Fri, 20 Sep 2013 11:52:32 +0200 [thread overview]
Message-ID: <523C1AE0.9020603@samsung.com> (raw)
In-Reply-To: <CA+V-a8s3PYr7qem6m8au0E7N2Xb_gD37_8uLcdXZjeHppBaC6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Prabhakar,
On 09/20/2013 10:11 AM, Prabhakar Lad wrote:
> OK I will, just send out a fix up patch which fixes the mismatch between
> names for the rc-cycle, and later send out a patch which removes the
> platform data usage for next release with proper DT bindings.
I think the binding need to be fully corrected now, I just meant to not
touch the board file, i.e. leave non-dt support unchanged.
> I'm OK with making regulator properties as optional, But still it would
> change the meaning of what DT is, we know that the VDD/VDD_IO .. etc
> pins are required properties (but still making them as optional) :-(
>
> I think there might several devices where this situation may arise so
> just thinking of a alternative solution.
>
> say we have property 'software-regulator' which takes true/false(0/1)
> If set to true we make the regulators as required property or else we
> assume it is handled and ignore it ?
I don't think this is a good idea. You would have to add a similar platform
data flag for non-dt, it doesn't sound right. I can see two options here:
1. Make the regulator properties mandatory and, e.g. define a fixed
voltage GPIO regulator in DT with an empty 'gpio' property. Then
pass a phandle to that regulator in the adv7343 *-supply properties.
For non-dt similarly a fixed voltage regulator(s) and voltage
supplies would need to be defined in the board files.
2. Make the properties optional and use (devm_)regulator_get_optional()
calls in the driver (a recently added function). I must admit I don't
fully understand description of this function, it currently looks
pretty much same as (devm_)regulator_get(). Thus the driver would
need to be handling regulator supplies only when non ERR_PTR() is
returned from regulator_get_optional() and otherwise assume a non
critical error. There is already quite a few example occurrences of
regulator_get_optional() usage.
--
Regards,
Sylwester
--
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
next prev parent reply other threads:[~2013-09-20 9:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 11:57 [PATCH] media: i2c: adv7343: fix the DT binding properties Prabhakar Lad
2013-09-13 22:46 ` Stephen Warren
2013-09-13 22:46 ` Stephen Warren
2013-09-13 22:46 ` Stephen Warren
2013-09-14 5:23 ` Prabhakar Lad
2013-09-14 5:23 ` Prabhakar Lad
2013-09-14 5:23 ` Prabhakar Lad
2013-09-16 16:24 ` Stephen Warren
2013-09-16 16:24 ` Stephen Warren
2013-09-16 16:24 ` Stephen Warren
2013-09-19 16:06 ` Prabhakar Lad
2013-09-19 16:06 ` Prabhakar Lad
2013-09-19 19:49 ` Sylwester Nawrocki
2013-09-19 19:49 ` Sylwester Nawrocki
2013-09-20 8:11 ` Prabhakar Lad
2013-09-20 8:11 ` Prabhakar Lad
2013-09-20 9:52 ` Sylwester Nawrocki [this message]
2013-09-20 9:52 ` Sylwester Nawrocki
2013-09-23 2:48 ` Prabhakar Lad
2013-09-23 2:48 ` Prabhakar Lad
2013-09-23 11:50 ` Laurent Pinchart
2013-09-23 11:50 ` Laurent Pinchart
2013-09-23 21:33 ` Stephen Warren
2013-09-23 21:33 ` Stephen Warren
2013-09-24 6:15 ` Prabhakar Lad
2013-09-24 6:15 ` Prabhakar Lad
2013-09-24 9:44 ` Laurent Pinchart
2013-09-24 9:44 ` Laurent Pinchart
2013-09-24 15:52 ` Mark Brown
2013-09-24 15:52 ` Mark Brown
2013-09-24 15:54 ` Mark Brown
2013-09-24 15:54 ` Mark Brown
2013-09-30 13:27 ` Prabhakar Lad
2013-09-30 13:27 ` Prabhakar Lad
2013-09-30 13:27 ` Prabhakar Lad
2013-09-30 14:41 ` Laurent Pinchart
2013-09-30 14:41 ` Laurent Pinchart
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=523C1AE0.9020603@samsung.com \
--to=s.nawrocki@samsung.com \
--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 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.