From: Vignesh R <vigneshr@ti.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Strashko, Grygorii" <grygorii.strashko@ti.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v2 2/3] Input: ti_am335x_tsc - Ack pending IRQs at probe and before suspend
Date: Tue, 17 Apr 2018 13:49:00 +0530 [thread overview]
Message-ID: <59afa48c-df5f-1c45-70e5-a0ae0aae8cff@ti.com> (raw)
In-Reply-To: <20180416175909.GC77055@dtor-ws>
On Monday 16 April 2018 11:29 PM, Dmitry Torokhov wrote:
> On Sat, Apr 14, 2018 at 03:21:52PM +0530, Vignesh R wrote:
>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> It is seen that just enabling the TSC module triggers a HW_PEN IRQ
>> without any interaction with touchscreen by user. This results in first
>> suspend/resume sequence to fail as system immediately wakes up from
>> suspend as soon as HW_PEN IRQ is enabled in suspend handler due to the
>> pending IRQ. Therefore clear all IRQs at probe and also in suspend
>
> Are the interrupts configured as edge?
>
No, its a level interrupt.
>> callback for sanity.
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> Acked-by: Lee Jones <lee.jones@linaro.org>
>> ---
>>
>> v2: Add Acks from v1.
>>
>> drivers/input/touchscreen/ti_am335x_tsc.c | 2 ++
>> include/linux/mfd/ti_am335x_tscadc.h | 1 +
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
>> index 810e05c9c4f5..dcd9db768169 100644
>> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
>> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
>> @@ -439,6 +439,7 @@ static int titsc_probe(struct platform_device *pdev)
>> dev_err(&pdev->dev, "irq wake enable failed.\n");
>> }
>>
>> + titsc_writel(ts_dev, REG_IRQSTATUS, IRQENB_MASK);
>> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
>> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
>
> Out of curiosity, should this be:
>
> titsc_writel(ts_dev, REG_IRQENABLE,
> IRQENB_FIFO0THRES | IRQENB_EOS);
>
> ?
>
> Because 2nd titsc_writel() overwrites the first? Or separate writes to
> the same register are distinct?
>
As per TRM, writing 0 to any bit of REG_IRQENABLE has no effect(IRQs are
cleared by writing to REG_IRQCLR). Therefore, second write does not
overwrite the first. I agree that there is nothing that prevents us from
enabling both IRQs in a single write. That can be a separate cleanup patch.
>> err = titsc_config_wires(ts_dev);
>> @@ -504,6 +505,7 @@ static int __maybe_unused titsc_suspend(struct device *dev)
>>
>> tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
>> if (device_may_wakeup(tscadc_dev->dev)) {
>> + titsc_writel(ts_dev, REG_IRQSTATUS, IRQENB_MASK);
>
> The comment in titsc_irq() says that we should not be touching
> IRQENB_FIFO0THRES as it is used by another driver, but here we are
> whacking it. Can you elaborate why this is safe?
>
> You might need to rework the interrupt handling since you have several
> drivers...
>
I guess you meant IRQENB_FIFO1THRES(FIFO0 is used for TSC and FIFO1 is
ADC). Yes, this driver must not touch FIFO1 related IRQs, I will fix
that up in next version.
>> idle = titsc_readl(ts_dev, REG_IRQENABLE);
>> titsc_writel(ts_dev, REG_IRQENABLE,
>> (idle | IRQENB_HW_PEN));
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> index b9a53e013bff..1a6a34f726cc 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -63,6 +63,7 @@
>> #define IRQENB_FIFO1OVRRUN BIT(6)
>> #define IRQENB_FIFO1UNDRFLW BIT(7)
>> #define IRQENB_PENUP BIT(9)
>> +#define IRQENB_MASK (0x7FF)
>>
>> /* Step Configuration */
>> #define STEPCONFIG_MODE_MASK (3 << 0)
>> --
>> 2.17.0
>>
>
> Thanks.
>
> --
> Dmitry
--
Regards
Vignesh
next prev parent reply other threads:[~2018-04-17 8:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-14 9:51 [PATCH v2 0/3] ti_am335x_tsc: Fix suspend/resume Vignesh R
2018-04-14 9:51 ` [PATCH v2 1/3] Input: ti_am335x_tsc - Mark IRQ as wakeup capable Vignesh R
2018-04-16 17:45 ` Dmitry Torokhov
2018-04-17 8:20 ` Vignesh R
2018-04-14 9:51 ` [PATCH v2 2/3] Input: ti_am335x_tsc - Ack pending IRQs at probe and before suspend Vignesh R
2018-04-16 17:59 ` Dmitry Torokhov
2018-04-17 8:19 ` Vignesh R [this message]
2018-04-14 9:51 ` [PATCH v2 3/3] Input: ti_am335x_tsc - Prevent system suspend when TSC is in use Vignesh R
2018-04-16 18:01 ` Dmitry Torokhov
2018-04-17 8:19 ` Vignesh R
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=59afa48c-df5f-1c45-70e5-a0ae0aae8cff@ti.com \
--to=vigneshr@ti.com \
--cc=dmitry.torokhov@gmail.com \
--cc=grygorii.strashko@ti.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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
all inboxes | Powered by JetHome®