On Mon, 3 Jun 2019 at 20:41, Doug Anderson dianders@chromium.org wrote:
Ulf,
On Tue, May 28, 2019 at 3:49 PM Doug Anderson dianders@chromium.org wrote:
- As kind of stated above, did you consider a solution where the core
simply disables the SDIO IRQ in case it isn't enabled for system wakeup? In this way all host drivers would benefit.
I can give it a shot if you can give me a bunch of specific advice, but I only have access to a few devices doing anything with SDIO and they are all using Marvell or Broadcom on dw_mmc.
In general I have no idea how SDIO wakeup (plumbed through the SD controller) would work. As per below the only way I've seen it done is totally out-of-band. ...and actually, I'm not sure I've actually ever seen even the out of band stuff truly work on a system myself. It's always been one of those "we should support wake on WiFi" but never made it all the way to implementation. In any case, if there are examples of people plumbing wakeup through the SD controller I'd need to figure out how to not break them. Just doing a solution for dw_mmc means I don't have to worry about this since dw_mmc definitely doesn't support SDIO wakeup.
Maybe one way to get a more generic solution is if you had an idea for a patch that would work for many host controllers then you could post it and I could test to confirm that it's happy on dw_mmc? ...similar to when you switched dw_mmc away from the old kthread-based SDIO stuff?
Let me have a look and see if I can post something for you to test.
Unless you have time to help dig into all the possibilities here to help understand how this should behave across all the different host controllers / wakeup setups, maybe we could just land ${SUBJECT} patch for now and when there is more clarity we can revisit?
That's an option. I only fear that the revisit part never happens (because of me personally being occupied with other things).
If I not able to come up with something within a week, then I will queue up this as fix.
Kind regards Uffe