All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@csie.org>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] mmc: sunxi: Fix DDR MMC timings for A80
Date: Mon, 30 May 2016 23:38:37 +0800	[thread overview]
Message-ID: <CAGb2v64qo=kY=ekhbzJUWM_6p9oUupsE+YASD6g9beZS7eg9NQ@mail.gmail.com> (raw)
In-Reply-To: <CAGb2v65=ZM+deSmTmMnT6XFJv8PuY+Kba3kJGKrk_46hxxRyHA@mail.gmail.com>

On Mon, May 30, 2016 at 8:59 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, May 30, 2016 at 7:34 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>
> 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

>>> 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
>
>> Thanks & Regards,
>>
>> Hans
>>
>>
>>
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  drivers/mmc/host/sunxi-mmc.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>> index 7fc8b7aa83f0..5873dc344ab2 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -970,8 +970,8 @@ static const struct sunxi_mmc_clk_delay
>>> sun9i_mmc_clk_delays[] = {
>>>         [SDXC_CLK_400K]         = { .output = 180, .sample = 180 },
>>>         [SDXC_CLK_25M]          = { .output = 180, .sample =  75 },
>>>         [SDXC_CLK_50M]          = { .output = 150, .sample = 120 },
>>> -       [SDXC_CLK_50M_DDR]      = { .output =  90, .sample = 120 },
>>> -       [SDXC_CLK_50M_DDR_8BIT] = { .output =  90, .sample = 120 },
>>> +       [SDXC_CLK_50M_DDR]      = { .output =  54, .sample =  36 },
>>> +       [SDXC_CLK_50M_DDR_8BIT] = { .output =  72, .sample =  72 },
>>>  };
>>>
>>>  static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
>>>
>>

WARNING: multiple messages have this Message-ID (diff)
From: wens@csie.org (Chen-Yu Tsai)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] mmc: sunxi: Fix DDR MMC timings for A80
Date: Mon, 30 May 2016 23:38:37 +0800	[thread overview]
Message-ID: <CAGb2v64qo=kY=ekhbzJUWM_6p9oUupsE+YASD6g9beZS7eg9NQ@mail.gmail.com> (raw)
In-Reply-To: <CAGb2v65=ZM+deSmTmMnT6XFJv8PuY+Kba3kJGKrk_46hxxRyHA@mail.gmail.com>

On Mon, May 30, 2016 at 8:59 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, May 30, 2016 at 7:34 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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.
>
> 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

>>> 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
>
>> Thanks & Regards,
>>
>> Hans
>>
>>
>>
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>> ---
>>>  drivers/mmc/host/sunxi-mmc.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>> index 7fc8b7aa83f0..5873dc344ab2 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -970,8 +970,8 @@ static const struct sunxi_mmc_clk_delay
>>> sun9i_mmc_clk_delays[] = {
>>>         [SDXC_CLK_400K]         = { .output = 180, .sample = 180 },
>>>         [SDXC_CLK_25M]          = { .output = 180, .sample =  75 },
>>>         [SDXC_CLK_50M]          = { .output = 150, .sample = 120 },
>>> -       [SDXC_CLK_50M_DDR]      = { .output =  90, .sample = 120 },
>>> -       [SDXC_CLK_50M_DDR_8BIT] = { .output =  90, .sample = 120 },
>>> +       [SDXC_CLK_50M_DDR]      = { .output =  54, .sample =  36 },
>>> +       [SDXC_CLK_50M_DDR_8BIT] = { .output =  72, .sample =  72 },
>>>  };
>>>
>>>  static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
>>>
>>

  reply	other threads:[~2016-05-30 15:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-29  7:04 [PATCH 0/3] mmc: sunxi: Fix MMC DDR modes for Allwinner A80 Chen-Yu Tsai
2016-05-29  7:04 ` Chen-Yu Tsai
2016-05-29  7:04 ` [PATCH 1/3] mmc: fix mmc mode selection for HS-DDR and higher Chen-Yu Tsai
2016-05-29  7:04   ` Chen-Yu Tsai
2016-05-31  9:30   ` Krzysztof Kozlowski
2016-05-31  9:30     ` Krzysztof Kozlowski
2016-06-01  1:25   ` Jaehoon Chung
2016-06-01  1:25     ` Jaehoon Chung
2016-06-01  2:36   ` Shawn Lin
2016-06-01  2:36     ` Shawn Lin
2016-06-01  9:19   ` Marcel Ziswiler
2016-06-01  9:19     ` Marcel Ziswiler
2016-06-01 18:58   ` Bjorn Andersson
2016-06-01 18:58     ` Bjorn Andersson
2016-06-02  8:08     ` Chen-Yu Tsai
2016-06-02  8:08       ` Chen-Yu Tsai
2016-06-02  8:31   ` Ulf Hansson
2016-06-02  8:31     ` Ulf Hansson
2016-06-02  8:31     ` Ulf Hansson
2016-06-02  9:35     ` Krzysztof Kozlowski
2016-06-02  9:35       ` Krzysztof Kozlowski
2016-06-02  9:35       ` Krzysztof Kozlowski
2016-06-02 15:01       ` Ulf Hansson
2016-06-02 15:01         ` Ulf Hansson
2016-06-02 15:01         ` Ulf Hansson
2016-05-29  7:04 ` [PATCH 2/3] mmc: sunxi: Fix DDR MMC timings for A80 Chen-Yu Tsai
2016-05-29  7:04   ` Chen-Yu Tsai
2016-05-30 11:34   ` Hans de Goede
2016-05-30 11:34     ` Hans de Goede
2016-05-30 12:59     ` Chen-Yu Tsai
2016-05-30 12:59       ` Chen-Yu Tsai
2016-05-30 15:38       ` Chen-Yu Tsai [this message]
2016-05-30 15:38         ` Chen-Yu Tsai
2016-05-30 18:05       ` Hans de Goede
2016-05-30 18:05         ` Hans de Goede
2016-05-29  7:04 ` [PATCH 3/3] mmc: sunxi: Re-enable eMMC HS-DDR modes on Allwinner A80 Chen-Yu Tsai
2016-05-29  7:04   ` Chen-Yu Tsai

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='CAGb2v64qo=kY=ekhbzJUWM_6p9oUupsE+YASD6g9beZS7eg9NQ@mail.gmail.com' \
    --to=wens@csie.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.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.