Files
odroid-linux/include/linux
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-21 10:45:01 -04:00
2016-07-08 16:23:11 +02:00
2016-12-22 22:58:37 -05:00
2017-04-28 18:09:59 -04:00
2017-05-01 14:09:21 -07:00
2017-02-10 15:52:24 -05:00
2017-06-14 13:27:50 -06:00
2017-01-25 13:17:47 -05: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
2016-08-11 09:41:35 -06:00
2017-05-24 12:43:30 -04:00
2017-04-18 20:41:12 +02:00
2016-12-05 19:01:16 -05:00
2016-10-28 08:48:16 -06:00
2017-04-10 17:15:02 +02:00
2016-05-17 15:48:12 -04:00
2017-04-27 05:13:04 -04:00
2016-12-05 19:01:16 -05:00
2017-05-25 13:44:28 -04:00
2017-05-12 15:57:15 -07:00
2016-12-25 17:21:22 +01:00
2017-03-21 10:15:47 +02:00
2017-04-05 18:11:48 +02:00
2017-02-11 20:59:41 -05:00
2016-09-14 09:18:09 -06:00
2017-05-08 17:15:12 -07:00
2017-01-05 15:01:55 -06:00
2017-05-03 15:52:10 -07:00
2016-12-12 18:55:06 -08:00
2016-12-25 17:21:23 +01:00
2017-02-24 17:46:57 -08:00
2016-09-27 12:33:47 +02:00
2016-12-06 11:05:46 +01:00
2017-06-19 21:50:20 +08:00
2017-04-24 14:30:46 -04:00
2017-01-12 16:48:26 -05:00
2016-11-16 18:32:02 -05:00
2017-04-26 13:03:04 -04:00
2016-12-06 10:17:03 +02:00
2016-10-31 16:18:30 -04:00
2016-10-14 11:36:59 -07:00
2016-09-27 21:52:00 -04:00
2017-03-07 14:01:02 -08:00
2017-05-09 16:43:23 +03:00
2017-02-13 21:44:09 -05:00
2017-03-28 08:54:48 +02:00
2016-07-06 10:51:14 +01:00
2017-05-03 15:52:10 -07:00
2016-06-14 10:54:40 -07:00
2017-05-08 17:15:12 -07:00
2017-03-26 15:09:45 +02:00
2017-01-09 16:07:38 -05:00
2016-12-26 23:53:46 -05:00
2017-03-22 12:15:15 -07:00
2017-03-09 15:42:33 +01:00
2017-01-10 18:31:55 -08:00
2017-02-10 16:34:17 +00:00
2017-05-09 16:43:22 +03:00