LKML Archive on lore.kernel.org help / color / mirror / Atom feed
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: linkBe 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).