* Re: arasan,sdhci.txt "compatibility" DT binding
From: Sebastian Frias @ 2016-11-30 10:51 UTC (permalink / raw)
To: Rameshwar Sahu, Mason
Cc: Mark Rutland, Ulf Hansson, Suman Tripathi, Heiko Stuebner,
Shawn Lin, Adrian Hunter, Jisheng Zhang, Russell King,
Anton Vorontsov, Michal Simek, Linux ARM, Linus Walleij,
P L Sai Krishna, Zach Brown, Arnd Bergmann, Suneel Garapati,
Soren Brinkmann, Michal Simek, linux-mmc, Douglas Anderson,
Maxime Ripard, Xiaobo Xie
In-Reply-To: <CAFd313zQHmFQ61Y4UEvQAvhhVeNFe=nNyjXUKfYXiTKnvm9VWQ@mail.gmail.com>
On 29/11/16 08:29, Rameshwar Sahu wrote:
> Hi Mason,
>
> Nowhere in the documentation do they specify an "IP version".
> Some documents do provide a revision number, but that's just
> a *documentation* revision number, e.g.
>
> changes in version 3.6 : fix typos
> changes in version 9.1a : update company logo
>
> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
> "arasan,sdhci-4.9a". These are documentation revisions.
> In my opinion, that information is mostly worthless.
>
For the record, the important information conveyed by Rameshwar's
email is the following:
Arasan SD/SDIO/eMMC IP has a register which tells about the SD
specification version and Vendor version number
Reg Name: Host controller version register (offset 0FEh)
bit [15:8] is for vendor version number,
But, I have seen that Arasaan vendor version number is same as
document revision number.
(At first I had ignored the email because it repeated Mason's email
without quoting, but then I realised it contained some information)
>
> On Mon, Nov 28, 2016 at 10:22 PM, Mason <slash.tmp@free.fr> wrote:
>> On 28/11/2016 17:15, Arnd Bergmann wrote:
>>
>>> On Monday, November 28, 2016 4:44:39 PM CET Mason wrote:
>>>
>>>> Hello,
>>>>
>>>> @Shawn Lin, could you take a look below and tell me exactly
>>>> which IP core(s) Rockchip is using in its SoCs?
>>>>
>>>> Based on the feedback I received, here is an updated list of
>>>> compatible strings and controller versions dealt with by the
>>>> drivers/mmc/host/sdhci-of-arasan.c code.
>>>>
>>>>
>>>> Xilinx Zynq:
>>>> "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller"
>>>> "arasan,sdhci-8.9a"
>>>> NB: 8.9a is the documentation revision (dated 2011-10-19)
>>>> subsequent tweaks labeled 9.0a, 9.1a, 9.2a
>>>>
>>>> Xilinx ZynqMP:
>>>> "SD3.0 / SDIO3.0 / eMMC4.51 AHB Host Controller"
>>>> "arasan,sdhci-8.9a"
>>>> NB: using the same compatible string as Zynq
>>>>
>>>> Sigma SMP87xx
>>>> "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller"
>>>> no compatible string yet, platform-specific init required
>>>>
>>>> APM:
>>>> "SD3.0 / SDIO3.0 / eMMC4.41 AHB Host Controller"
>>>> "arasan,sdhci-4.9a"
>>>> NB: 4.9a appears to be the documentation revision
>>>> no functional diff with "arasan,sdhci-8.9a"
>>>>
>>>> Rockchip
>>>> Exact IP unknown, waiting for Shawn's answer
>>>> "arasan,sdhci-5.1"
>>>> NB: 5.1 appears to refer to the eMMC standard supported
>>>>
>>>>
>>>> On a final note, there are many variations of the Arasan IP.
>>>> I've tracked down at least the following:
>>>>
>>>> SD_2.0_SDIO_2.0__MMC_3.31_AHB_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.41_OCP_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller.pdf
>>>> SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf
>>>> SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller.pdf
>>>> SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller.pdf
>>>>
>>>> It seems to me the compatible string should specify
>>>> the SD/SDIO version AND the eMMC version, since it
>>>> seems many combinations are allowed, e.g. eMMC 4.51
>>>> has two possible SD versions.
>>>>
>>>> What do you think?
>>>
>>> It seems wrong to have the eMMC or SD version in the compatible
>>> string. Is that the only difference between the documents you
>>> found? Normally there should be a version of IP block itself,
>>> besides the supported protocol.
>>
>> But that is exactly the problem :-)
>>
>> Nowhere in the documentation do they specify an "IP version".
>> Some documents do provide a revision number, but that's just
>> a *documentation* revision number, e.g.
>>
>> changes in version 3.6 : fix typos
>> changes in version 9.1a : update company logo
>>
>> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
>> "arasan,sdhci-4.9a". These are documentation revisions.
>> In my opinion, that information is mostly worthless.
>>
>>
>> Looking more closely at SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
>> (User Guide, which has more info than Datasheet) I see this:
>>
>> Changed Host Controller Version Register value from 16'h0002 to 16'h7501
>> Changed Host Controller Version Register value from 16'h8301 to 16'h8401
>> Changed Host Controller Version Register value from 16'h8401 to 16'h8501
>> Changed Host Controller Version Register to 16'h9502
>> Changed Host Controller Version Register to 16'h9602
>> Changed Host Controller Version Register to 16'h9902
>>
>> Host controller version register (offset 0FEh)
>>
>> Vendor Version Number 15:8
>> HwInit=0x99
>> This status is reserved for the vendor version number.
>> The HD should not use this status.
>>
>> Specification Version Number 7:0
>> HwInit=0x02
>> This status indicates the Host Controller Spec. Version.
>> The upper and lower 4-bits indicate the version.
>> Description
>> 00 - SD Host Specification version 1.0
>> 01 - SD Host Specification version 2.00
>> including only the feature of the Test Register
>> 02 - SD Host Specification Version 3.00
>> others - Reserved
>>
>> I'm not sure what this "Vendor Version Number" specifies, nor if is
>> guaranteed to be unique across controllers.
>>
>> In SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller_UserGuide.pdf,
>> they write "The Vendor Version Number is set to 0x10 (1.0)"
>>
>> I don't have a UserGuide for "arasan,sdhci-5.1".
>>
>> Regards.
>>
^ permalink raw reply
* Re: [PATCH v3 1/1] mmc: Hynix: add QUIRK_NOTIFY_POWEROFF_ON_SLEEP
From: Ulf Hansson @ 2016-11-30 10:29 UTC (permalink / raw)
To: Thierry Escande
Cc: Jaehoon Chung, Shawn Lin, Bernie Thompson,
linux-mmc@vger.kernel.org, Alex Lemberg
In-Reply-To: <302c7160-bdb2-d31a-4847-5c066f43feaf@collabora.com>
+Alex
On 30 November 2016 at 10:10, Thierry Escande
<thierry.escande@collabora.com> wrote:
> Hi Jaehoon,
>
> On 30/11/2016 09:46, Jaehoon Chung wrote:
>>
>> On 11/29/2016 11:24 PM, Thierry Escande wrote:
>>>
>>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>>> index df19777..774d478 100644
>>> --- a/drivers/mmc/core/mmc.c
>>> +++ b/drivers/mmc/core/mmc.c
>>> @@ -1941,8 +1941,14 @@ static int _mmc_suspend(struct mmc_host *host,
>>> bool is_suspend)
>>> if (mmc_can_poweroff_notify(host->card) &&
>>> ((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend))
>>> err = mmc_poweroff_notify(host->card, notify_type);
>>> - else if (mmc_can_sleep(host->card))
>>> + else if (mmc_can_sleep(host->card)) {
>>> + if (host->card->quirks &
>>> MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP) {
>>> + err = mmc_poweroff_notify(host->card,
>>> notify_type);
>>> + if (err)
>>> + goto out;
>>> + }
>>> err = mmc_sleep(host);
>>
>>
>> After running mmc_poweroff_notify(), also doing mmc_sleep()? Is it right?
>
>
> Yes, that's what the quirk is intended for. This firmware resumes from sleep
> faster if it has been notified for power-off. This is a recommendation from
> Hynix.
I think we need to discuss this change in the context of eMMC sleep
notification - as a generic solution and conforming to the eMMC spec.
This was also as pointed out by Alex [1]. Perhaps you can respond to
his earlier reply?
>
> Regards,
> Thierry
Kind regards
Uffe
[1]
http://www.spinics.net/lists/linux-mmc/msg39892.html
^ permalink raw reply
* Re: [PATCH 2/4] mmc: sdhci: Fix recovery from tuning timeout
From: Adrian Hunter @ 2016-11-30 10:17 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <CAPDyKFqz36hsJxVJpNcH-Y+gzTOfewPiV3w4LApQOdrQiKLNtg@mail.gmail.com>
On 30/11/16 12:06, Ulf Hansson wrote:
> On 30 November 2016 at 10:20, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> Clearing the tuning bits should reset the tuning circuit. However there is
>> more to do. Reset the command and data lines for good measure, and then
>> for eMMC ensure the card is not still trying to process a tuning command by
>> sending a stop command.
>>
>> Note the JEDEC eMMC specification says the stop command (CMD12) can be used
>> to stop a tuning command (CMD21) whereas the SD specification is silent on
>> the subject with respect to the SD tuning command (CMD19). Considering that
>> CMD12 is not a valid SDIO command, the stop command is sent only when the
>> tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
>> which have been on eMMC.
>>
>> Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
>> data circuits after tuning failure") which is being reverted for v4.9+.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> Tested-by: Dan O'Donovan <dan@emutex.com>
>> Cc: stable@vger.kernel.org
>> ---
>> drivers/mmc/host/sdhci.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index e761fe2aa99e..1d72a51287d4 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -2095,7 +2095,27 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>> ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
>> sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>>
>> + sdhci_do_reset(host, SDHCI_RESET_CMD);
>> + sdhci_do_reset(host, SDHCI_RESET_DATA);
>> +
>> err = -EIO;
>> +
>> + if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
>> + goto out;
>> +
>> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
>> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
>> +
>> + spin_unlock_irqrestore(&host->lock, flags);
>> +
>> + memset(&cmd, 0, sizeof(cmd));
>> + cmd.opcode = MMC_STOP_TRANSMISSION;
>> + cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
>> + cmd.busy_timeout = 50;
>> + mmc_wait_for_cmd(mmc, &cmd, 0);
>
> No, please don't add more hacks to send commands internally from sdhci.
>
> Maybe even before you start fix the problems for tuning, perhaps you
> try to clean up the current code when sending CMD21/19 in
> sdhci_execute_tuning()?
>
> Moreover, according to the change log above, it seems like a generic
> thing to send CMD12 to abort tuning. In such case, we could either
> make the core deal with it in the error path - or we could implement a
> "mmc_abort_tuning()" function, host drivers may call when needed.
I am not sure a cleanup would apply cleanly to stable trees. It would be
nicer to have these patches for stable and then a cleanup on top. Would
that be acceptable?
^ permalink raw reply
* Re: [PATCH 2/4] mmc: sdhci: Fix recovery from tuning timeout
From: Ulf Hansson @ 2016-11-30 10:06 UTC (permalink / raw)
To: Adrian Hunter; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <1480497614-3501-3-git-send-email-adrian.hunter@intel.com>
On 30 November 2016 at 10:20, Adrian Hunter <adrian.hunter@intel.com> wrote:
> Clearing the tuning bits should reset the tuning circuit. However there is
> more to do. Reset the command and data lines for good measure, and then
> for eMMC ensure the card is not still trying to process a tuning command by
> sending a stop command.
>
> Note the JEDEC eMMC specification says the stop command (CMD12) can be used
> to stop a tuning command (CMD21) whereas the SD specification is silent on
> the subject with respect to the SD tuning command (CMD19). Considering that
> CMD12 is not a valid SDIO command, the stop command is sent only when the
> tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
> which have been on eMMC.
>
> Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
> data circuits after tuning failure") which is being reverted for v4.9+.
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Tested-by: Dan O'Donovan <dan@emutex.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/mmc/host/sdhci.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index e761fe2aa99e..1d72a51287d4 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2095,7 +2095,27 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
> ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
> sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>
> + sdhci_do_reset(host, SDHCI_RESET_CMD);
> + sdhci_do_reset(host, SDHCI_RESET_DATA);
> +
> err = -EIO;
> +
> + if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
> + goto out;
> +
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> +
> + spin_unlock_irqrestore(&host->lock, flags);
> +
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.opcode = MMC_STOP_TRANSMISSION;
> + cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
> + cmd.busy_timeout = 50;
> + mmc_wait_for_cmd(mmc, &cmd, 0);
No, please don't add more hacks to send commands internally from sdhci.
Maybe even before you start fix the problems for tuning, perhaps you
try to clean up the current code when sending CMD21/19 in
sdhci_execute_tuning()?
Moreover, according to the change log above, it seems like a generic
thing to send CMD12 to abort tuning. In such case, we could either
make the core deal with it in the error path - or we could implement a
"mmc_abort_tuning()" function, host drivers may call when needed.
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> goto out;
> }
>
> --
> 1.9.1
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH 4/4] mmc: sdhci: Always allow tuning to fall back to fixed sampling
From: Adrian Hunter @ 2016-11-30 9:20 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <1480497614-3501-1-git-send-email-adrian.hunter@intel.com>
SDHCI falls back to fixed sampling if there is an error during tuning.
However it also reports an error unless there is periodic re-tuning.
That is not the best option because:
a) there is a reasonable chance that fixed sampling will work, especially
at room temperature.
b) re-tuning will be done again anyway if there are CRC errors.
Change to return no error always when falling back to fixed sampling.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/host/sdhci.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ad2f2c6113e4..a23887799f43 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2098,8 +2098,6 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
sdhci_do_reset(host, SDHCI_RESET_CMD);
sdhci_do_reset(host, SDHCI_RESET_DATA);
- err = -EIO;
-
if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
goto out;
@@ -2137,24 +2135,10 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
}
- if (!(ctrl & SDHCI_CTRL_TUNED_CLK)) {
+ if (!(ctrl & SDHCI_CTRL_TUNED_CLK))
pr_info(DRIVER_NAME ": Tuning procedure failed, falling back to fixed sampling clock\n");
- err = -EIO;
- }
-
out:
- if (tuning_count) {
- /*
- * In case tuning fails, host controllers which support
- * re-tuning can try tuning again at a later time, when the
- * re-tuning timer expires. So for these controllers, we
- * return 0. Since there might be other controllers who do not
- * have this capability, we return error for them.
- */
- err = 0;
- }
-
- host->mmc->retune_period = err ? 0 : tuning_count;
+ host->mmc->retune_period = tuning_count;
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] mmc: sdhci: Fix tuning reset after exhausting the maximum number of loops
From: Adrian Hunter @ 2016-11-30 9:20 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <1480497614-3501-1-git-send-email-adrian.hunter@intel.com>
If the driver has exhausted the maximum number of tuning loops, then fixed
sampling is used. To do that both SDHCI_CTRL_TUNED_CLK and
SDHCI_CTRL_EXEC_TUNING must be reset to 0, but only SDHCI_CTRL_TUNED_CLK
was being reset. Reset SDHCI_CTRL_EXEC_TUNING to 0 also.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
drivers/mmc/host/sdhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1d72a51287d4..ad2f2c6113e4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2134,6 +2134,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
*/
if (tuning_loop_counter < 0) {
ctrl &= ~SDHCI_CTRL_TUNED_CLK;
+ ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
}
if (!(ctrl & SDHCI_CTRL_TUNED_CLK)) {
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] mmc: sdhci: Fix recovery from tuning timeout
From: Adrian Hunter @ 2016-11-30 9:20 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <1480497614-3501-1-git-send-email-adrian.hunter@intel.com>
Clearing the tuning bits should reset the tuning circuit. However there is
more to do. Reset the command and data lines for good measure, and then
for eMMC ensure the card is not still trying to process a tuning command by
sending a stop command.
Note the JEDEC eMMC specification says the stop command (CMD12) can be used
to stop a tuning command (CMD21) whereas the SD specification is silent on
the subject with respect to the SD tuning command (CMD19). Considering that
CMD12 is not a valid SDIO command, the stop command is sent only when the
tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far
which have been on eMMC.
Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and
data circuits after tuning failure") which is being reverted for v4.9+.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Dan O'Donovan <dan@emutex.com>
Cc: stable@vger.kernel.org
---
drivers/mmc/host/sdhci.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e761fe2aa99e..1d72a51287d4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2095,7 +2095,27 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+ sdhci_do_reset(host, SDHCI_RESET_CMD);
+ sdhci_do_reset(host, SDHCI_RESET_DATA);
+
err = -EIO;
+
+ if (cmd.opcode != MMC_SEND_TUNING_BLOCK_HS200)
+ goto out;
+
+ sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
+ sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+ spin_unlock_irqrestore(&host->lock, flags);
+
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.opcode = MMC_STOP_TRANSMISSION;
+ cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
+ cmd.busy_timeout = 50;
+ mmc_wait_for_cmd(mmc, &cmd, 0);
+
+ spin_lock_irqsave(&host->lock, flags);
+
goto out;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"
From: Adrian Hunter @ 2016-11-30 9:20 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
In-Reply-To: <1480497614-3501-1-git-send-email-adrian.hunter@intel.com>
This reverts commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits
after tuning failure").
A better fix is available, and it will be applied to older stable releases,
so get this out of the way by reverting it.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.9+
---
drivers/mmc/host/sdhci.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 7f2526c9572f..e761fe2aa99e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2090,10 +2090,6 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
if (!host->tuning_done) {
pr_info(DRIVER_NAME ": Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock\n");
-
- sdhci_do_reset(host, SDHCI_RESET_CMD);
- sdhci_do_reset(host, SDHCI_RESET_DATA);
-
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
ctrl &= ~SDHCI_CTRL_TUNED_CLK;
ctrl &= ~SDHCI_CTRL_EXEC_TUNING;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] mmc: sdhci: Fix recovery from tuning timeout
From: Adrian Hunter @ 2016-11-30 9:20 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-mmc, Dan O'Donovan
Hi
Here are some small SDHCI tuning-related fixes.
Adrian Hunter (4):
Revert "mmc: sdhci: Reset cmd and data circuits after tuning failure"
mmc: sdhci: Fix recovery from tuning timeout
mmc: sdhci: Fix tuning reset after exhausting the maximum number of loops
mmc: sdhci: Always allow tuning to fall back to fixed sampling
drivers/mmc/host/sdhci.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
Regards
Adrian
^ permalink raw reply
* Re: [PATCH v3 1/1] mmc: Hynix: add QUIRK_NOTIFY_POWEROFF_ON_SLEEP
From: Thierry Escande @ 2016-11-30 9:10 UTC (permalink / raw)
To: Jaehoon Chung; +Cc: Ulf Hansson, Shawn Lin, bhthompson, linux-mmc
In-Reply-To: <89a61073-6f1e-d386-c2d1-866447bcd715@samsung.com>
Hi Jaehoon,
On 30/11/2016 09:46, Jaehoon Chung wrote:
> On 11/29/2016 11:24 PM, Thierry Escande wrote:
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index df19777..774d478 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1941,8 +1941,14 @@ static int _mmc_suspend(struct mmc_host *host, bool is_suspend)
>> if (mmc_can_poweroff_notify(host->card) &&
>> ((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend))
>> err = mmc_poweroff_notify(host->card, notify_type);
>> - else if (mmc_can_sleep(host->card))
>> + else if (mmc_can_sleep(host->card)) {
>> + if (host->card->quirks & MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP) {
>> + err = mmc_poweroff_notify(host->card, notify_type);
>> + if (err)
>> + goto out;
>> + }
>> err = mmc_sleep(host);
>
> After running mmc_poweroff_notify(), also doing mmc_sleep()? Is it right?
Yes, that's what the quirk is intended for. This firmware resumes from
sleep faster if it has been notified for power-off. This is a
recommendation from Hynix.
Regards,
Thierry
^ permalink raw reply
* Re: [PATCH v3 1/1] mmc: Hynix: add QUIRK_NOTIFY_POWEROFF_ON_SLEEP
From: Jaehoon Chung @ 2016-11-30 8:46 UTC (permalink / raw)
To: Thierry Escande, Ulf Hansson, Shawn Lin; +Cc: bhthompson, linux-mmc
In-Reply-To: <1480429488-22289-2-git-send-email-thierry.escande@collabora.com>
On 11/29/2016 11:24 PM, Thierry Escande wrote:
> From: zhaojohn <john.zhao@intel.com>
>
> Hynix eMMC devices sometimes take 50% longer to resume from sleep. This
> occurs on Braswell based chromebook with acpi sdhci controller.
>
> Based on a recommendation from Hynix engineers, this patch sends a
> Power-Off Notification using mmc_poweroff_notify() before going to S3 to
> have a resume time consistently within spec. No voltage regulator are
> being cut through this notification but merely tells the eMMC firmware
> that we're about to do so and get it to behave better on resume.
>
> Signed-off-by: zhaojohn <john.zhao@intel.com>
> Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
> ---
> drivers/mmc/card/block.c | 8 ++++++++
> drivers/mmc/core/mmc.c | 8 +++++++-
> include/linux/mmc/card.h | 2 ++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 709a872..0066a66 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -2573,6 +2573,14 @@ static const struct mmc_fixup blk_fixups[] =
> MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
> MMC_QUIRK_TRIM_BROKEN),
>
> + /*
> + * Hynix eMMC devices sometimes take 50% longer to resume from sleep.
> + * Based on a recommendation from Hynix, send a Power-Off Notification
> + * before going to S3 to restore a resume time consistently within spec.
> + */
> + MMC_FIXUP("HBG4e\005", CID_MANFID_HYNIX, 0x014a, add_quirk_mmc,
> + MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP),
> +
> END_FIXUP
> };
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index df19777..774d478 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1941,8 +1941,14 @@ static int _mmc_suspend(struct mmc_host *host, bool is_suspend)
> if (mmc_can_poweroff_notify(host->card) &&
> ((host->caps2 & MMC_CAP2_FULL_PWR_CYCLE) || !is_suspend))
> err = mmc_poweroff_notify(host->card, notify_type);
> - else if (mmc_can_sleep(host->card))
> + else if (mmc_can_sleep(host->card)) {
> + if (host->card->quirks & MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP) {
> + err = mmc_poweroff_notify(host->card, notify_type);
> + if (err)
> + goto out;
> + }
> err = mmc_sleep(host);
After running mmc_poweroff_notify(), also doing mmc_sleep()? Is it right?
> + }
> else if (!mmc_host_is_spi(host))
> err = mmc_deselect_cards(host);
>
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 73fad83..e4940f4 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -281,6 +281,8 @@ struct mmc_card {
> #define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could create a fake interrupt */
> #define MMC_QUIRK_TRIM_BROKEN (1<<12) /* Skip trim */
> #define MMC_QUIRK_BROKEN_HPI (1<<13) /* Disable broken HPI support */
> +#define MMC_QUIRK_NOTIFY_POWEROFF_ON_SLEEP \
> + (1<<14) /* Poweroff notification*/
>
>
> unsigned int erase_size; /* erase size in sectors */
>
^ permalink raw reply
* Re: [PATCH V8 05/20] mmc: queue: Factor out mmc_queue_alloc_bounce_sgs()
From: Adrian Hunter @ 2016-11-30 8:46 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <CAPDyKFoD0gKt5F0aDT7-EMUZ2j1xoYNU+0WRypPXCSfdH8WzkQ@mail.gmail.com>
On 30/11/16 10:17, Ulf Hansson wrote:
> On 29 November 2016 at 11:09, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> In preparation for supporting a queue of requests, factor out
>> mmc_queue_alloc_bounce_sgs().
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
>> ---
>> drivers/mmc/card/queue.c | 44 ++++++++++++++++++++++++++++----------------
>> 1 file changed, 28 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
>> index 4497a218c245..3fd27c684292 100644
>> --- a/drivers/mmc/card/queue.c
>> +++ b/drivers/mmc/card/queue.c
>> @@ -211,6 +211,30 @@ static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
>> return true;
>> }
>>
>> +static int mmc_queue_alloc_bounce_sgs(struct mmc_queue *mq,
>> + unsigned int bouncesz)
>
> This causes a compiler warning about unused function, in case when
> CONFIG_MMC_BLOCK_BOUNCE is unset.
> No worries, I fixed it and amended the patch.
Thank you!
^ permalink raw reply
* Re: [PATCH V8 05/20] mmc: queue: Factor out mmc_queue_alloc_bounce_sgs()
From: Ulf Hansson @ 2016-11-30 8:17 UTC (permalink / raw)
To: Adrian Hunter
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-6-git-send-email-adrian.hunter@intel.com>
On 29 November 2016 at 11:09, Adrian Hunter <adrian.hunter@intel.com> wrote:
> In preparation for supporting a queue of requests, factor out
> mmc_queue_alloc_bounce_sgs().
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
> ---
> drivers/mmc/card/queue.c | 44 ++++++++++++++++++++++++++++----------------
> 1 file changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 4497a218c245..3fd27c684292 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -211,6 +211,30 @@ static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
> return true;
> }
>
> +static int mmc_queue_alloc_bounce_sgs(struct mmc_queue *mq,
> + unsigned int bouncesz)
This causes a compiler warning about unused function, in case when
CONFIG_MMC_BLOCK_BOUNCE is unset.
No worries, I fixed it and amended the patch.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH V8 04/20] mmc: queue: Factor out mmc_queue_alloc_bounce_bufs()
From: Ulf Hansson @ 2016-11-30 8:16 UTC (permalink / raw)
To: Adrian Hunter
Cc: linux-mmc, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Jaehoon Chung, Dong Aisheng, Das Asutosh, Zhangfei Gao,
Dorfman Konstantin, David Griego, Sahitya Tummala, Harjani Ritesh,
Venu Byravarasu, Linus Walleij
In-Reply-To: <1480414167-15577-5-git-send-email-adrian.hunter@intel.com>
On 29 November 2016 at 11:09, Adrian Hunter <adrian.hunter@intel.com> wrote:
> In preparation for supporting a queue of requests, factor out
> mmc_queue_alloc_bounce_bufs().
>
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Harjani Ritesh <riteshh@codeaurora.org>
> ---
> drivers/mmc/card/queue.c | 45 +++++++++++++++++++++++++++------------------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 010888d8d97c..4497a218c245 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -186,6 +186,31 @@ static void mmc_queue_setup_discard(struct request_queue *q,
> queue_flag_set_unlocked(QUEUE_FLAG_SECERASE, q);
> }
>
> +static bool mmc_queue_alloc_bounce_bufs(struct mmc_queue *mq,
> + unsigned int bouncesz)
This causes a compiler warning about unused function, in case when
CONFIG_MMC_BLOCK_BOUNCE is unset.
No worries, I fixed it and amended the patch.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [GIT PULL] DWMMC controller for next
From: Ulf Hansson @ 2016-11-30 8:13 UTC (permalink / raw)
To: Jaehoon Chung; +Cc: linux-mmc@vger.kernel.org
In-Reply-To: <657025e2-decd-338e-60e9-f7ebfc7fcbb4@samsung.com>
On 30 November 2016 at 02:39, Jaehoon Chung <jh80.chung@samsung.com> wrote:
> Dear Ulf,
>
> Could you pull these patches for next on your repository?
>
> The following changes since commit b977a3400ee697f80e128e8bb927652026e400da:
>
> mmc: mmc_test: remove BUG_ONs and deploy error handling (2016-11-29 13:40:22 +0100)
>
> are available in the git repository at:
>
> http://github.com/jh80chung/dw-mmc.git for-ulf
>
> for you to fetch changes up to dc595736c5549b82d02fb4217cf68be595e479be:
>
> mmc: dw_mmc: display the clock message only one time when card is polling (2016-11-30 10:36:33 +0900)
>
> ----------------------------------------------------------------
> Jaehoon Chung (3):
> mmc: dw_mmc: check the "present" variable before checking flags
> mmc: dw_mmc: add the debug message for polling and non-removable
> mmc: dw_mmc: display the clock message only one time when card is polling
>
> Joonyoung Shim (2):
> mmc: dw_mmc: exynos: fix to call suspend callback
> mmc: dw_mmc: add missing codes for runtime resume
>
> drivers/mmc/host/dw_mmc-exynos.c | 28 ++++++++++++++++++++++++++--
> drivers/mmc/host/dw_mmc.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
> drivers/mmc/host/dw_mmc.h | 1 +
> 3 files changed, 72 insertions(+), 7 deletions(-)
>
> Best Regards,
> Jaehoon Chung
Thanks Jaehoon, pulled into next!
Kind regards
Uffe
^ permalink raw reply
* [PATCH] mmc: sdhci-s3c: add spin_unlock_irq() before calling clk_round_rate
From: Jaehoon Chung @ 2016-11-30 6:05 UTC (permalink / raw)
To: linux-mmc; +Cc: ulf.hansson, adrian.hunter, Jaehoon Chung
Before calling clk_round_rate(), put the spin_unlock_irq() in
sdhci_s3c_consider_clock() function.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
---
drivers/mmc/host/sdhci-s3c.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 784c5a8..de219ca 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -121,7 +121,9 @@ static unsigned int sdhci_s3c_consider_clock(struct sdhci_s3c *ourhost,
* speed possible with selected clock source and skip the division.
*/
if (ourhost->no_divider) {
+ spin_unlock_irq(&ourhost->host->lock);
rate = clk_round_rate(clksrc, wanted);
+ spin_lock_irq(&ourhost->host->lock);
return wanted - rate;
}
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
From: Masahiro Yamada @ 2016-11-30 4:07 UTC (permalink / raw)
To: linux-mmc
Cc: Adrian Hunter, Ulf Hansson, Masahiro Yamada, devicetree,
Al Cooper, Eric Anholt, Linus Walleij, linux-kernel,
Stefan Wahren, Rob Herring, Andrei Pistirica, Wolfram Sang,
Mark Rutland, Simon Horman, Geert Uytterhoeven
In-Reply-To: <1480478865-5271-1-git-send-email-yamada.masahiro@socionext.com>
Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.
For SD, it basically relies on the SDHCI standard code.
For eMMC, this driver provides some platform specific callbacks to
control the part of hardware that is specific to this IP design.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
.../devicetree/bindings/mmc/sdhci-cadence.txt | 31 +++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-cadence.c | 279 +++++++++++++++++++++
4 files changed, 323 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
create mode 100644 drivers/mmc/host/sdhci-cadence.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
new file mode 100644
index 0000000..c18aaee
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -0,0 +1,31 @@
+* Cadence SD/SDIO/eMMC Host Controller
+
+Required properties:
+- compatible: should be "cdns,sd4hc".
+- reg: offset and length of the register set for the device. The region should
+ contain both Host Register Set (HRS) and Slot Register Set (SRS).
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+For eMMC configuration, supported speed modes are not provided by the SDHCI
+Capabilities Register. Instead, the following properties should be specified
+if supported. See mmc.txt for details.
+- mmc-ddr-1_8v
+- mmc-ddr-1_2v
+- mmc-hs200-1_8v
+- mmc-hs200-1_2v
+- mmc-hs400-1_8v
+- mmc-hs400-1_2v
+
+Example:
+ emmc: sdhci@5a000000 {
+ compatible = "cdns,sd4hc";
+ reg = <0x5a000000 0x400>;
+ interrupts = <0 78 4>;
+ clocks = <&clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 580b5a1..c1308ad 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -165,6 +165,18 @@ config MMC_SDHCI_OF_HLWD
If unsure, say N.
+config MMC_SDHCI_CADENCE
+ tristate "SDHCI support for the Cadence SD/SDIO/eMMC controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ select MMC_SDHCI_IO_ACCESSORS
+ help
+ This selects the Cadence SD/SDIO/eMMC driver.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_SDHCI_CNS3XXX
tristate "SDHCI support on the Cavium Networks CNS3xxx SoC"
depends on ARCH_CNS3XXX
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e49a82a..55f7193 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
+obj-$(CONFIG_MMC_SDHCI_CADENCE) += sdhci-cadence.o
obj-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
new file mode 100644
index 0000000..ed49425
--- /dev/null
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/bitops.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mmc/host.h>
+
+#include "sdhci-pltfm.h"
+
+/* HRS - Host Register Set (specific to Cadence) */
+#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
+#define SDHCI_CDNS_HRS04_ACK BIT(26)
+#define SDHCI_CDNS_HRS04_RD BIT(25)
+#define SDHCI_CDNS_HRS04_WR BIT(24)
+#define SDHCI_CDNS_HRS04_RDATA_SHIFT 12
+#define SDHCI_CDNS_HRS04_WDATA_SHIFT 8
+#define SDHCI_CDNS_HRS04_ADDR_SHIFT 0
+
+#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
+#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
+#define SDHCI_CDNS_HRS06_TUNE_SHIFT 8
+#define SDHCI_CDNS_HRS06_TUNE_MASK 0x3f
+#define SDHCI_CDNS_HRS06_MODE_MASK 0x7
+#define SDHCI_CDNS_HRS06_MODE_SD 0x0
+#define SDHCI_CDNS_HRS06_MODE_MMC_SDR 0x2
+#define SDHCI_CDNS_HRS06_MODE_MMC_DDR 0x3
+#define SDHCI_CDNS_HRS06_MODE_MMC_HS200 0x4
+#define SDHCI_CDNS_HRS06_MODE_MMC_HS400 0x5
+
+/* PHY */
+#define SDHCI_CDNS_PHY_DLY_SD_HS 0x00
+#define SDHCI_CDNS_PHY_DLY_SD_DEFAULT 0x01
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR12 0x02
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR25 0x03
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR50 0x04
+#define SDHCI_CDNS_PHY_DLY_UHS_DDR50 0x05
+#define SDHCI_CDNS_PHY_DLY_EMMC_LEGACY 0x06
+#define SDHCI_CDNS_PHY_DLY_EMMC_SDR 0x07
+#define SDHCI_CDNS_PHY_DLY_EMMC_DDR 0x08
+
+/* SRS - Slot Register Set (SDHCI-compatible) */
+#define SDHCI_CDNS_SRS_BASE 0x200
+
+/*
+ * The tuned val register is 6 bit-wide, but not the whole of the range is
+ * available. The range 0-42 seems to be available (then 43 wraps around to 0)
+ * but I am not quite sure if it is official. Use only 0 to 39 for safety.
+ */
+#define SDHCI_CDNS_MAX_TUNING_LOOP 40
+
+struct sdhci_cdns_priv {
+ void __iomem *hrs_addr;
+};
+
+static void sdhci_cdns_write_phy_reg(struct sdhci_cdns_priv *priv,
+ u8 addr, u8 data)
+{
+ void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS04;
+ u32 val;
+
+ val = (data << SDHCI_CDNS_HRS04_WDATA_SHIFT) |
+ (addr << SDHCI_CDNS_HRS04_ADDR_SHIFT);
+ writel(val, reg);
+
+ val |= SDHCI_CDNS_HRS04_WR;
+ writel(val, reg);
+
+ val &= ~SDHCI_CDNS_HRS04_WR;
+ writel(val, reg);
+}
+
+static void sdhci_cdns_phy_init(struct sdhci_cdns_priv *priv)
+{
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_SD_HS, 4);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_SD_DEFAULT, 4);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_LEGACY, 9);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_SDR, 2);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_DDR, 3);
+}
+
+static inline void *sdhci_cdns_priv(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ return sdhci_pltfm_priv(pltfm_host);
+}
+
+static unsigned int sdhci_cdns_get_timeout_clock(struct sdhci_host *host)
+{
+ /*
+ * Cadence's spec says the Timeout Clock Frequency is the same as the
+ * Base Clock Frequency. Divide it by 1000 to return a value in kHz.
+ */
+ return host->max_clk / 1000;
+}
+
+static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
+{
+ struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+ void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS06;
+ u32 tmp;
+
+ if (WARN_ON(val > SDHCI_CDNS_HRS06_TUNE_MASK))
+ return -EINVAL;
+
+ tmp = readl(reg);
+ tmp &= ~(SDHCI_CDNS_HRS06_TUNE_MASK << SDHCI_CDNS_HRS06_TUNE_SHIFT);
+ tmp |= val << SDHCI_CDNS_HRS06_TUNE_SHIFT;
+ tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
+ writel(tmp, reg);
+
+ return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
+ 0, 1);
+}
+
+static int sdhci_cdns_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ int max_streak = 0;
+ int cur_streak = 0;
+ int end_of_streak, i;
+
+ /*
+ * This handler only implements the eMMC tuning that is specific to
+ * this controller. Fall back to the standard method for SD timing.
+ */
+ if (host->timing != MMC_TIMING_MMC_HS200)
+ return -ENOTSUPP;
+
+ if (WARN_ON(opcode != MMC_SEND_TUNING_BLOCK_HS200))
+ return -EINVAL;
+
+ for (i = 0; i < SDHCI_CDNS_MAX_TUNING_LOOP; i++) {
+ if (sdhci_cdns_set_tune_val(host, i) ||
+ mmc_send_tuning(host->mmc, opcode, NULL)) { /* bad */
+ cur_streak = 0;
+ } else { /* good */
+ cur_streak++;
+ max_streak = max(max_streak, cur_streak);
+ end_of_streak = i;
+ }
+ }
+
+ if (!max_streak) {
+ dev_err(mmc_dev(host->mmc), "no tuning point found\n");
+ return -EIO;
+ }
+
+ return sdhci_cdns_set_tune_val(host, end_of_streak - max_streak / 2);
+}
+
+static void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
+ unsigned int timing)
+{
+ struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+ u32 mode, tmp;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_SDR;
+ break;
+ case MMC_TIMING_MMC_DDR52:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_DDR;
+ break;
+ case MMC_TIMING_MMC_HS200:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_HS200;
+ break;
+ case MMC_TIMING_MMC_HS400:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_HS400;
+ break;
+ default:
+ mode = SDHCI_CDNS_HRS06_MODE_SD;
+ break;
+ }
+
+ /* The speed mode for eMMC is selected by HRS06 register */
+ tmp = readl(priv->hrs_addr + SDHCI_CDNS_HRS06);
+ tmp &= ~SDHCI_CDNS_HRS06_MODE_MASK;
+ tmp |= mode;
+ writel(tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
+
+ /* For SD, fall back to the default handler */
+ if (mode == SDHCI_CDNS_HRS06_MODE_SD)
+ sdhci_set_uhs_signaling(host, timing);
+}
+
+static const struct sdhci_ops sdhci_cdns_ops = {
+ .set_clock = sdhci_set_clock,
+ .get_timeout_clock = sdhci_cdns_get_timeout_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .platform_execute_tuning = sdhci_cdns_execute_tuning,
+ .set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
+};
+
+static const struct sdhci_pltfm_data sdhci_cdns_pltfm_data = {
+ .ops = &sdhci_cdns_ops,
+};
+
+static int sdhci_cdns_probe(struct platform_device *pdev)
+{
+ struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_cdns_priv *priv;
+ struct clk *clk;
+ int ret;
+
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ return ret;
+
+ host = sdhci_pltfm_init(pdev, &sdhci_cdns_pltfm_data, sizeof(*priv));
+ if (IS_ERR(host)) {
+ ret = PTR_ERR(host);
+ goto disable_clk;
+ }
+
+ pltfm_host = sdhci_priv(host);
+ pltfm_host->clk = clk;
+
+ priv = sdhci_cdns_priv(host);
+ priv->hrs_addr = host->ioaddr;
+ host->ioaddr += SDHCI_CDNS_SRS_BASE;
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret)
+ goto free;
+
+ sdhci_cdns_phy_init(priv);
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto free;
+
+ return 0;
+free:
+ sdhci_pltfm_free(pdev);
+disable_clk:
+ clk_disable_unprepare(clk);
+
+ return ret;
+}
+
+static const struct of_device_id sdhci_cdns_match[] = {
+ { .compatible = "cdns,sd4hc" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sdhci_cdns_match);
+
+static struct platform_driver sdhci_cdns_driver = {
+ .driver = {
+ .name = "sdhci-cdns",
+ .pm = &sdhci_pltfm_pmops,
+ .of_match_table = sdhci_cdns_match,
+ },
+ .probe = sdhci_cdns_probe,
+ .remove = sdhci_pltfm_unregister,
+};
+module_platform_driver(sdhci_cdns_driver);
+
+MODULE_AUTHOR("Masahiro Yamada <yamada.masahiro@socionext.com>");
+MODULE_DESCRIPTION("Cadence SD/SDIO/eMMC Host Controller Driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] mmc: sdhci: continue normal tuning if unsupported by platform tuning
From: Masahiro Yamada @ 2016-11-30 4:07 UTC (permalink / raw)
To: linux-mmc; +Cc: Adrian Hunter, Ulf Hansson, Masahiro Yamada, linux-kernel
In-Reply-To: <1480478865-5271-1-git-send-email-yamada.masahiro@socionext.com>
Some SDHCI-compat controllers support not only SD, but also eMMC,
but they use different commands for tuning: CMD19 for SD, CMD21 for
eMMC.
Due to the difference of the underlying mechanism, some controllers
(at least, the Cadence IP is the case) provide their own registers
for the eMMC tuning.
This commit will be useful when we want to use platform-specific
tuning (to support eMMC HS200), but still let it reuse the code
provided by sdhci_execute_tuning() for SD timing.
If sdhci_ops::platform_execute_tuning receives a timing it does not
take care of, it can return -ENOTSUPP. Then, it will fall back to
the SDHCI standard tuning.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
I want to use this in the next commit.
The Cadence IP supports eMMC as well as SD.
The tuning for SD is pretty simple; just set the "Execute Tuning" bit
of the HOST_CONTROL2 register. So, I can re-use the
sdhci_execute_tuning().
On the other hand, Cadence provides its own way for eMMC HS200 tuning;
I need to touch some registers that are specific to Cadence's design.
drivers/mmc/host/sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 42ef3eb..cdce489 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2004,7 +2004,9 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
if (host->ops->platform_execute_tuning) {
spin_unlock_irqrestore(&host->lock, flags);
err = host->ops->platform_execute_tuning(host, opcode);
- return err;
+ if (err != -ENOTSUPP)
+ return err;
+ spin_lock_irqsave(&host->lock, flags);
}
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] mmc: sdhci: one expansion for SDHCI base code and add Cadence SDHCI driver
From: Masahiro Yamada @ 2016-11-30 4:07 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: Adrian Hunter, Ulf Hansson, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA, Al Cooper, Eric Anholt,
Linus Walleij, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Wahren,
Rob Herring, Andrei Pistirica, Wolfram Sang, Mark Rutland,
Simon Horman, Geert Uytterhoeven
1/2 tweaks sdhci_execute_tuning(), which I want to use for 2/2.
2/2 adds a new driver for Cadence's controller IP.
Masahiro Yamada (2):
mmc: sdhci: continue normal tuning if unsupported by platform tuning
mmc: sdhci-cadence: add Cadence SD4HC support
.../devicetree/bindings/mmc/sdhci-cadence.txt | 31 +++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-cadence.c | 279 +++++++++++++++++++++
drivers/mmc/host/sdhci.c | 4 +-
5 files changed, 326 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
create mode 100644 drivers/mmc/host/sdhci-cadence.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] DWMMC controller for next
From: Jaehoon Chung @ 2016-11-30 1:39 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org; +Cc: Ulf Hansson, Jaehoon Chung
Dear Ulf,
Could you pull these patches for next on your repository?
The following changes since commit b977a3400ee697f80e128e8bb927652026e400da:
mmc: mmc_test: remove BUG_ONs and deploy error handling (2016-11-29 13:40:22 +0100)
are available in the git repository at:
http://github.com/jh80chung/dw-mmc.git for-ulf
for you to fetch changes up to dc595736c5549b82d02fb4217cf68be595e479be:
mmc: dw_mmc: display the clock message only one time when card is polling (2016-11-30 10:36:33 +0900)
----------------------------------------------------------------
Jaehoon Chung (3):
mmc: dw_mmc: check the "present" variable before checking flags
mmc: dw_mmc: add the debug message for polling and non-removable
mmc: dw_mmc: display the clock message only one time when card is polling
Joonyoung Shim (2):
mmc: dw_mmc: exynos: fix to call suspend callback
mmc: dw_mmc: add missing codes for runtime resume
drivers/mmc/host/dw_mmc-exynos.c | 28 ++++++++++++++++++++++++++--
drivers/mmc/host/dw_mmc.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
drivers/mmc/host/dw_mmc.h | 1 +
3 files changed, 72 insertions(+), 7 deletions(-)
Best Regards,
Jaehoon Chung
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2016-11-30 1:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CABxcv=nEih8xX4fM0eqjkqprdt1uGTEyx5tzK04GuSgsHc=Haw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
<javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org> wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
> <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
>> ---
>> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
>> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
>> drivers/mmc/core/Kconfig | 10 ++
>> drivers/mmc/core/Makefile | 1 +
>> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
>> 5 files changed, 146 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.
Ok will do.
>
>> new file mode 100644
>> index 000000000000..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>
Makes sense to me.
>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>
The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>> + }
>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...
Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.
>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>> so that the wifi chip can wakeup host platform under certain condition.
>> during system resume, the irq will be disabled to make sure
>> unnecessary interrupt is not received.
>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> + for documentation of MMC power sequence bindings.
>>
>> Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
>> &mmc3 {
>> status = "okay";
>> vmmc-supply = <&wlan_en_reg>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Javier Martinez Canillas @ 2016-11-29 17:13 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <1479434109-8745-1-git-send-email-matt@ranostay.consulting>
Hello Matt,
On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
<matt@ranostay.consulting> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
> drivers/mmc/core/Kconfig | 10 ++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
> 5 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
According Documentation/devicetree/bindings/submitting-patches.txt,
the DT bindings patches should posted as a separate patch.
> new file mode 100644
> index 000000000000..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".
Since this is not a generic binding, the compatible string should have
a vendor prefix.
> +- pwndn-gpio: contains a power down GPIO specifier.
> +- reset-gpio: contains a reset GPIO specifier.
> +
I wonder if we really need a custom power sequence provider for just
this SDIO WiFI chip though. AFAICT the only missing piece in
mmc-pwrseq-simple is the power down GPIO property, so maybe
mmc-pwrseq-simple could be extended instead to have an optional
powerdown-gpios property and instead in the Marvell SD8787 DT binding
can be mentioned which mmc-pwrseq-simple properties are required for
the device.
> +Example:
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-sd8787";
> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
> + }
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
Does this patch depend on a previous posted series? I don't see this
file in today's linux-next...
> index c421aba0a5bc..08fd65d35725 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -32,6 +32,9 @@ Optional properties:
> so that the wifi chip can wakeup host platform under certain condition.
> during system resume, the irq will be disabled to make sure
> unnecessary interrupt is not received.
> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> + for documentation of MMC power sequence bindings.
>
> Example:
>
> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
> &mmc3 {
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
I think this change should be split in a separate patch as well.
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2016-11-29 16:53 UTC (permalink / raw)
To: Rob Herring
Cc: Matt Ranostay, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Mark Rutland,
Srinivas Kandagatla
In-Reply-To: <CAL_Jsq+80LAkCGEdP5T0AWFV2nRtZ8nrkBoNRB47CR9JN=9dog@mail.gmail.com>
On 29 November 2016 at 15:51, Rob Herring <robh@kernel.org> wrote:
> On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> [...]
>>
>>>> +
>>>> +Example:
>>>> +
>>>> + wifi_pwrseq: wifi_pwrseq {
>>>> + compatible = "mmc-pwrseq-sd8787";
>>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>>> + }
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> index c421aba0a5bc..08fd65d35725 100644
>>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> @@ -32,6 +32,9 @@ Optional properties:
>>>> so that the wifi chip can wakeup host platform under certain condition.
>>>> during system resume, the irq will be disabled to make sure
>>>> unnecessary interrupt is not received.
>>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>>
>>> This is why pwrseq is wrong. You have some properties in the card node
>>> and some in pwrseq node. Everything should be in the card node.
>>
>> Put "all" in the card node, just doesn't work for MMC. Particular in
>> cases when we have removable cards, as then it would be wrong to have
>> a card node.
>
> When is there a problem with removable cards? The connector is
> standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
> the host controller node. If that isn't sufficient, then we should
> start defining a connector node.
I probably didn't get your point. Anyway, let's try again.
I don't see any problems with removable cards and neither with
non-removable cards.
Normally, we don't need a connector node, but instead we put the
related properties/phandles in the host controller node. This works
fine!
For SDIO func devices, sometimes we need a child node of the host
controller node, as to be able to describe certain characteristics of
the SDIO func device. So this case is kind of a special type of card
node (because one can have several SDIO func devices attached, even if
this isn't used).
Now, to follow the current bindings, we must not put connector related
bindings in the card node, like the vmmc-supply, perhaps that is what
causes confusion here?
>
>> The mmc pwrseq DT bindings just follows the legacy approach for MMC
>> and that's why the pwrseq handle is at the controller node. Yes, would
>> could have done it differently, but this is the case now, so we will
>> have to accept that.
>
> We're stuck with supporting the existing cases. That doesn't mean
> we're stuck with the same thing for new cases.
Agree!
But I think there is nothing to improve in this case, or am I wrong?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Rob Herring @ 2016-11-29 14:51 UTC (permalink / raw)
To: Ulf Hansson
Cc: Matt Ranostay,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CAPDyKFr=TE+EuZ9rZV3ygsjBFN_mRrE2imkFa-wQs_ykM5d+cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> [...]
>
>>> +
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>> so that the wifi chip can wakeup host platform under certain condition.
>>> during system resume, the irq will be disabled to make sure
>>> unnecessary interrupt is not received.
>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>
>> This is why pwrseq is wrong. You have some properties in the card node
>> and some in pwrseq node. Everything should be in the card node.
>
> Put "all" in the card node, just doesn't work for MMC. Particular in
> cases when we have removable cards, as then it would be wrong to have
> a card node.
When is there a problem with removable cards? The connector is
standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
the host controller node. If that isn't sufficient, then we should
start defining a connector node.
> The mmc pwrseq DT bindings just follows the legacy approach for MMC
> and that's why the pwrseq handle is at the controller node. Yes, would
> could have done it differently, but this is the case now, so we will
> have to accept that.
We're stuck with supporting the existing cases. That doesn't mean
we're stuck with the same thing for new cases.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] mmc: block: delete packed command support
From: Linus Walleij @ 2016-11-29 14:25 UTC (permalink / raw)
To: Alex Lemberg
Cc: Ulf Hansson, linux-mmc@vger.kernel.org, Chunyan Zhang,
Baolin Wang, Namjae Jeon, Maya Erez, Christoph Hellwig
In-Reply-To: <50128E8A-D7B3-49E3-9E18-4AD240F1EBD0@sandisk.com>
On Sun, Nov 27, 2016 at 3:25 PM, Alex Lemberg <Alex.Lemberg@sandisk.com> wrote:
> I understand your concerns about the current packed commands
> support and the problem of transition to blk_mq.
It may be possible to re-implement the feature later, but then
only if we get some queue inspection features in blk-mq.
Do you agree with my assessment in the thread that this
feature can only really make an improvement on random writes,
i.e. it will not improve reads (even random reads) and it will not
improve sequential writes?
> But as I mentioned in previous email thread, the packed commands
> feature is still in use on eMMC4.5 or eMMC5.1 devices on hosts
> without SW/HW CMDQ support.
True. In the market place of devices, sure.
But noone is maintaining or testing the code in the Linux
kernel. Noone bothered to enable it for their platform so we can
test it.
> Taking this feature out meaning stop supporting one of important
> performance features of eMMC devices.
> Looking forward this feature is replaced with a CMDQ, but should we
> kill it for those who doesn’t have a CMDQ?
What we need from memory card vendors like you (SanDisk)
is a target test rig.
That is: a board with an SoC that we developers can get hold
of (for reasonable cost) and where both the host controller and
the eMMC card has the desired features so we can test it.
Also that this board has support in the upstream kernel.
There are too many vendor trees with too much forked code
out there, I know this is common, but we cannot develop
important core features in the kernel that have no in-kernel
user and no way for us to test it if we need to re-write the
code, it is just unmaintainable.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox