RE: [PATCH] OMAP2/3 Avoid GPIO pending irq status been set after irq_disable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> "Wang Sawsd-A24013" <cqwang@xxxxxxxxxxxx> writes:
> 
> > Resend because of the content format issues in last mail---sorry for
> > inconvenience.
> 
> This version is line-wrapped and otherwise confusing as well so does
> not apply cleanly.  Could you try using 'git format-patch' to generate
> your patch?  It looks like you may have used 'git diff' and then
> appended them together?
> 

I did use git-format-patch command, seems the issue is caused 
our mail server, this time I attached the whole patch in the mail,
and I didn't separate the change into sub-patchs, see explanation below.

> In addition, the many uses of "also" in this description suggest that
> that it could be broken up in to several patches with more clear
> descriptions/justifications..  Some are fixes, some are new
> functionality.

Yes, "also" is abused in my description, too spoken. :-) 
But the whole change is actually for the same issue which is 
OMAP GPIO IRQ/WAKEUP issue and I think they are all fixes
but not new functionality.

> 
> > This patch adds irq_enable and irq_disable for OMAP GPIO IRQ chip, 
> 
> Please elaborate on why you chose to implement the enable/disable
> hooks instead of using the mask/unmask hooks.
> 
1: irq mask/unmask are typically used by the IRQ handling framework
or CHIP IRQ handler to disable and enable IRQ during the IRQ handing
procedure; While still many drivers are using irq_disable and
irq_disable
in their code especially in the case of suspend/resume and IOCTL to turn
on/off the peripherals, without the irq_disable in IRQ CHIP, the
default_disable
Is used but it is just an empty function now. This will cause an issue
that
The IRQ may still happen after irq_disable which may cause unexpected 
behavior in driver since they are not expecting any IRQ after
irq_disable.

2: I noticed that we have the mask and unmask already, but why I didn't
choose to use them directly for irq_disable and irq_enable is because
we need something special in irq_disable for OMAP. 

Since irq_disable typically means the driver wants to deactive the
peripherals
for a long period of time and may allow System going into low power
state, 
but for OMAP GPIO the IRQ status bit may still be set even when IRQEN
bit is cleared, that's why we need also clear the level detect and edge
detect
Configuration register to ensure after irq_disable, no IRQ status bit is
set,
since once the IRQ status bit is set while IRQ is disabled, then this
will
prevent GPIO module acknowledge IDLE request from PRCM, so PER 
and CORE will fail entering RET state. We are facing this issue now,
that is why I made this patch.


> > and also only enable WAKEUPEN When GPIO edge detection is enabled,
> 
> Can you send this fixa separate patch.  It is a bug fix that is
> separate from the new stuff you're adding here.
> 
This issue is also related with the OMAP GPIO IRQ wakeup configuration
So it is not a separate issue. But I can send it as separate patch if
the community
Think the rest of this patch is not applicable.

> > also clear the gpio event triggering configurations to avoid Pending
> > interrupt status which is generated regardless of the IRQEN and
> > WKUPEN bit, the pending IRQ status may prevent GPIO module
> > acknowledge IDLE request and prevent PER and thus CORE RETENTION.
> 
> Have you tested the PM branch code?
> 
Yes, I have verified the patch on the kernel which is based on google
omap
GIT which is based on linux-omap PM branch, and it does resolve the
issue.
The issue I am facing is the Touch controller on my HW will continously
report
Input interrupts fastly, so without the patch, the IRQ staus will be
pending there
Even after the touch driver calls irq_disable and prevents PER and CORE
going into RETENTION In suspend mode.

> I'm not sure I quite follow your description here, but IIUC, we are
> already doing this in the [prepare|resume]_idle() hooks.
> 
The code in GPIO prepare/resume for idle functions are made to address
another different issue for OMAP2, since on OMAP2 there are some silicon
bugs
that causes some GPIO to be non-wakeupable, so the workaround was made
to
not enable edge detection for those GPIOs and manually trigger IRQs
using level
detect based on input GPIO levels after idle. But for OMAP3, there is no
non-wakeup
gpio, all the GPIOs are wakeup gpios.

This patch is needed for both OMAP2 and OMAP3 since the GPIO module has
The similar silicon architecture, that is IRQ status will be set
regardless of IRQEN bit.

> Kevin
> > To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Attachment: 0001-Fix-OMAP2-3-GPIO-pending-irq-status-blocking-RETENTI.patch
Description: 0001-Fix-OMAP2-3-GPIO-pending-irq-status-blocking-RETENTI.patch


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux