Received: by 10.192.165.148 with SMTP id m20csp3376932imm; Mon, 7 May 2018 11:10:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpeM0yxOFyKXNmhx036iVPGVZs6ZCz1o7cAJmfmN7puN9Ms/ijfrbyH+cSf7arJv3I+yXBH X-Received: by 2002:a9d:22a9:: with SMTP id y38-v6mr10580314ota.260.1525716624510; Mon, 07 May 2018 11:10:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525716624; cv=none; d=google.com; s=arc-20160816; b=coiE0sZIkpuSUBeTuDD7L6l+GFtq65EFs6/6Ilz5C3OXRC04wNprm0XCMr6sUYvWOb ORWQQSUWU9HPv01L9FPyoEeF2ILwyZnQze4PXkvO8kvAmTjFqWyA7f8nlCa0c+F2xPwz c7S2qTAA6akjeF1tNwynuQIuPsWOyJdzEqQlTMsUgX1XO8vymqzV1XdQut607qXuI34C sfV+0lsJ8XE/cqo3wy03dh+EWzkc7g8+gCw2LaSh63XHlc8P2i55cDv8DT6kAZviToga ZKh/SdScGt3n6i/u4QZwBHbMPaiMOhXJ309EyRYmE0kZF1VKB+cKLyxNJwaJmDV7jzpi b4Ng== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=+kt9qfvf5F7kwVczD2/AbEAppweCpbz4OFSEDeRBIqg=; b=Q5m+yOTxUk/L6yhQW+OI/1PlxRXQA0W7rJDart68jYqEoK5yVIkGOheA1PNOUyrLSL Bde3wyBDAqDjjllrqDknMCcrzJHE+/eW6FuFSeQ4baUquECKocePBM8IpHl0zNjeE7zB jEEsaXMJHlZXbhCbxfOtc7x7e+HUbFMPMCOvW3jE6leX7ZrwarRsDF1SThwN0Mz9pkeK dmlzPc/x6bnV50fX97uXPuj9fJ5YgO/fgCsaIlpOwrjr9Lg12GYs1Yw4nMAimh+uOm6g AMlWn+ta5CoLBXH7ETVIxro6BxXwWMlv+Scixfp4F9miTVmHR1FarYUXyYmsYdpyts51 fuuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Q8P3kc/A; 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 j66-v6si2495704otj.190.2018.05.07.11.10.10; Mon, 07 May 2018 11:10:24 -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=Q8P3kc/A; 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 S1752754AbeEGSJY (ORCPT + 99 others); Mon, 7 May 2018 14:09:24 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:35501 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752389AbeEGSJV (ORCPT ); Mon, 7 May 2018 14:09:21 -0400 Received: by mail-pl0-f68.google.com with SMTP id i5-v6so206545plt.2 for ; Mon, 07 May 2018 11:09:21 -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:in-reply-to:user-agent; bh=+kt9qfvf5F7kwVczD2/AbEAppweCpbz4OFSEDeRBIqg=; b=Q8P3kc/AcueyJxwVdnyUl4ncNP2z1ugcSU/rNrnAEogEjV/8CIYm60ujvUUNK68jxR wVEAV/CB35KEw4BLVvlXtHKuWbNflwZoK5wB9Xvr5rdDPuEqXsz/LmLQRoX1xmRT1Vgc /AJDKL6Kz2II/Be3BBemO2zRK1i/2ZSyZzE7c= 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:in-reply-to:user-agent; bh=+kt9qfvf5F7kwVczD2/AbEAppweCpbz4OFSEDeRBIqg=; b=qefI5cp/MriwE9t2V3Abv7ML5o+v4LK7qhCLs8GnmMj5E+3HOY7t+tlmwmMt+yhHF8 gYoOtH+bCX38ZR3FDjkHRT4olRGHw5AINGCiJU60RPqkhGLJDI7NRouOvaCSxJkVknQt vvr+smV3yhtQOl0dMLS6ZACbNFIGs1QHdgAlQCLubRGuTUSAKsK3ceo5Xm4bI9HPl/mX 8cSj86mKqp4Xuv2bVxZRzXtja9JvA4mx/gD/bveRpSk6FAvyFNs8OQsIWXPa8SXC0qth eX/o0aZz6kdbMdjAr8eiHajhuUpjzLfue1d0Qnz4NVM0GXdyB6FYn91Gp1XQ3AG7VSwE Xq7w== X-Gm-Message-State: ALQs6tDfVApcK7+KTOlSeWdJiTX4L9fBl4rCyGUhGOwUy35JW4xxH9b4 WG/VheWkc3mmMCyObnMan5dKzA== X-Received: by 2002:a17:902:a5:: with SMTP id a34-v6mr38670875pla.58.1525716561217; Mon, 07 May 2018 11:09:21 -0700 (PDT) Received: from tuxbook-pro (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id a65sm51380680pfg.40.2018.05.07.11.09.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 07 May 2018 11:09:20 -0700 (PDT) Date: Mon, 7 May 2018 11:10:44 -0700 From: Bjorn Andersson To: Kiran Gunda Cc: Lee Jones , Daniel Thompson , Jingoo Han , Bartlomiej Zolnierkiewicz , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-leds@vger.kernel.org Subject: Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic Message-ID: <20180507181044.GE2259@tuxbook-pro> References: <1525341432-15818-1-git-send-email-kgunda@codeaurora.org> <1525341432-15818-6-git-send-email-kgunda@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525341432-15818-6-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 Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: [..] > + > +#define WLED_AUTO_DETECT_OVP_COUNT 5 > +#define WLED_AUTO_DETECT_CNT_DLY_US HZ /* 1 second */ > +static bool wled_auto_detection_required(struct wled *wled) So cfg.auto_detection_enabled is set, but we didn't have a fault during wled_auto_detection_at_init(), which I presume indicates that the boot loader configured the strings appropriately (or didn't enable the BL). Then first time we try to enable the backlight we will hit the ovp irq, which will enter here a few times to figure out that the strings are incorrectly configured and then we will do the same thing that would have been done if we probed with a fault. This is convoluted! If auto-detection is a feature allowing the developer to omit the string configuration then just do the auto detection explicitly in probe when the developer did so and then never do it again. > +{ > + s64 elapsed_time_us; > + > + if (*wled->version == WLED_PM8941) > + return false; > + /* > + * Check if the OVP fault was an occasional one > + * or if it's firing continuously, the latter qualifies > + * for an auto-detection check. > + */ > + if (!wled->auto_detection_ovp_count) { > + wled->start_ovp_fault_time = ktime_get(); > + wled->auto_detection_ovp_count++; > + } else { > + elapsed_time_us = ktime_us_delta(ktime_get(), > + wled->start_ovp_fault_time); > + if (elapsed_time_us > WLED_AUTO_DETECT_CNT_DLY_US) > + wled->auto_detection_ovp_count = 0; > + else > + wled->auto_detection_ovp_count++; > + > + if (wled->auto_detection_ovp_count >= > + WLED_AUTO_DETECT_OVP_COUNT) { > + wled->auto_detection_ovp_count = 0; > + return true; > + } > + } > + > + return false; > +} > + > +static int wled_auto_detection_at_init(struct wled *wled) > +{ > + int rc; > + u32 fault_status = 0, rt_status = 0; > + > + if (*wled->version == WLED_PM8941) > + return 0; cfg.auto_detection_enabled will be false in this case, so there's no need for the extra check. > + > + if (!wled->cfg.auto_detection_enabled) > + return 0; > + > + rc = regmap_read(wled->regmap, > + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, > + &rt_status); > + if (rc < 0) { > + pr_err("Failed to read RT status rc=%d\n", rc); > + return rc; > + } > + > + rc = regmap_read(wled->regmap, > + wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS, > + &fault_status); > + if (rc < 0) { > + pr_err("Failed to read fault status rc=%d\n", rc); > + return rc; > + } > + > + if ((rt_status & WLED3_CTRL_REG_OVP_FAULT_STATUS) || > + (fault_status & WLED3_CTRL_REG_OVP_FAULT_BIT)) { So this would only happen if the boot loader set an invalid string configuration, as we have yet to enable the module here? > + mutex_lock(&wled->lock); > + rc = wled_auto_string_detection(wled); > + if (!rc) > + wled->auto_detection_done = true; > + mutex_unlock(&wled->lock); > + } > + > + return rc; > +} > + > +static void handle_ovp_fault(struct wled *wled) > +{ > + if (!wled->cfg.auto_detection_enabled) As this is the only reason for requesting the ovp_irq, how about just not requesting it in this case? > + return; > + > + mutex_lock(&wled->lock); > + if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) { The logic here is unnecessary, the only way handle_ovp_fault() is ever executed is if wled_ovp_irq_handler() was called, which is a really good indication that ovp_irq is valid and !ovp_irq_disabled. So this is always going to be entered. > + disable_irq_nosync(wled->ovp_irq); > + wled->ovp_irq_disabled = true; > + } > + > + if (wled_auto_detection_required(wled)) > + wled_auto_string_detection(wled); > + > + if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) { Again, ovp_irq is valid and we entered the function with either ovp_irq_disabled = true due to some bug or it was set to true above. So this check is useless - which renders ovp_irq_disabled unnecessary as well. > + enable_irq(wled->ovp_irq); > + wled->ovp_irq_disabled = false; > + } > + mutex_unlock(&wled->lock); > +} > + > static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled) > { > struct wled *wled = _wled; > @@ -413,6 +706,9 @@ static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled) > dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x fault_sts= %x\n", > int_sts, fault_sts); > > + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT) > + handle_ovp_fault(wled); Just inline handle_ovp_fault() here and make things less "generic". > + > return IRQ_HANDLED; > } > > @@ -575,6 +871,10 @@ static int wled4_setup(struct wled *wled) > return rc; > } > > + rc = wled_auto_detection_at_init(wled); > + if (rc < 0) > + return rc; > + > if (wled->cfg.external_pfet) { > /* Unlock the secure register access */ > rc = regmap_write(wled->regmap, wled->ctrl_addr + > @@ -602,6 +902,7 @@ static int wled4_setup(struct wled *wled) > .enabled_strings = 0xf, > .cabc = false, > .external_pfet = true, > + .auto_detection_enabled = false, > }; > > static const u32 wled3_boost_i_limit_values[] = { > @@ -785,6 +1086,7 @@ static int wled_configure(struct wled *wled) > { "qcom,ext-gen", &cfg->ext_gen, }, > { "qcom,cabc", &cfg->cabc, }, > { "qcom,external-pfet", &cfg->external_pfet, }, > + { "qcom,auto-string-detection", &cfg->auto_detection_enabled, }, > }; So afaict the auto detect logic is triggered by two things: * Boot loader enabled backlight with an invalid string configuration, which will make wled_auto_detection_at_init() do the detection. * Once we the driver tries to enable the module, ovp faults will start arriving and we will trigger the auto detection. But I think you can integrate this in a much more direct way. If the module is enabled and there are no faults you should be able to just read the config from the hardware (if auto detect is enabled!) and if the module is not enabled you can just call auto detect from probe(). This will give you flicker free "auto detection" in the event that the boot loader did its job and very clean logic in the other cases. Regards, Bjorn