gpio/omap v2: map irq_enable/disable to mask/unmask.
Hi Santosh,
I submitted the following patch a while back.
https://patchwork.kernel.org/patch/1886421/
As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips.
[why it is needed]
The omap_hsmmc module is suspended whenever it is idle, its functional clock being turned off. In this mode it is not able to forwared IRQs to the system. For that to happen, it needs to tell the PRCM to restore it's fclk.
------
| PRCM |
------
| ^
fclk | | swakeup
v |
------- ------
<-- IRQ -- | hsmmc | <-- CIRQ -- | card |
------- ------This is done through the swakeup line, which can be configured to trigger for various events, among others; CIRQ. The problem is that on the AM335x family the swakeup line is missing, it has not been routed from the module to the PRCM.
[solution]
the simplest solution was to keep the fclk enabled all the time. But that was not accepted, instead this was suggested
Quoted 9 lines
Quoted 4 lines
The alternative was to configure dat1 line as a GPIO, while waiting for an IRQ. Then configuring it back as dat1 to serve the SDIO card after it signalled an IRQ. Or when the host wants to start a transfer.
The way to implement this is set named states in the .dts file for the pins using
pinctrl-single.c, then have the MMC driver request states "default" "active" and "idle" during the probe, then toggle between active and idle during the runtime.
Surprisingly the induced overhead is quite small, the performance is similar to keeping the fclk enabled at all times. See here for full thread:
http://www.spinics.net/lists/linux-omap/msg83363.html
https://patchwork.kernel.org/patch/1901471/ ... or just the patch
There are still open questions to gpio patch itself, see here
http://www.mail-archive.com/[email protected]/msg87217.html
So could we pls reopen that thread? It might be on the other side of your mailbox
rgds,
Andi
Hi,
Quoted 7 lines · Andreas Fenkart
Hi Santosh,
I submitted the following patch a while back.
https://patchwork.kernel.org/patch/1886421/As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips.
I suggest you repost, patches can easily get forgotten unuless you follow-up getting them merged.
Quoted 36 lines
[why it is needed]
The
omap_hsmmcmodule is suspended whenever it is idle, its functional clock being turned off. In this mode it is not able to forwared IRQs to the system. For that to happen, it needs to tell the PRCM to restore it's fclk.------ | PRCM | ------ | ^ fclk | | swakeup v | ------- ------ <-- IRQ -- | hsmmc | <-- CIRQ -- | card | ------- ------This is done through the swakeup line, which can be configured to trigger for various events, among others; CIRQ. The problem is that on the AM335x family the swakeup line is missing, it has not been routed from the module to the PRCM.
[solution]
the simplest solution was to keep the fclk enabled all the time. But that was not accepted, instead this was suggestedQuoted 9 lines
Quoted 4 lines
The alternative was to configure dat1 line as a GPIO, while waiting for an IRQ. Then configuring it back as dat1 to serve the SDIO card after it signalled an IRQ. Or when the host wants to start a transfer.
The way to implement this is set named states in the .dts file for the pins using
pinctrl-single.c, then have the MMC driver request states "default" "active" and "idle" during the probe, then toggle between active and idle during the runtime.
Quoted 5 lines
Surprisingly the induced overhead is quite small, the performance is similar to keeping the fclk enabled at all times. See here for full thread:
http://www.spinics.net/lists/linux-omap/msg83363.html
https://patchwork.kernel.org/patch/1901471/ ... or just the patch
That's nice, AFAIK this is the only way to do it for some omaps.
Quoted 5 lines
There are still open questions to gpio patch itself, see here
http://www.mail-archive.com/[email protected]/msg87217.htmlSo could we pls reopen that thread? It might be on the other side of your mailbox
The SDIO related patch can already get merged while the GPIO patch is being discussed I hope?
If so, you should fix #if 0 part I commented on and repost with the ack from Grant. And update it against the current linux next so people can apply it for testing.
Regards,
Tony
Quoted 10 lines · Andreas Fenkart
Hi Santosh,
I submitted the following patch a while back.
https://patchwork.kernel.org/patch/1886421/As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips.
[why it is needed]
Why part is clear for me.
Quoted 6 lines
There are still open questions to gpio patch itself, see here
http://www.mail-archive.com/[email protected]/msg87217.htmlSo could we pls reopen that thread? It might be on the other side of your mailbox
Your idea is reasonable and probably patch make lot of sense for edge triggered interrupt.
Can you please repost the patch with the more comprehensive change-log as discussed in the thread.
Regards,
Santosh
Quoted 16 lines · Santosh Shilimkar
Quoted 10 lines · Andreas Fenkart
Hi Santosh,
I submitted the following patch a while back.
https://patchwork.kernel.org/patch/1886421/As already said, the patch is straight forward, but without it, we probably will not see decent SDIO performance on am335x chips.
[why it is needed]
Why part is clear for me.
Quoted 3 lines
There are still open questions to gpio patch itself, see here
http://www.mail-archive.com/[email protected]/msg87217.html
Quoted 8 lines
Quoted 3 lines
So could we pls reopen that thread? It might be on the other side of your mailbox
Your idea is reasonable and probably patch make lot of sense for edge triggered interrupt.
Can you please repost the patch with the more comprehensive change-log as discussed in the thread.
Originally, I had a question on enable/disable versus mask/unmask, but looking at the way we have implemented mask/unmask for omap, I don't think that my question is really applicable. Yes so please re-post.
Jon