Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp883318ybg; Fri, 18 Oct 2019 08:45:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+pSAsBBc9T0uqVCJltl7PjSMuDrnBOQcUeGMq2btDJrgQ+giQG4AkgYtj4CPmuz3W4+Xa X-Received: by 2002:aa7:ce8c:: with SMTP id y12mr10273011edv.171.1571413543381; Fri, 18 Oct 2019 08:45:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571413543; cv=none; d=google.com; s=arc-20160816; b=KKnShQigyiBpEIKmO33qeS/L+g7fbaZFxhrQcR/wKvRJKMjxQkxOqhVWc+VsTsPbJz Qx2DnVlTEyjQBboDmntGvyg9emMWV7yOapMjP6dxYbQezEiy8kGjTjO32ONCjNKsy75Y HCTWIVyhbpCF41C2MnIZihH7wZOBhzBSBIQgI/8yUQ/ZdUsT+AztV9VgLIgqOnu+Hvb1 PO+DzIX3oYnX/OPJbeU4qSIl36TSohugsD/dpT5GJW6TffxHwLR4N+sMwAFZGbtgdPD9 vwDy50TwVWTiLyfe/mB1g4pG1KRj8Js1yLoZYxVFjwFu30kyWsOl53Bcd6WVmD+v6Ka5 NZ+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=e5PXvkJj6yLgLLpU0V58xaLs23PCozUwXaPXAmVU3f0=; b=Gv9ZyQDkTdaG7dxQIUc2rpeHOknYixgZsZtOrX1U7+a24BeDFtBHr9Ouwc9Hu+XN2l CbhLXmYA7MwS/g9+l4qneKsf7Udr7/tnjDnQTHfImJnY2nS4dRPhUhRCY5lqYPHEnbAy 8BGq3vATejkUetKvDbflgADivt4elh3ki/N/3BdNkW4kFB/JTFk9il9wENMxFGRaRto8 1O8wy+sxcebxq92piWrOIUKJLpRid5gC8mvUi0s711fjYKPCP2b+7m7RNPWn/t4xCk1N qepTdX0kQJjYHNb5aEBRXJnuRrLPskOOmmpFfh1uwK4NWcujFINxu31X0nFImaOQ9+uh Kvaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="M2+1Qx/D"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id sb7si3449741ejb.321.2019.10.18.08.45.19; Fri, 18 Oct 2019 08:45:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="M2+1Qx/D"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409383AbfJQM1B (ORCPT + 99 others); Thu, 17 Oct 2019 08:27:01 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:38628 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406225AbfJQM1A (ORCPT ); Thu, 17 Oct 2019 08:27:00 -0400 Received: by mail-wr1-f67.google.com with SMTP id o15so1699843wru.5 for ; Thu, 17 Oct 2019 05:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=e5PXvkJj6yLgLLpU0V58xaLs23PCozUwXaPXAmVU3f0=; b=M2+1Qx/DuhYBuThmcJfx5JfLuZjkWpvQDesjuHxTZhU9PtIHUdL/6uku69PjxWiFS0 izL2XiCoH8HlOCBoynrQsmJWHBCw2SxY7rXrVVH3yHulOIoF5CTvk6jXRZDSkn1W0qoC k4Z69DTZEC67KFn2mZmNGzRgt6tQw9k3d6LS5FXJN3jRbM6AGkE/OvAkDLMb74TMFKOj gkoAVRzzD7B40WH5J7S+jxmQieTt7TFSP+3DVU4vkDWXslo+sopj8M1Oi3kXFP8zGgbl 81dAGokpcP2vQZw8NSMLOE2+TelgnrLf8l2oA/HZz4dsNrw+ExOotvKGCPKa4DSehi/B izBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=e5PXvkJj6yLgLLpU0V58xaLs23PCozUwXaPXAmVU3f0=; b=fp6doFJ/JahaK/EJpPv0O99VBqUBNGu4c9qoLVk38RaUk9GeqrueKqTJhM4ke7lLg1 Ji1RshCVau2lJmyN1rnhVCMsmwhXwE3tWYnr6T7CkyQvKIgaBGD+xUivUiG7FX2uy50S ozA4Ug7jqZLrnuy68q6SSu+biOu8k5TxKw4pTMzzxQDdKeKbjUrd/vhg1l71ulbTN7vm 57jSVQaySOGip783rz0P5cDfqFv0wxbA8BR+bTsbBT/1vnDZjL1Il6iULyRYxdpFWwIR RO6I72Fr3FJ3ky3yA6PSSo73p/I77uK+cP8XCk2pbhHWI6mMRtMKYCcIHm/hk4ULcVuo 2PQg== X-Gm-Message-State: APjAAAUtMXgyQy73BAB8MqEL9dU8Wue1j4CotuwZBJ4Jv6G2OiBuX9Xe 6xA7xDxqXuBDFntIK7wyMHM7IA== X-Received: by 2002:adf:a157:: with SMTP id r23mr2691445wrr.51.1571315215846; Thu, 17 Oct 2019 05:26:55 -0700 (PDT) Received: from dell ([95.149.164.47]) by smtp.gmail.com with ESMTPSA id o22sm2299542wra.96.2019.10.17.05.26.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Oct 2019 05:26:55 -0700 (PDT) Date: Thu, 17 Oct 2019 13:26:53 +0100 From: Lee Jones To: Kiran Gunda Cc: bjorn.andersson@linaro.org, jingoohan1@gmail.com, b.zolnierkie@samsung.com, dri-devel@lists.freedesktop.org, daniel.thompson@linaro.org, jacek.anaszewski@gmail.com, pavel@ucw.cz, robh+dt@kernel.org, mark.rutland@arm.com, linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Gross , linux-arm-msm@vger.kernel.org, linux-fbdev@vger.kernel.org Subject: Re: [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic Message-ID: <20191017122653.GO4365@dell> References: <1571220826-7740-1-git-send-email-kgunda@codeaurora.org> <1571220826-7740-7-git-send-email-kgunda@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1571220826-7740-7-git-send-email-kgunda@codeaurora.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Oct 2019, Kiran Gunda wrote: > The auto string detection algorithm checks if the current WLED > sink configuration is valid. It tries enabling every sink and > checks if the OVP fault is observed. Based on this information > it detects and enables the valid sink configuration. > Auto calibration will be triggered when the OVP fault interrupts > are seen frequently thereby it tries to fix the sink configuration. > > The auto-detection also kicks in when the connected LED string > of the display-backlight malfunctions (because of damage) and > requires the damaged string to be turned off to prevent the > complete panel and/or board from being damaged. > > Signed-off-by: Kiran Gunda > --- > drivers/video/backlight/qcom-wled.c | 410 +++++++++++++++++++++++++++++++++++- > 1 file changed, 404 insertions(+), 6 deletions(-) > > diff --git a/drivers/video/backlight/qcom-wled.c b/drivers/video/backlight/qcom-wled.c > index b5b125c..ff7c409 100644 > --- a/drivers/video/backlight/qcom-wled.c > +++ b/drivers/video/backlight/qcom-wled.c [...] > + /* iterate through the strings one by one */ Please use proper English in comments (less a full stop). In this case, just s/iterate/Iterate/. > + for (i = 0; i < wled->cfg.num_strings; i++) { > + sink_test = BIT((WLED4_SINK_REG_CURR_SINK_SHFT + i)); > + > + /* Enable feedback control */ > + rc = regmap_write(wled->regmap, wled->ctrl_addr + > + WLED3_CTRL_REG_FEEDBACK_CONTROL, i + 1); > + if (rc < 0) { > + dev_err(wled->dev, "Failed to enable feedback for SINK %d rc = %d\n", > + i + 1, rc); > + goto failed_detect; > + } > + > + /* enable the sink */ Here too. And everywhere else. > + rc = regmap_write(wled->regmap, wled->sink_addr + > + WLED4_SINK_REG_CURR_SINK, sink_test); > + if (rc < 0) { > + dev_err(wled->dev, "Failed to configure SINK %d rc=%d\n", > + i + 1, rc); > + goto failed_detect; > + } > + > + /* Enable the module */ > + rc = regmap_update_bits(wled->regmap, wled->ctrl_addr + > + WLED3_CTRL_REG_MOD_EN, > + WLED3_CTRL_REG_MOD_EN_MASK, > + WLED3_CTRL_REG_MOD_EN_MASK); > + if (rc < 0) { > + dev_err(wled->dev, "Failed to enable WLED module rc=%d\n", > + rc); > + goto failed_detect; > + } > + > + usleep_range(WLED_SOFT_START_DLY_US, > + WLED_SOFT_START_DLY_US + 1000); > + > + rc = regmap_read(wled->regmap, wled->ctrl_addr + > + WLED3_CTRL_REG_INT_RT_STS, &int_sts); > + if (rc < 0) { > + dev_err(wled->dev, "Error in reading WLED3_CTRL_INT_RT_STS rc=%d\n", > + rc); > + goto failed_detect; > + } > + > + if (int_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS) > + dev_dbg(wled->dev, "WLED OVP fault detected with SINK %d\n", > + i + 1); I haven't reviewed the whole patch, but this caught my eye. I think this should be upgraded to dev_warn(). > + else > + sink_valid |= sink_test; > + > + /* Disable the module */ > + rc = regmap_update_bits(wled->regmap, > + wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN, > + WLED3_CTRL_REG_MOD_EN_MASK, 0); > + if (rc < 0) { > + dev_err(wled->dev, "Failed to disable WLED module rc=%d\n", > + rc); > + goto failed_detect; > + } > + } > + > + if (!sink_valid) { > + dev_err(wled->dev, "No valid WLED sinks found\n"); > + wled->disabled_by_short = true; > + goto failed_detect; > + } > + > + if (sink_valid == sink_config) { > + dev_dbg(wled->dev, "WLED auto-detection complete, sink-config=%x OK!\n", > + sink_config); Does this really need to be placed in the kernel log? > + } else { > + dev_warn(wled->dev, "New WLED string configuration found %x\n", > + sink_valid); Why would the user care about this? Is it not normal? > + sink_config = sink_valid; > + } [...] > +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled) > +{ > + struct wled *wled = _wled; > + int rc; > + u32 int_sts, fault_sts; > + > + rc = regmap_read(wled->regmap, > + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, &int_sts); > + if (rc < 0) { > + dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n", > + rc); > + return IRQ_HANDLED; > + } > + > + rc = regmap_read(wled->regmap, wled->ctrl_addr + > + WLED3_CTRL_REG_FAULT_STATUS, &fault_sts); > + if (rc < 0) { > + dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n", > + rc); > + return IRQ_HANDLED; > + } > + > + if (fault_sts & > + (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT)) Break the line at the '|'. > + dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts= %x\n", > + int_sts, fault_sts); dev_warn(). > + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) { > + mutex_lock(&wled->lock); > + disable_irq_nosync(wled->ovp_irq); > + > + if (wled_auto_detection_required(wled)) > + wled_auto_string_detection(wled); > + > + enable_irq(wled->ovp_irq); > + > + mutex_unlock(&wled->lock); > + } > + > + return IRQ_HANDLED; > +} > + > static int wled3_setup(struct wled *wled) > { > u16 addr; > @@ -435,8 +775,10 @@ static int wled4_setup(struct wled *wled) > sink_en |= 1 << temp; > } > > - if (sink_cfg == sink_en) > - return 0; > + if (sink_cfg == sink_en) { > + rc = wled_auto_detection_at_init(wled); > + return rc; > + } > > rc = regmap_update_bits(wled->regmap, > wled->sink_addr + WLED4_SINK_REG_CURR_SINK, > @@ -499,7 +841,9 @@ static int wled4_setup(struct wled *wled) > return rc; > } > > - return 0; > + rc = wled_auto_detection_at_init(wled); > + > + return rc; > } > > static const struct wled_config wled4_config_defaults = { > @@ -510,6 +854,7 @@ static int wled4_setup(struct wled *wled) > .switch_freq = 11, > .cabc = false, > .external_pfet = false, > + .auto_detection_enabled = false, > }; > > static const u32 wled3_boost_i_limit_values[] = { > @@ -676,6 +1021,7 @@ static int wled_configure(struct wled *wled, int version) > { "qcom,ext-gen", &cfg->ext_gen, }, > { "qcom,cabc", &cfg->cabc, }, > { "qcom,external-pfet", &cfg->external_pfet, }, > + { "qcom,auto-string-detection", &cfg->auto_detection_enabled, }, > }; > > prop_addr = of_get_address(dev->of_node, 0, NULL, NULL); > @@ -796,6 +1142,40 @@ static int wled_configure_short_irq(struct wled *wled, > return rc; > } > > +static int wled_configure_ovp_irq(struct wled *wled, > + struct platform_device *pdev) > +{ > + int rc; > + u32 val; > + > + wled->ovp_irq = platform_get_irq_byname(pdev, "ovp"); > + if (wled->ovp_irq < 0) { > + dev_dbg(&pdev->dev, "ovp irq is not used\n"); I assume this is optional. What happens if no IRQ is provided? If, for instance, polling mode is enabled, maybe something like this would be better? dev_warn(&pdev->dev, "No IRQ found, falling back to polling mode\n"); -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog