linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: kgunda@codeaurora.org
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: bjorn.andersson@linaro.org, jingoohan1@gmail.com,
	lee.jones@linaro.org, b.zolnierkie@samsung.com,
	dri-devel@lists.freedesktop.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 <agross@kernel.org>,
	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
Date: Thu, 17 Oct 2019 17:47:47 +0530	[thread overview]
Message-ID: <fa32f7ec727cb2626ad877a6cef32a1b@codeaurora.org> (raw)
In-Reply-To: <20191017112941.qqvgboyambzw63i3@holly.lan>

On 2019-10-17 16:59, Daniel Thompson wrote:
> On Wed, Oct 16, 2019 at 03:43:46PM +0530, 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 <kgunda@codeaurora.org>
> 
> It's a complex bit of code but I'm OK with it in principle. Everything
> below is about small details and/or nitpicking.
> 
> 
>> +static void wled_ovp_work(struct work_struct *work)
>> +{
>> +	struct wled *wled = container_of(work,
>> +					 struct wled, ovp_work.work);
>> +	enable_irq(wled->ovp_irq);
>> +}
>> +
> 
> A bit of commenting about why we have to wait 10ms before enabling the
> OVP interrupt would be appreciated.
> 
> 
Sure. Will add the comment in the next series.
>> +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))
>> +		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) {
>> +		mutex_lock(&wled->lock);
>> +		disable_irq_nosync(wled->ovp_irq);
> 
> We're currently running the threaded ISR for this irq. Do we really 
> need
> to disable it?
> 
We need to disable this IRQ, during the auto string detection logic. 
Because
in the auto string detection we configure the current sinks one by one 
and check the
status register for the OVPs and set the right string configuration. We 
enable it later after
the auto string detection is completed.
>> +
>> +		if (wled_auto_detection_required(wled))
>> +			wled_auto_string_detection(wled);
>> +
>> +		enable_irq(wled->ovp_irq);
>> +
>> +		mutex_unlock(&wled->lock);
>> +	}
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
> 
> Snip.
> 
> 
>> +static int wled_remove(struct platform_device *pdev)
>> +{
>> +	struct wled *wled = dev_get_drvdata(&pdev->dev);
>> +
>> +	cancel_delayed_work_sync(&wled->ovp_work);
>> +	mutex_destroy(&wled->lock);
> 
> Have the irq handlers been disabled at this point?
> 
Ok.. may not be. I will disable the irq's here in next series.

> Also, if you want to destroy the mutex shouldn't that code be
> introduced in the same patch that introduces the mutex?
Ok.. I will move it to the same patch where the mutex introduced in next 
series.
>> +
>> +	return 0;
>> +}
> 
> 
> Daniel.

  reply	other threads:[~2019-10-17 12:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 10:13 [PATCH V7 0/6] backlight: qcom-wled: Support for QCOM wled driver Kiran Gunda
2019-10-16 10:13 ` [PATCH V7 1/6] backlight: qcom-wled: Add new properties for PMI8998 Kiran Gunda
2019-10-16 10:13 ` [PATCH V7 2/6] backlight: qcom-wled: Rename PM8941* to WLED3 Kiran Gunda
2019-10-16 10:13 ` [PATCH V7 3/6] backlight: qcom-wled: Restructure the driver for WLED3 Kiran Gunda
2019-10-16 10:13 ` [PATCH V7 4/6] backlight: qcom-wled: Add support for WLED4 peripheral Kiran Gunda
2019-10-17 11:06   ` Daniel Thompson
2019-10-17 12:27     ` kgunda
2019-10-16 10:13 ` [PATCH V7 5/6] backlight: qcom-wled: add support for short circuit handling Kiran Gunda
2019-10-17 11:09   ` Daniel Thompson
2019-10-17 12:30     ` kgunda
2019-10-16 10:13 ` [PATCH V7 6/6] backlight: qcom-wled: Add auto string detection logic Kiran Gunda
2019-10-17 11:29   ` Daniel Thompson
2019-10-17 12:17     ` kgunda [this message]
2019-10-17 13:39       ` Daniel Thompson
2019-10-18  6:42         ` kgunda
2019-10-17 12:26   ` Lee Jones
2019-10-17 13:09     ` kgunda
2019-10-17 13:30       ` Lee Jones
2019-10-18  5:03         ` kgunda

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=fa32f7ec727cb2626ad877a6cef32a1b@codeaurora.org \
    --to=kgunda@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=bjorn.andersson@linaro.org \
    --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=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.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=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).