All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ludovic Desroches <ludovic.desroches@atmel.com>
To: <ulf.hansson@linaro.org>, <adrian.hunter@intel.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mmc@vger.kernel.org>,
	<linux-pm@vger.kernel.org>, <nicolas.ferre@atmel.com>,
	Ludovic Desroches <ludovic.desroches@atmel.com>
Subject: [PATCH] sdhci: wakeup from runtime PM
Date: Fri, 25 Mar 2016 17:05:01 +0100	[thread overview]
Message-ID: <1458921903-11133-1-git-send-email-ludovic.desroches@atmel.com> (raw)

Hi,

When not using the SDHCI controller, it is logical to save power by suspending
it. The issue is that SDHCI assumes that the controller is completely disabled.
It means the only way to wake up on a card event is to have a gpio for the card
detection (so two pins for the same signal). A possible workaround is to use
polling but the controller will be resumed/suspended between each attempts.

We have already discussed a long time about this and it seems we don't agree.
In my opinion, even if I can't disable all clocks, I should use runtime PM 
to save some power.

I propose two patches, one which is a draft to try to solve it at sdhci level
and one at sdhci-of-at91 level.

Concerning the first one, I don't understand why we need to reject irqs if
runtime_suspended is true. Only SDHCI_INT_CARD_INT irq is enabled so why we
should have other IRQs than this one?

Since you were not in favour of allowing to wakeup on SDHCI_INT_CARD_INSERT or
SDHCI_INT_CARD_REMOVE, I assume you won't take it so I
solved my issue only by modifying my driver.

I have not noticed side effects. I have compared a wakeup with a gpio for card
detection and the controller card detect. It seems the two paths are rougly
the same (mmc_detect_change -> mmc_rescan then resume is performed).

Regards

Ludovic

WARNING: multiple messages have this Message-ID (diff)
From: Ludovic Desroches <ludovic.desroches@atmel.com>
To: ulf.hansson@linaro.org, adrian.hunter@intel.com
Cc: linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-pm@vger.kernel.org, nicolas.ferre@atmel.com,
	Ludovic Desroches <ludovic.desroches@atmel.com>
Subject: [PATCH] sdhci: wakeup from runtime PM
Date: Fri, 25 Mar 2016 17:05:01 +0100	[thread overview]
Message-ID: <1458921903-11133-1-git-send-email-ludovic.desroches@atmel.com> (raw)

Hi,

When not using the SDHCI controller, it is logical to save power by suspending
it. The issue is that SDHCI assumes that the controller is completely disabled.
It means the only way to wake up on a card event is to have a gpio for the card
detection (so two pins for the same signal). A possible workaround is to use
polling but the controller will be resumed/suspended between each attempts.

We have already discussed a long time about this and it seems we don't agree.
In my opinion, even if I can't disable all clocks, I should use runtime PM 
to save some power.

I propose two patches, one which is a draft to try to solve it at sdhci level
and one at sdhci-of-at91 level.

Concerning the first one, I don't understand why we need to reject irqs if
runtime_suspended is true. Only SDHCI_INT_CARD_INT irq is enabled so why we
should have other IRQs than this one?

Since you were not in favour of allowing to wakeup on SDHCI_INT_CARD_INSERT or
SDHCI_INT_CARD_REMOVE, I assume you won't take it so I
solved my issue only by modifying my driver.

I have not noticed side effects. I have compared a wakeup with a gpio for card
detection and the controller card detect. It seems the two paths are rougly
the same (mmc_detect_change -> mmc_rescan then resume is performed).

Regards

Ludovic

             reply	other threads:[~2016-03-25 16:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25 16:05 Ludovic Desroches [this message]
2016-03-25 16:05 ` [PATCH] sdhci: wakeup from runtime PM Ludovic Desroches
2016-03-25 16:05 ` [PATCH] DRAFT: shdci: allows custom wakeup irqs for " Ludovic Desroches
2016-03-25 16:05   ` Ludovic Desroches
2016-03-25 16:46   ` kbuild test robot
2016-03-25 16:46     ` kbuild test robot
2016-03-25 16:50   ` kbuild test robot
2016-03-25 16:50     ` kbuild test robot
2016-03-25 17:12   ` kbuild test robot
2016-03-25 17:12     ` kbuild test robot
2016-03-25 17:27   ` kbuild test robot
2016-03-25 17:27     ` kbuild test robot
2016-03-25 16:05 ` [PATCH] mmc: sdhci-of-at91: allow the use of controller card detect as wake up Ludovic Desroches
2016-03-25 16:05   ` Ludovic Desroches
2016-03-25 17:11   ` [PATCH] mmc: sdhci-of-at91: fix semicolon.cocci warnings kbuild test robot
2016-03-25 17:11     ` kbuild test robot
2016-03-25 17:11   ` [PATCH] mmc: sdhci-of-at91: allow the use of controller card detect as wake up kbuild test robot
2016-03-25 17:11     ` kbuild test robot
2016-04-05 12:40 ` [PATCH] sdhci: wakeup from runtime PM Adrian Hunter
2016-04-07  9:11   ` Ulf Hansson
2016-04-07 15:12     ` Ludovic Desroches
2016-04-08  8:35       ` Ulf Hansson
2016-04-08 15:19         ` Alan Stern
2016-04-08 20:51           ` Ulf Hansson
2016-04-11 12:09         ` Ludovic Desroches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1458921903-11133-1-git-send-email-ludovic.desroches@atmel.com \
    --to=ludovic.desroches@atmel.com \
    --cc=adrian.hunter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nicolas.ferre@atmel.com \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.