From: Dan Murphy <dmurphy@ti.com>
To: Brian Masney <masneyb@onstation.org>,
lee.jones@linaro.org, daniel.thompson@linaro.org,
jingoohan1@gmail.com, robh+dt@kernel.org
Cc: jacek.anaszewski@gmail.com, pavel@ucw.cz, mark.rutland@arm.com,
b.zolnierkie@samsung.com, dri-devel@lists.freedesktop.org,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
jonathan@marek.ca
Subject: Re: [PATCH v2 3/3] backlight: lm3630a: add device tree supprt
Date: Tue, 2 Apr 2019 08:45:40 -0500 [thread overview]
Message-ID: <7bcd94ee-a4f8-c91b-697d-cc4c6337ec88@ti.com> (raw)
In-Reply-To: <20190401103034.21062-4-masneyb@onstation.org>
Hello
On 4/1/19 5:30 AM, Brian Masney wrote:
> Add device tree support to the lm3630a driver and allow configuring
> independently on both banks the mapping mode (linear or exponential),
> initial and maximum LED brightness.
>
> Driver was tested on a LG Nexus 5 (hammerhead) phone.
>
Don't need this in the commit message.
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> ---
> drivers/video/backlight/lm3630a_bl.c | 69 ++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
> index ef2553f452ca..96fbc1273dda 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -35,6 +35,9 @@
> #define REG_MAX 0x50
>
> #define INT_DEBOUNCE_MSEC 10
> +
> +#define LM3630A_MAX_SOURCES 2
> +
> struct lm3630a_chip {
> struct device *dev;
> struct delayed_work work;
> @@ -364,6 +367,64 @@ static const struct regmap_config lm3630a_regmap = {
> .max_register = REG_MAX,
> };
>
> +static void lm3630a_parse_dt(struct lm3630a_chip *pchip)
> +{
> + u32 sources[LM3630A_MAX_SOURCES], val;
> + struct device_node *child_node;
> + int num_sources, ret, i;
> + bool linear;
> +
> + for_each_available_child_of_node(pchip->dev->of_node, child_node) {
I would prefer we use fwnode api's.
See lm3532 patch submission for example
https://lore.kernel.org/patchwork/patch/1053132/
> + num_sources = of_property_count_u32_elems(child_node,
> + "led-sources");
> + if (num_sources < 0)
> + continue;
> +
Not sure what this is checking here. Wondering if you should return an error here instead.
> + if (num_sources > LM3630A_MAX_SOURCES)
> + num_sources = LM3630A_MAX_SOURCES;
> +
If num_sources is greater than max should we not log and return an error?
Why does the driver fix a malformed property?
> + ret = of_property_read_u32_array(child_node, "led-sources",
> + sources, num_sources);
> + if (ret) {
> + dev_err(pchip->dev,
> + "Error parsing led-sources node: %d\n", ret);
> + return;
We should return an error here see comment below on the order of operation pdata->dt->default parameters.
> + }
> +
> + linear = of_property_read_bool(child_node,
> + "ti,linear-mapping-mode");
> +
> + for (i = 0; i < num_sources; i++) {
If the reg property is used to determine control bank then this for..loop may be eliminated
> + if (sources[i] == 0)
> + pchip->pdata->leda_ctrl = linear ?
> + LM3630A_LEDA_ENABLE_LINEAR :
> + LM3630A_LEDA_ENABLE;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_ctrl = linear ?
> + LM3630A_LEDB_ENABLE_LINEAR :
> + LM3630A_LEDB_ENABLE;
> +
> + ret = of_property_read_u32(child_node,
> + "default-brightness", &val);
> + if (!ret) {
> + if (sources[i] == 0)
> + pchip->pdata->leda_init_brt = val;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_init_brt = val;
> + }
> +
> + ret = of_property_read_u32(child_node, "max-brightness",
> + &val);
> + if (!ret) {
> + if (sources[i] == 0)
> + pchip->pdata->leda_max_brt = val;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_max_brt = val;
> + }
> + }
> + };
> +}
> +
> static int lm3630a_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -405,6 +466,7 @@ static int lm3630a_probe(struct i2c_client *client,
> pdata->ledb_init_brt = LM3630A_MAX_BRIGHTNESS;
> }
> pchip->pdata = pdata;
> + lm3630a_parse_dt(pchip);
>
Hmm. Wondering if this should be in the if (pdata == NULL) case and if parsing the
node fails then set defaults.
Because the way it is written if pdata is null then all the defaults are set then the dt parsing
overwrites the data.
Not sure if thats what you intended.
Dan
> /* chip initialize */
> rval = lm3630a_chip_init(pchip);
> @@ -470,11 +532,18 @@ static const struct i2c_device_id lm3630a_id[] = {
> {}
> };
>
> +static const struct of_device_id lm3630a_match_table[] = {
> + { .compatible = "ti,lm3630a", },
> + { },
> +};
> +
> +
> MODULE_DEVICE_TABLE(i2c, lm3630a_id);
>
> static struct i2c_driver lm3630a_i2c_driver = {
> .driver = {
> .name = LM3630A_NAME,
> + .of_match_table = lm3630a_match_table,
> },
> .probe = lm3630a_probe,
> .remove = lm3630a_remove,
>
--
------------------
Dan Murphy
next prev parent reply other threads:[~2019-04-02 13:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 10:30 [PATCH v2 0/3] backlight: lm3630a: bug fix and device tree support Brian Masney
2019-04-01 10:30 ` [PATCH v2 1/3] backlight: lm3630a: return 0 on success in update_status functions Brian Masney
2019-04-01 21:34 ` Pavel Machek
2019-04-01 10:30 ` [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings Brian Masney
2019-04-01 21:39 ` Pavel Machek
2019-04-01 23:04 ` Brian Masney
2019-04-02 12:56 ` Dan Murphy
2019-04-02 13:24 ` Brian Masney
2019-04-02 13:44 ` Dan Murphy
2019-04-07 11:28 ` Brian Masney
2019-04-03 1:50 ` Rob Herring
2019-04-01 10:30 ` [PATCH v2 3/3] backlight: lm3630a: add device tree supprt Brian Masney
2019-04-01 21:48 ` Pavel Machek
2019-04-02 0:02 ` Brian Masney
2019-04-02 13:45 ` Dan Murphy [this message]
2019-04-02 16:45 ` Pavel Machek
2019-04-02 17:07 ` Dan Murphy
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=7bcd94ee-a4f8-c91b-697d-cc4c6337ec88@ti.com \
--to=dmurphy@ti.com \
--cc=b.zolnierkie@samsung.com \
--cc=daniel.thompson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.anaszewski@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=jonathan@marek.ca \
--cc=lee.jones@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masneyb@onstation.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.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).