Ulf Hansson 682696605c mmc: sdio: Add API to manage SDIO IRQs from a workqueue
For hosts not supporting MMC_CAP2_SDIO_IRQ_NOTHREAD but MMC_CAP_SDIO_IRQ,
the SDIO IRQs are processed from a dedicated kernel thread. For these
cases, the host calls mmc_signal_sdio_irq() from its ISR to signal a new
SDIO IRQ.

Signaling an SDIO IRQ makes the host's ->enable_sdio_irq() callback to be
invoked to temporary disable the IRQs, before the kernel thread is woken up
to process it. When processing of the IRQs are completed, they are
re-enabled by the kernel thread, again via invoking the host's
->enable_sdio_irq().

The observation from this, is that the execution path is being unnecessary
complex, as the host driver already knows that it needs to temporary
disable the IRQs before signaling a new one. Moreover, replacing the kernel
thread with a work/workqueue would not only greatly simplify the code, but
also make it more robust.

To address the above problems, let's continue to build upon the support for
MMC_CAP2_SDIO_IRQ_NOTHREAD, as it already implements SDIO IRQs to be
processed without using the clumsy kernel thread and without the ping-pong
calls of the host's ->enable_sdio_irq() callback for each processed IRQ.

Therefore, let's add new API sdio_signal_irq(), which enables hosts to
signal/process SDIO IRQs by using a work/workqueue, rather than using the
kernel thread.

Add also a new host callback ->ack_sdio_irq(), which the work invokes when
the SDIO IRQs have been processed. This informs the host about when it
shall re-enable the SDIO IRQs. Potentially, we could re-use the existing
->enable_sdio_irq() callback instead of adding a new one, however it has
turned out that it's more convenient for hosts to get this information via
a separate callback.

Hosts that wants to use this new method to signal/process SDIO IRQs, must
enable MMC_CAP2_SDIO_IRQ_NOTHREAD and implement the ->ack_sdio_irq()
callback.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-06-20 10:30:11 +02:00
..
2017-04-12 18:51:01 +02:00
2017-04-21 10:45:01 -04:00
2017-05-08 19:03:25 -07:00
2017-05-11 10:44:22 -07:00
2017-05-11 11:12:26 -07:00
2017-05-10 15:33:45 +02:00
2017-05-09 15:15:47 -07:00
2017-05-09 15:15:47 -07:00
2017-04-28 18:09:59 -04:00
2017-05-01 14:09:21 -07:00
2017-06-14 13:27:50 -06:00
2017-04-11 14:38:43 -04:00
2017-04-26 23:54:06 -04:00
2017-03-30 09:37:20 +02:00
2017-05-24 12:43:30 -04:00
2017-04-18 20:41:12 +02:00
2017-05-05 18:49:20 -07:00
2017-04-10 17:15:02 +02:00
2017-04-27 05:13:04 -04:00
2017-05-25 13:44:28 -04:00
2017-05-12 15:57:15 -07:00
2017-03-21 10:15:47 +02:00
2017-04-05 18:11:48 +02:00
2017-05-04 19:15:35 -07:00
2017-05-08 17:15:12 -07:00
2017-05-03 15:52:10 -07:00
2017-06-19 21:50:20 +08:00
2017-05-03 19:12:27 -07:00
2017-04-24 14:30:46 -04:00
2017-05-10 13:03:38 -07:00
2017-04-26 13:03:04 -04:00
2017-05-09 15:15:47 -07:00
2017-05-05 11:36:44 -07:00
2017-05-26 10:51:18 -07:00
2017-05-09 10:01:15 -07:00
2017-03-07 14:01:02 -08:00
2017-05-09 16:43:23 +03:00
2017-03-28 08:54:48 +02:00
2017-05-03 15:52:10 -07:00
2017-05-05 18:16:23 -07:00
2017-05-08 17:15:12 -07:00
2017-03-26 15:09:45 +02:00
2017-03-22 12:15:15 -07:00
2017-05-05 18:49:20 -07:00
2017-03-09 15:42:33 +01:00
2017-05-09 16:43:22 +03:00