linux-kernel - Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151106233913.GB30882@usrtlx11787.corpusers.net>
Date:	Fri, 6 Nov 2015 15:39:13 -0800
From:	Bjorn Andersson <bjorn.andersson@...ymobile.com>
To:	Ulf Hansson <ulf.hansson@...aro.org>
CC:	Bjorn Andersson <bjorn@...o.se>,
	"Ivan T. Ivanov" <ivan.ivanov@...aro.org>,
	Georgi Djakov <georgi.djakov@...aro.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Peter Griffin <peter.griffin@...aro.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

On Fri 06 Nov 00:10 PST 2015, Ulf Hansson wrote:

> On 6 November 2015 at 02:42, Bjorn Andersson <bjorn@...o.se> wrote:
> > On Mon, Jul 6, 2015 at 4:53 AM, Ivan T. Ivanov <ivan.ivanov@...aro.org> wrote:
> >> Ensure SDCC is working with maximum clock otherwise card
> >> detection could be extremely slow, up to 7 seconds.
> >>
> >> Signed-off-by: Ivan T. Ivanov <ivan.ivanov@...aro.org>
> >> Reviewed-by: Georgi Djakov <georgi.djakov@...aro.org>
> >> Acked-by: Stephen Boyd <sboyd@...eaurora.org>
> >> ---
> >>
> >> Changes since v0:
> >> - s/falied/failed in warning message.
> >>
> >>  drivers/mmc/host/sdhci-msm.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> >> index 4a09f76..4bcee03 100644
> >> --- a/drivers/mmc/host/sdhci-msm.c
> >> +++ b/drivers/mmc/host/sdhci-msm.c
> >> @@ -489,6 +489,11 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> >>                 goto pclk_disable;
> >>         }
> >>
> >> +       /* Vote for maximum clock rate for maximum performance */
> >> +       ret = clk_set_rate(msm_host->clk, INT_MAX);
> >> +       if (ret)
> >> +               dev_warn(&pdev->dev, "core clock boost failed\n");
> >> +
> >
> > On my 8974AC devices this results in GCC_SDCC1_APPS_CLK changing from
> > 100MHz to 200MHz for my eMMC. Unfortunately this results in the
> > following error:
> >
> > [    5.103241] mmcblk0: retrying because a re-tune was needed
> > [    5.109270] mmcblk0: error -84 transferring data, sector 5816322,
> > nr 2, cmd response 0x900, card status 0xc00
> >
> > Looking at the board specification it's stated that these card should
> > run in DDR50, so I've tried specifying "max-frequency" in the dt. I
> > verified in sdhci_set_clock() that we get a divisor of 4, but the
> > result is a repetition of:
> 
> I don't follow. Are you saying that changing the clock frequency to
> 200MHz caused the card to be initialized in HS200 mode instead of
> DDR50?
> 

No, we clock the sdhci block at 100MHz, the host->max_clk is 200MHz and
the divisor in sdhci_set_clock() becomes 1. So if I read this correctly
we're running HS200 at 100MHz.

Bumping the clock rate to 200MHz at the block doesn't affect the max_clk
and hence we're trying to run the bus at 200MHz.

I therefor tried to just set "max-frequency" to 50MHz, getting the
divider to be 4 and the below error.

So I assume it just happened to work at 100MHz, but 200MHz is way off
from the 50MHz the board is designed and tested for.


Unfortunately I don't have the equipment to measure these assumptions :/

> >
> > [    1.702312] mmc1: Switching to 3.3V signalling voltage failed
> > [    1.837987] mmc1: power class selection to bus width 8 ddr 0 failed
> > [    1.846227] mmc1: error -110 whilst initialising MMC card
> > [    1.946303] mmc1: Reset 0x1 never completed.
> >
> > I tried to disable HS200 by specifying SDHCI_QUIRK2_BROKEN_HS200. This
> > makes the card come up nicely again.
> >
> >
> > Is there any other way to force the link to DDR50? Is it acceptable to
> > expose the broken-hs200 quirk in dt so I can use that for now?
> 
> We already have these DT bindings.
> - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
> - mmc-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
> - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
> - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
> 
> Can't we use these instead?
> 

These are all additive and the hardware is correctly advertising that
it's capable of supporting SDR104, which implies HS200. Dropping this
assumption (or unsetting these bits) drops us down to the high-speed
rates and things work again.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/