Message ID | 20230429104534.28943-3-aweber.kernel@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1513257vqo; Sat, 29 Apr 2023 03:47:13 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ52t8eaO/xqmLX9bK0ABf3X/fjFWSbTvQJCVQ0WEPPs7r9yUoSgNhxesqbKbyUTk5kpHSCi X-Received: by 2002:a05:6a00:cd3:b0:63b:6d60:9a02 with SMTP id b19-20020a056a000cd300b0063b6d609a02mr11848086pfv.34.1682765233185; Sat, 29 Apr 2023 03:47:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682765233; cv=none; d=google.com; s=arc-20160816; b=zQzGDhsdObptkiH/S0Y1WBJRt0m21jOmTwouUGyaApxwzAi1wx0SzhywzOPZbY61Ft uSknZDUhsvmI1XTkkpb/Nio//S9uTv6FLLba+s3OFtsIQvPqDjFakdoPQw2M9VIfvsNQ 3pKP0BrBo6PzLO+UOx3INzUzAUhfZwmfKQunogskpFTmeswJLs5QPJPY9KEna0//cdrt oEpiODhWuE8m5BgLzSch/srXnI5uV+NYLR/PGSM6sBV1g6VFnhK3kOtiFsQNeFktoVgN oAeVkdlQv+U/2lY0z51OuDC8vBZyyNchvzkLdugQWUpPh7vQFOov/c+M2DF4C3gxZXag Qdzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=85dGX3BcJlsvsmIB6J26oSZoBGI3NIb+OIXm3X+ki1M=; b=NiOou5yFI6+N9QCZBGBpALoa81jU1Fx60l+R3Wkq19Bx1siSJDXj5DAs/Bk0Mo/4Ck x2tOeB3MQHLIdYotcXtKS78KnXdRmrdLbbhjBtlDqvPPr4+WqPRCgG6atpFh0rg1n+p6 2ha7rORj2TENF5zrkIokdDhk7soyGG33wbRjfigLtbv2ZEdUoaInNpLYMBhjD72r86I8 eERrH0nmh/RZUvifq0wNOxUZJuU14ZmwQLUQHltSHBELPNEBY0U0ABQHk5pQ/z1cvBN8 L6wJITac7yJym/ybNtxR3W8UFkpyQOTvxD+Eq8qDiy3UAIbChsE7y+mIpu/htmNCn4Be kUrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=SavQORTD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v10-20020a63610a000000b00528d90d40ddsi326661pgb.318.2023.04.29.03.47.01; Sat, 29 Apr 2023 03:47:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=SavQORTD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231259AbjD2KqE (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 99 others); Sat, 29 Apr 2023 06:46:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbjD2KqA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 29 Apr 2023 06:46:00 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7B481FCD; Sat, 29 Apr 2023 03:45:58 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-94f32588c13so115444266b.2; Sat, 29 Apr 2023 03:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682765157; x=1685357157; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=85dGX3BcJlsvsmIB6J26oSZoBGI3NIb+OIXm3X+ki1M=; b=SavQORTDBSYuMf4NYpgxnmvNWIzE5CKP433xtRUMTq7J/Q6oYvGzI2G07vovknCplW aKOMKbde1U6gPNSmEhbHyKLXhY3Yz1V6wTf55xiuGHClESIuGM4+Jp6CD7HlgR9fc4uM hpiD6zq9LOb2Z2Lv3J8miwjq0WhyybIk76uNwYF3Su3lCyRwK0O/j4xDX+Xbvbh62um7 oho9YD5G2iVO9Z16716wKfe28m9CC7jgPAS8OZpNYRuvdeId/8LJBRwOTdSeK0teBJbE UtzF7qNFdOJHeMHjcJaYkZwpGeyZuZuagXqS8sQNyVI27SI3f+CcOMWS4cvUytTtoqxM U8kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682765157; x=1685357157; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=85dGX3BcJlsvsmIB6J26oSZoBGI3NIb+OIXm3X+ki1M=; b=HMzUwZTSngxeGy53yv1K9FST9pUEV+vAlMGrPwXqJ95O5l8hD0kc/nLV2VXeJln4Ca pwwEYBUDT7swNpzQA+e9Qpl/3yCdN+efRlEXYBPzmkM0lVkzFpEdWD2CO23fjIAl/Qek lCtNIWl9D3MpR5r075iMRfzjLN34KVjdA5PUYeXWtRdUm7rMNNlp0pVm4Fj+eghpIU4Q e6UB0RS2GnHim0ydvvk2qQwCR1uP8uYCBsQH9EZpTri8gV9uYQT7N8Lb7T6PUN0//ZPM REyx5wv0AX//y+yZZAcbW5TGqmRPxaIYo5qPe+qkizfBDC03fAhxI+UM46QQ40m9sadt eD/A== X-Gm-Message-State: AC+VfDxQlD6FXaNPLikf9zSzrQSnjtTtf9UVdNC4JmlE3RtO75+54z40 mHMAUSJkINm5VpKuJEYuASE= X-Received: by 2002:a17:907:3e08:b0:94a:5c6d:3207 with SMTP id hp8-20020a1709073e0800b0094a5c6d3207mr7154482ejc.44.1682765157169; Sat, 29 Apr 2023 03:45:57 -0700 (PDT) Received: from localhost.my.domain (83.8.115.30.ipv4.supernova.orange.pl. [83.8.115.30]) by smtp.gmail.com with ESMTPSA id b11-20020a056402138b00b004bd6e3ed196sm9952522edv.86.2023.04.29.03.45.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Apr 2023 03:45:56 -0700 (PDT) From: Artur Weber <aweber.kernel@gmail.com> To: Lee Jones <lee@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org>, Jingoo Han <jingoohan1@gmail.com>, Pavel Machek <pavel@ucw.cz>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Thierry Reding <thierry.reding@gmail.com>, Jonathan Hunter <jonathanh@nvidia.com>, Helge Deller <deller@gmx.de>, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>, Artur Weber <aweber.kernel@gmail.com>, dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-pwm@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht Subject: [PATCH 2/4] video: backlight: lp855x: get PWM for PWM mode during probe Date: Sat, 29 Apr 2023 12:45:32 +0200 Message-Id: <20230429104534.28943-3-aweber.kernel@gmail.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20230429104534.28943-1-aweber.kernel@gmail.com> References: <20230429104534.28943-1-aweber.kernel@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764507237300843934?= X-GMAIL-MSGID: =?utf-8?q?1764507237300843934?= |
Series |
video: backlight: lp855x: modernize bindings
|
|
Commit Message
Artur Weber
April 29, 2023, 10:45 a.m. UTC
Also deprecate the pwm-period DT property, as it is now redundant
(pwms property already contains period value).
Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
---
drivers/video/backlight/lp855x_bl.c | 48 ++++++++++++++++-------------
1 file changed, 26 insertions(+), 22 deletions(-)
Comments
On Sat, Apr 29, 2023 at 12:45:32PM +0200, Artur Weber wrote: > Also deprecate the pwm-period DT property, as it is now redundant > (pwms property already contains period value). > > Signed-off-by: Artur Weber <aweber.kernel@gmail.com> > --- > drivers/video/backlight/lp855x_bl.c | 48 ++++++++++++++++------------- > 1 file changed, 26 insertions(+), 22 deletions(-) > > diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c > index 81012bf29baf..21eb4943ed56 100644 > --- a/drivers/video/backlight/lp855x_bl.c > +++ b/drivers/video/backlight/lp855x_bl.c > @@ -218,23 +218,10 @@ static int lp855x_configure(struct lp855x *lp) > > static void lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br) > { > - struct pwm_device *pwm; > struct pwm_state state; > > - /* request pwm device with the consumer name */ > - if (!lp->pwm) { > - pwm = devm_pwm_get(lp->dev, lp->chipname); > - if (IS_ERR(pwm)) > - return; > - > - lp->pwm = pwm; > - > - pwm_init_state(lp->pwm, &state); > - } else { > - pwm_get_state(lp->pwm, &state); > - } > + pwm_get_state(lp->pwm, &state); pwm_get_state returns an error code. Do you care if it fails? (You probably should.) > > - state.period = lp->pdata->period_ns; > state.duty_cycle = div_u64(br * state.period, max_br); > state.enabled = state.duty_cycle; > > @@ -339,6 +326,7 @@ static int lp855x_parse_dt(struct lp855x *lp) > of_property_read_string(node, "bl-name", &pdata->name); > of_property_read_u8(node, "dev-ctrl", &pdata->device_control); > of_property_read_u8(node, "init-brt", &pdata->initial_brightness); > + /* Deprecated, specify period in pwms property instead */ > of_property_read_u32(node, "pwm-period", &pdata->period_ns); > > /* Fill ROM platform data if defined */ > @@ -399,6 +387,7 @@ static int lp855x_probe(struct i2c_client *cl) > const struct i2c_device_id *id = i2c_client_get_device_id(cl); > const struct acpi_device_id *acpi_id = NULL; > struct device *dev = &cl->dev; > + struct pwm_state pwmstate; > struct lp855x *lp; > int ret; > > @@ -457,11 +446,6 @@ static int lp855x_probe(struct i2c_client *cl) > } > } > > - if (lp->pdata->period_ns > 0) > - lp->mode = PWM_BASED; > - else > - lp->mode = REGISTER_BASED; > - > lp->supply = devm_regulator_get(dev, "power"); > if (IS_ERR(lp->supply)) { > if (PTR_ERR(lp->supply) == -EPROBE_DEFER) > @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl) > lp->enable = devm_regulator_get_optional(dev, "enable"); > if (IS_ERR(lp->enable)) { > ret = PTR_ERR(lp->enable); > - if (ret == -ENODEV) { > + if (ret == -ENODEV) > lp->enable = NULL; > - } else { > + else > return dev_err_probe(dev, ret, "getting enable regulator\n"); > - } > + } > + > + lp->pwm = devm_pwm_get(lp->dev, lp->chipname); > + if (IS_ERR(lp->pwm)) { > + ret = PTR_ERR(lp->pwm); > + if (ret == -ENODEV || ret == -EINVAL) Why would you ignore EINVAL? > + lp->pwm = NULL; > + else > + return dev_err_probe(dev, ret, "getting PWM\n"); > + > + lp->mode = REGISTER_BASED; > + dev_dbg(dev, "mode: register based\n"); > + } else { pwmstate could be declared here. > + pwm_init_state(lp->pwm, &pwmstate); > + /* Legacy platform data compatibility */ > + if (lp->pdata->period_ns > 0) > + pwmstate.period = lp->pdata->period_ns; > + pwm_apply_state(lp->pwm, &pwmstate); This is a change in behaviour. Before lp855x_probe() didn't modify the state the bootloader left the backlight in. Now you're disabling it (I think). Is this intended? Best regards Uwe
On 14/06/2023 10:39, Uwe Kleine-König wrote: > On Sat, Apr 29, 2023 at 12:45:32PM +0200, Artur Weber wrote: >> Also deprecate the pwm-period DT property, as it is now redundant >> (pwms property already contains period value). >> >> Signed-off-by: Artur Weber <aweber.kernel@gmail.com> >> --- >> drivers/video/backlight/lp855x_bl.c | 48 ++++++++++++++++------------- >> 1 file changed, 26 insertions(+), 22 deletions(-) >> >> diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c >> index 81012bf29baf..21eb4943ed56 100644 >> --- a/drivers/video/backlight/lp855x_bl.c >> +++ b/drivers/video/backlight/lp855x_bl.c >> ... >> @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl) >> lp->enable = devm_regulator_get_optional(dev, "enable"); >> if (IS_ERR(lp->enable)) { >> ret = PTR_ERR(lp->enable); >> - if (ret == -ENODEV) { >> + if (ret == -ENODEV) >> lp->enable = NULL; >> - } else { >> + else >> return dev_err_probe(dev, ret, "getting enable regulator\n"); >> - } >> + } >> + >> + lp->pwm = devm_pwm_get(lp->dev, lp->chipname); >> + if (IS_ERR(lp->pwm)) { >> + ret = PTR_ERR(lp->pwm); >> + if (ret == -ENODEV || ret == -EINVAL) > > Why would you ignore EINVAL? EINVAL is returned when the pwms property is not found in the DT node for the backlight. Not sure if there's a better way of separately detecting whether it's present (especially when taking into consideration non-DT platforms that might use the driver). Would be nice to have something like devm_regulator_get_optional but for PWMs... Still, someone who's setting up the driver could check the debug messages to see if the backlight was set up in PWM mode or register mode. > ... >> + pwm_init_state(lp->pwm, &pwmstate); >> + /* Legacy platform data compatibility */ >> + if (lp->pdata->period_ns > 0) >> + pwmstate.period = lp->pdata->period_ns; >> + pwm_apply_state(lp->pwm, &pwmstate); > > This is a change in behaviour. Before lp855x_probe() didn't modify the > state the bootloader left the backlight in. Now you're disabling it (I > think). Is this intended? I didn't really consider the implication of this in this way, as on the device I was testing this on (Exynos4212-based tablet) the PWM state would get reset during PWM chip initialization in the kernel anyways, meaning that the state from the bootloader would be lost regardless of this change. Either way, there's no guarantee that this would be the same on other devices, though I'd assume that in most cases it's not noticeable anyways as brightness is usually set somewhere in userspace (or even earlier, in the driver, if the init-brt property is set). Nonetheless, that's an oversight on my part. As for the reasoning for this change in behavior - the previous behavior was to silently fail if, while setting the brightness, the PWM could not be set up. This seemed rather confusing to me (I encountered this while I was initially working on the tablet, I added a "pwm" property instead of "pwms" and was wondering why the backlight didn't work...) Of course, that could be fixed by adding error detection in the brightness set function, but since I was already working on it, it made more sense to me for the PWM to be set up during the probing process, given that this way we could 1. warn about errors early, and 2. catch deferred probes and defer the backlight's probe if we're still waiting for the PWM. That's why it's done the way it is in this patch. If this is undesired behavior, let me know and I'll submit another patch to revert it. Best regards Artur
Hello, On Fri, Jun 16, 2023 at 05:29:08PM +0200, Artur Weber wrote: > On 14/06/2023 10:39, Uwe Kleine-König wrote: > > On Sat, Apr 29, 2023 at 12:45:32PM +0200, Artur Weber wrote: > >> Also deprecate the pwm-period DT property, as it is now redundant > >> (pwms property already contains period value). > >> > >> Signed-off-by: Artur Weber <aweber.kernel@gmail.com> > >> --- > >> drivers/video/backlight/lp855x_bl.c | 48 ++++++++++++++++------------- > >> 1 file changed, 26 insertions(+), 22 deletions(-) > >> > >> diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c > >> index 81012bf29baf..21eb4943ed56 100644 > >> --- a/drivers/video/backlight/lp855x_bl.c > >> +++ b/drivers/video/backlight/lp855x_bl.c > >> ... > >> @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl) > >> lp->enable = devm_regulator_get_optional(dev, "enable"); > >> if (IS_ERR(lp->enable)) { > >> ret = PTR_ERR(lp->enable); > >> - if (ret == -ENODEV) { > >> + if (ret == -ENODEV) > >> lp->enable = NULL; > >> - } else { > >> + else > >> return dev_err_probe(dev, ret, "getting enable regulator\n"); > >> - } > >> + } > >> + > >> + lp->pwm = devm_pwm_get(lp->dev, lp->chipname); > >> + if (IS_ERR(lp->pwm)) { > >> + ret = PTR_ERR(lp->pwm); > >> + if (ret == -ENODEV || ret == -EINVAL) > > > > Why would you ignore EINVAL? > > EINVAL is returned when the pwms property is not found in the DT node > for the backlight. Not sure if there's a better way of separately > detecting whether it's present (especially when taking into > consideration non-DT platforms that might use the driver). Would be nice > to have something like devm_regulator_get_optional but for PWMs... Ah, that is because of_pwm_get() calls of_property_match_string(np, "pwm-names", con_id) which returns -EINVAL if there is no pwm-names property. This is different for clocks. I wonder if pwm should adapt accordingly? Thierry? > Still, someone who's setting up the driver could check the debug > messages to see if the backlight was set up in PWM mode or register mode. > > > ... > >> + pwm_init_state(lp->pwm, &pwmstate); > >> + /* Legacy platform data compatibility */ > >> + if (lp->pdata->period_ns > 0) > >> + pwmstate.period = lp->pdata->period_ns; > >> + pwm_apply_state(lp->pwm, &pwmstate); > > > > This is a change in behaviour. Before lp855x_probe() didn't modify the > > state the bootloader left the backlight in. Now you're disabling it (I > > think). Is this intended? > > I didn't really consider the implication of this in this way, as on the > device I was testing this on (Exynos4212-based tablet) the PWM state > would get reset during PWM chip initialization in the kernel anyways, Which chip driver is in use here? That's a patch opportunity. > meaning that the state from the bootloader would be lost regardless of > this change. Either way, there's no guarantee that this would be the > same on other devices, though I'd assume that in most cases it's not > noticeable anyways as brightness is usually set somewhere in userspace > (or even earlier, in the driver, if the init-brt property is set). > Nonetheless, that's an oversight on my part. > > As for the reasoning for this change in behavior - the previous behavior > was to silently fail if, while setting the brightness, the PWM could not This sounds wrong. > be set up. This seemed rather confusing to me (I encountered this while > I was initially working on the tablet, I added a "pwm" property instead > of "pwms" and was wondering why the backlight didn't work...) > > Of course, that could be fixed by adding error detection in the > brightness set function, but since I was already working on it, it made > more sense to me for the PWM to be set up during the probing process, > given that this way we could 1. warn about errors early, and 2. catch > deferred probes and defer the backlight's probe if we're still waiting > for the PWM. That's why it's done the way it is in this patch. > > If this is undesired behavior, let me know and I'll submit another patch > to revert it. Best regards Uwe
diff --git a/drivers/video/backlight/lp855x_bl.c b/drivers/video/backlight/lp855x_bl.c index 81012bf29baf..21eb4943ed56 100644 --- a/drivers/video/backlight/lp855x_bl.c +++ b/drivers/video/backlight/lp855x_bl.c @@ -218,23 +218,10 @@ static int lp855x_configure(struct lp855x *lp) static void lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br) { - struct pwm_device *pwm; struct pwm_state state; - /* request pwm device with the consumer name */ - if (!lp->pwm) { - pwm = devm_pwm_get(lp->dev, lp->chipname); - if (IS_ERR(pwm)) - return; - - lp->pwm = pwm; - - pwm_init_state(lp->pwm, &state); - } else { - pwm_get_state(lp->pwm, &state); - } + pwm_get_state(lp->pwm, &state); - state.period = lp->pdata->period_ns; state.duty_cycle = div_u64(br * state.period, max_br); state.enabled = state.duty_cycle; @@ -339,6 +326,7 @@ static int lp855x_parse_dt(struct lp855x *lp) of_property_read_string(node, "bl-name", &pdata->name); of_property_read_u8(node, "dev-ctrl", &pdata->device_control); of_property_read_u8(node, "init-brt", &pdata->initial_brightness); + /* Deprecated, specify period in pwms property instead */ of_property_read_u32(node, "pwm-period", &pdata->period_ns); /* Fill ROM platform data if defined */ @@ -399,6 +387,7 @@ static int lp855x_probe(struct i2c_client *cl) const struct i2c_device_id *id = i2c_client_get_device_id(cl); const struct acpi_device_id *acpi_id = NULL; struct device *dev = &cl->dev; + struct pwm_state pwmstate; struct lp855x *lp; int ret; @@ -457,11 +446,6 @@ static int lp855x_probe(struct i2c_client *cl) } } - if (lp->pdata->period_ns > 0) - lp->mode = PWM_BASED; - else - lp->mode = REGISTER_BASED; - lp->supply = devm_regulator_get(dev, "power"); if (IS_ERR(lp->supply)) { if (PTR_ERR(lp->supply) == -EPROBE_DEFER) @@ -472,11 +456,31 @@ static int lp855x_probe(struct i2c_client *cl) lp->enable = devm_regulator_get_optional(dev, "enable"); if (IS_ERR(lp->enable)) { ret = PTR_ERR(lp->enable); - if (ret == -ENODEV) { + if (ret == -ENODEV) lp->enable = NULL; - } else { + else return dev_err_probe(dev, ret, "getting enable regulator\n"); - } + } + + lp->pwm = devm_pwm_get(lp->dev, lp->chipname); + if (IS_ERR(lp->pwm)) { + ret = PTR_ERR(lp->pwm); + if (ret == -ENODEV || ret == -EINVAL) + lp->pwm = NULL; + else + return dev_err_probe(dev, ret, "getting PWM\n"); + + lp->mode = REGISTER_BASED; + dev_dbg(dev, "mode: register based\n"); + } else { + pwm_init_state(lp->pwm, &pwmstate); + /* Legacy platform data compatibility */ + if (lp->pdata->period_ns > 0) + pwmstate.period = lp->pdata->period_ns; + pwm_apply_state(lp->pwm, &pwmstate); + + lp->mode = PWM_BASED; + dev_dbg(dev, "mode: PWM based\n"); } if (lp->supply) {