> "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
