Hi everyone,
This series fixes and re-enables eMMC HS-DDR support for Allwinner A80 SoC.
The issue with the original code was the mmc clock timings were incorrect,
and thus we had disabled HS-DDR on A80 for the previous release.
Patch 1 is a fix for mmc core. Arnd's patch to remove IS_ERR_VALUE replaced
it with an incorrect check on return values, thus blocking the code path
for HS-DDR and higher timing modes. This patch instead checks for a positive
return code, which is how mmc_select_bus_width indicates a success.
Patch 2 fixes the HS-DDR clock timings for the A80.
Patch 3 re-enables HS-DDR mode for the A80.
Regards
ChenYu
Chen-Yu Tsai (3):
mmc: fix mmc mode selection for HS-DDR and higher
mmc: sunxi: Fix DDR MMC timings for A80
mmc: sunxi: Re-enable eMMC HS-DDR modes on Allwinner A80
drivers/mmc/core/mmc.c | 4 ++--
drivers/mmc/host/sunxi-mmc.c | 9 ++-------
2 files changed, 4 insertions(+), 9 deletions(-)
--
2.8.1
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Krzysztof Kozlowski <hidden> Date: 2016-05-31 09:30:38
On Sun, May 29, 2016 at 9:04 AM, Chen-Yu Tsai [off-list ref] wrote:
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski <redacted>
Could you be so kind and pick it up as fast as possible for current
RC? Half of my boards fail (because they work on eMMC) so testing
patches before applying is limited.
Best regards,
Krzysztof
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Best Regards,
Jaehoon Chung
From: Shawn Lin <shawn.lin@rock-chips.com> Date: 2016-06-01 02:37:42
On 2016/5/29 15:04, Chen-Yu Tsai wrote:
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
On Sun, 2016-05-29 at 15:04 +0800, Chen-Yu Tsai wrote:
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value
checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR
unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
This fixes the following eMMC issue as experienced on Apalis T30 as
well:
[????7.194625] mmc1: mmc_select_hs200 failed, error 3
[????7.201549] mmc1: error 3 whilst initialising MMC card
Tested-by: Marcel Ziswiler <redacted>
On Sun, May 29, 2016 at 12:04 AM, Chen-Yu Tsai [off-list ref] wrote:
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
mmc_select_bus_width() can return 0 on "success" as well and the
previous check was !IS_ERR_VALUE(err), which coverts that. So I
believe these checks should be for err >= 0 rather than just > 0.
Either way this fixes the boot failures seen on my Qualcomm based
boards with v4.7-rc1.
Regards,
Bjorn
On Thu, Jun 2, 2016 at 2:58 AM, Bjorn Andersson
[off-list ref] wrote:
On Sun, May 29, 2016 at 12:04 AM, Chen-Yu Tsai [off-list ref] wrote:
quoted
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
mmc_select_bus_width() can return 0 on "success" as well and the
previous check was !IS_ERR_VALUE(err), which coverts that. So I
believe these checks should be for err >= 0 rather than just > 0.
From the comments above the function:
"Zero is returned instead of error value if the wide width is not supported."
The documents I found, which were more vendor datasheets, only list
bit widths 4 and 8 for high speed SDR/DDR and HS200.
Not sure what the MMC spec actually says though, as I do not have
it.
Regards
ChenYu
Either way this fixes the boot failures seen on my Qualcomm based
boards with v4.7-rc1.
Regards,
Bjorn
+ Linus
On 29 May 2016 at 09:04, Chen-Yu Tsai [off-list ref] wrote:
quoted hunk
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card)*switchtoHS200modeifbuswidthissetsuccessfully.*/err=mmc_select_bus_width(card);-if(!err){+if(err>0){val=EXT_CSD_TIMING_HS200|card->drive_strength<<EXT_CSD_DRV_STR_SHIFT;err=__mmc_switch(card,EXT_CSD_CMD_SET_NORMAL,
@@ -1583,7 +1583,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,}elseif(mmc_card_hs(card)){/* Select the desired bus width optionally */err=mmc_select_bus_width(card);-if(!err){+if(err>0){
As pointed out in the review by Bj?rn, to restore the old behaviour we
should check for "err >= 0".
No need to send a new patch, I can amend the current version.
err = mmc_select_hs_ddr(card);
if (err)
goto free_card;
--
2.8.1
Finally, I am a little concerned about the commit 287980e49ffc
("remove lots of IS_ERR_VALUE abuses") which introduced this
regression.
Surprisingly the IS_ERR_VALUE():s aren't being replaced by equivalent
checks, so perhaps there a more regressions. Moreover, I wonder why I
wasn't being on cc/to list when this patch was submitted a few days
ago, perhaps my review could prevented the regression from even
happen.
Anyway, let's fix this now! I will pick up $subject patch as fix asap...
and Arnd, can you please double-check that the commit 287980e49ffc
doesn?t seems to regress anything else!?
Kind regards
Uffe
From: Krzysztof Kozlowski <hidden> Date: 2016-06-02 09:35:28
On Thu, Jun 2, 2016 at 10:31 AM, Ulf Hansson [off-list ref] wrote:
+ Linus
On 29 May 2016 at 09:04, Chen-Yu Tsai [off-list ref] wrote:
quoted
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card)*switchtoHS200modeifbuswidthissetsuccessfully.*/err=mmc_select_bus_width(card);-if(!err){+if(err>0){val=EXT_CSD_TIMING_HS200|card->drive_strength<<EXT_CSD_DRV_STR_SHIFT;err=__mmc_switch(card,EXT_CSD_CMD_SET_NORMAL,
@@ -1583,7 +1583,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,}elseif(mmc_card_hs(card)){/* Select the desired bus width optionally */err=mmc_select_bus_width(card);-if(!err){+if(err>0){
As pointed out in the review by Bj?rn, to restore the old behaviour we
should check for "err >= 0".
No need to send a new patch, I can amend the current version.
quoted
err = mmc_select_hs_ddr(card);
if (err)
goto free_card;
--
2.8.1
Finally, I am a little concerned about the commit 287980e49ffc
("remove lots of IS_ERR_VALUE abuses") which introduced this
regression.
Surprisingly the IS_ERR_VALUE():s aren't being replaced by equivalent
checks, so perhaps there a more regressions. Moreover, I wonder why I
wasn't being on cc/to list when this patch was submitted a few days
ago, perhaps my review could prevented the regression from even
happen.
Anyway, let's fix this now! I will pick up $subject patch as fix asap...
and Arnd, can you please double-check that the commit 287980e49ffc
doesn?t seems to regress anything else!?
If only the 287980e49ffc could sit in linux-next for few days before
reaching v4.7-rc1... Could you please pick up the fix soon? Maybe
directly by Linus?
Best regards,
Krzysztof
On 2 June 2016 at 11:35, Krzysztof Kozlowski [off-list ref] wrote:
On Thu, Jun 2, 2016 at 10:31 AM, Ulf Hansson [off-list ref] wrote:
quoted
+ Linus
On 29 May 2016 at 09:04, Chen-Yu Tsai [off-list ref] wrote:
quoted
When IS_ERR_VALUE was removed from the mmc core code, it was replaced
with a simple not-zero check. This does not work, as the value checked
is the return value for mmc_select_bus_width, which returns the set
bit width on success. This made eMMC modes higher than HS-DDR unusable.
Fix this by checking for a positive return value instead.
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card)*switchtoHS200modeifbuswidthissetsuccessfully.*/err=mmc_select_bus_width(card);-if(!err){+if(err>0){val=EXT_CSD_TIMING_HS200|card->drive_strength<<EXT_CSD_DRV_STR_SHIFT;err=__mmc_switch(card,EXT_CSD_CMD_SET_NORMAL,
@@ -1583,7 +1583,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,}elseif(mmc_card_hs(card)){/* Select the desired bus width optionally */err=mmc_select_bus_width(card);-if(!err){+if(err>0){
As pointed out in the review by Bj?rn, to restore the old behaviour we
should check for "err >= 0".
No need to send a new patch, I can amend the current version.
quoted
err = mmc_select_hs_ddr(card);
if (err)
goto free_card;
--
2.8.1
Finally, I am a little concerned about the commit 287980e49ffc
("remove lots of IS_ERR_VALUE abuses") which introduced this
regression.
Surprisingly the IS_ERR_VALUE():s aren't being replaced by equivalent
checks, so perhaps there a more regressions. Moreover, I wonder why I
wasn't being on cc/to list when this patch was submitted a few days
ago, perhaps my review could prevented the regression from even
happen.
Anyway, let's fix this now! I will pick up $subject patch as fix asap...
and Arnd, can you please double-check that the commit 287980e49ffc
doesn?t seems to regress anything else!?
If only the 287980e49ffc could sit in linux-next for few days before
reaching v4.7-rc1... Could you please pick up the fix soon? Maybe
directly by Linus?
The fix has already been applied and published through my mmc tree. I
am waiting for reports from kernelci, assuming those will be okay, I
will send a PR tomorrow so it should reach rc2.
Kind regards
Uffe
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.
The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/host/sunxi-mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Hans de Goede <hidden> Date: 2016-05-30 11:34:49
Hi,
On 29-05-16 09:04, Chen-Yu Tsai wrote:
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.
Hmm, I'm not really all that familiar with mmc, but can't an external
sdcard connected to mmc0 use DDR too ? Assuming the answer is yes, then
we really need to update the driver to use the right per controller
timings.
The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
If you're sure the timings are wrong, please fix them. Sometimes wrong
timings do seem to work, but lead to unreliable communication, or turn
out to work on some boards and not on others due to routing differences.
Thanks & Regards,
Hans
On Mon, May 30, 2016 at 7:34 PM, Hans de Goede [off-list ref] wrote:
Hi,
On 29-05-16 09:04, Chen-Yu Tsai wrote:
quoted
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.
Hmm, I'm not really all that familiar with mmc, but can't an external
sdcard connected to mmc0 use DDR too ? Assuming the answer is yes, then
we really need to update the driver to use the right per controller
timings.
I would very much like that to happen. However, SD card UHS-1 DDR modes
require 1.8V signaling, which is unavailable on _all_ sunxi boards.
This seems like a limit of most of the SoCs not having a separate IO
voltage rail for mmc pins.
Until then, I wouldn't worry that much.
quoted
The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
If you're sure the timings are wrong, please fix them. Sometimes wrong
timings do seem to work, but lead to unreliable communication, or turn
out to work on some boards and not on others due to routing differences.
Unfortunately I did try putting in the correct numbers for them, and my
eMMC then failed to probe. It seems the core switches up from 400kHz to
50MHz then to 50MHz DDR, and it fails somewhere in there, maybe at 50MHz.
I'm not sure if we need to add DT bindings to specify different delays
for different controllers, though. Seems like we'll never actually use
it.
Hope this answers your questions.
Regards
ChenYu
On Mon, May 30, 2016 at 8:59 PM, Chen-Yu Tsai [off-list ref] wrote:
On Mon, May 30, 2016 at 7:34 PM, Hans de Goede [off-list ref] wrote:
quoted
Hi,
On 29-05-16 09:04, Chen-Yu Tsai wrote:
quoted
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.
Hmm, I'm not really all that familiar with mmc, but can't an external
sdcard connected to mmc0 use DDR too ? Assuming the answer is yes, then
we really need to update the driver to use the right per controller
timings.
I would very much like that to happen. However, SD card UHS-1 DDR modes
require 1.8V signaling, which is unavailable on _all_ sunxi boards.
This seems like a limit of most of the SoCs not having a separate IO
voltage rail for mmc pins.
Until then, I wouldn't worry that much.
P.S. I also tried the settings from mmc0 in Allwinner sources. They gave
horrible results ( < 5 MB/s read ) on my CC-A80, while my Optimus wasn't
really affected. I wonder if there's some kind of auto-retry mechanism
in the MMC controller, or driver?
ChenYu
quoted
quoted
The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
If you're sure the timings are wrong, please fix them. Sometimes wrong
timings do seem to work, but lead to unreliable communication, or turn
out to work on some boards and not on others due to routing differences.
Unfortunately I did try putting in the correct numbers for them, and my
eMMC then failed to probe. It seems the core switches up from 400kHz to
50MHz then to 50MHz DDR, and it fails somewhere in there, maybe at 50MHz.
I'm not sure if we need to add DT bindings to specify different delays
for different controllers, though. Seems like we'll never actually use
it.
Hope this answers your questions.
Regards
ChenYu
From: Hans de Goede <hidden> Date: 2016-05-30 18:05:36
Hi,
On 30-05-16 14:59, Chen-Yu Tsai wrote:
On Mon, May 30, 2016 at 7:34 PM, Hans de Goede [off-list ref] wrote:
quoted
Hi,
On 29-05-16 09:04, Chen-Yu Tsai wrote:
quoted
The MMC clock timings were incorrectly calculated, when the conversion
from delay value to delay phase was done.
The 50M DDR and 50M DDR 8bit timings are off, and make eMMC DDR
unusable. Unfortunately it seems different controllers on the same SoC
have different timings. The new settings are taken from mmc2, which is
commonly used with eMMC.
Hmm, I'm not really all that familiar with mmc, but can't an external
sdcard connected to mmc0 use DDR too ? Assuming the answer is yes, then
we really need to update the driver to use the right per controller
timings.
I would very much like that to happen. However, SD card UHS-1 DDR modes
require 1.8V signaling, which is unavailable on _all_ sunxi boards.
This seems like a limit of most of the SoCs not having a separate IO
voltage rail for mmc pins.
Until then, I wouldn't worry that much.
quoted
quoted
The settings for the slower timing modes seem to work despite being
wrong, so leave them be.
If you're sure the timings are wrong, please fix them. Sometimes wrong
timings do seem to work, but lead to unreliable communication, or turn
out to work on some boards and not on others due to routing differences.
Unfortunately I did try putting in the correct numbers for them, and my
eMMC then failed to probe. It seems the core switches up from 400kHz to
50MHz then to 50MHz DDR, and it fails somewhere in there, maybe at 50MHz.
I'm not sure if we need to add DT bindings to specify different delays
for different controllers, though. Seems like we'll never actually use
it.
Hope this answers your questions.
Yes that answers my questions, and with my questions answered, this series is:
Acked-by: Hans de Goede <redacted>
Regards,
Hans
Now the the HS-DDR mode clock timings have been corrected, we can
re-enable these modes on the A80.
Signed-off-by: Chen-Yu Tsai <redacted>
---
drivers/mmc/host/sunxi-mmc.c | 5 -----
1 file changed, 5 deletions(-)
@@ -1129,11 +1129,6 @@ static int sunxi_mmc_probe(struct platform_device *pdev)MMC_CAP_1_8V_DDR|MMC_CAP_ERASE|MMC_CAP_SDIO_IRQ;-/* TODO MMC DDR is not working on A80 */-if(of_device_is_compatible(pdev->dev.of_node,-"allwinner,sun9i-a80-mmc"))-mmc->caps&=~MMC_CAP_1_8V_DDR;-ret=mmc_of_parse(mmc);if(ret)gotoerror_free_dma;