Message ID | 20221108045300.2084671-2-lis8215@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2486270wru; Mon, 7 Nov 2022 20:59:01 -0800 (PST) X-Google-Smtp-Source: AMsMyM4fsWLBjNDq+Mqz60/Pqzuqd5FLMgfWp7ghUKXRzfPWw3COslybFgYZhQw+7+rDNq1b2Dy8 X-Received: by 2002:a17:907:b602:b0:7ad:e82c:3355 with SMTP id vl2-20020a170907b60200b007ade82c3355mr38103587ejc.3.1667883540909; Mon, 07 Nov 2022 20:59:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667883540; cv=none; d=google.com; s=arc-20160816; b=pctjMM5ARDQx8QwoRWapny7D2fzeRc7H8sqZEKfkW4+laRTDAWFdvQ2j+m2hLvRnQj fbXcywGM0o0bch2axW7M0kOUoA5dJnZpBhyRchvWpGGa8AiQsecaubnVqNOfRyaRh/Om 0QYXk/dget9P4OtUrivtfjEuAm6pd7auMgqDqU6CRWH7yVPeqGKDTh2leTP2rKJYs6dr PL7bnXXlgtMe8TBuz0MzehWpKFUt8y1vWCD2OBp7iUh/vyR6CgihLX92avM6STvviPDj hY58lSz+dSXkwRZao76yX7qckKCpyt7Hn4HfEBbhCKplL7IJe8OOdXMvcbfoNW59lNxT CF1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:from :dkim-signature; bh=cJ4Kp4qtRSrvjN0VOHg/NMsbcM2L3wi4GzWp4+H7lqY=; b=g2NSQ4YTvL+T7VNwWl/yVUKcdq2vu3WXY7YbroJkl9MhMUgKydjnplRoKpfO/A3hqB GDZ/P63lv8cMHs5L1RWGPiWYwXFdWC2ro5X0Hyn4Yj72d+ucqnfk4f72NRhftxNpGEMd 1uzYxcaROU8c+Ii/7KwN7P2+zj9LpJvFSoAW6C2JRunLZliykuObW1adEfZ3v2ld7di4 DDbiEdw+LYyqQDb5G1T1wtxL7Y8ZHPRC/sakOw7C/6dG5Bmx5vwksruEkDC6elLBQ4Xj SPtH2kBxZvVlfgV6cJAUkcVi+SwOxD3bEokxWyKr7W2WN3yHFafG9TVbtP+LyCxHZYDx 7GGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20210112 header.b=VRlK8dyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bb6-20020a1709070a0600b00781bbff1cc1si10981444ejc.455.2022.11.07.20.58.37; Mon, 07 Nov 2022 20:59:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20210112 header.b=VRlK8dyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233443AbiKHE5u (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Mon, 7 Nov 2022 23:57:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233399AbiKHE5c (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 7 Nov 2022 23:57:32 -0500 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF4FF2E691; Mon, 7 Nov 2022 20:53:56 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id s12so11121949edd.5; Mon, 07 Nov 2022 20:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=cJ4Kp4qtRSrvjN0VOHg/NMsbcM2L3wi4GzWp4+H7lqY=; b=VRlK8dyzw8ngJPEBSuKzwQwMbZE+SmKnbjXkreWs+SKjkaHFsrmGvYExBUU74ZTOty qVrfpmkis7/qm8rR2q+eZ+Fl9rx6YSEDB+UUpdz1ZJWXNsP/Vf8/2hhjHpKEKaX6PgAi jRquLzFBP5/9DPUKDXp2s66eOXIm9u9v8VZRZVDmsQ7ZN8688j7Lrvvstsx77lXQzEep rT2GF97Nw/xTStzEkAEsB/DJ+hSj2tyqvgSPh1Aehz9z9B8AefxIIa9NhQf2B6ggOC12 9/zRmw5I8BMIRap64rWDVS+baDYSuDP/WMU1kd7mLt3Jfa/asDEe4JsWRkK6P+cf9m23 OqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cJ4Kp4qtRSrvjN0VOHg/NMsbcM2L3wi4GzWp4+H7lqY=; b=pxjelmSwrXntr3bRusOPt7CchC12iIZ+MItO5ZuYw1snisb2wYBxpxtsIerxZCetGB CL56ptXL1FH/86trGphlOytMgjy+/mW6LFSAS2GNuJHFA0962b4fFvmbbGwVuQvk+G4z ql4EkDkIEjmiyrnwOvCwO1holxOuuwRjV7S2qHWlh0mdGx1zSr+qv8Irx6cuk1n+RuIH +7lxpQLbpMNbKRHJSdYyUV1gEh66bdqwwXPekzia06B3OQi5XeuB80B0OB1Sq+rpNzQE Ko02AdWyO5GeJrFvkuD5eW0oFo6cZYZzRMXdGd990IhB+QMnKdkZ/Zkfc5v5Q4fnVsZg YENA== X-Gm-Message-State: ACrzQf3dPaiL9Qn7RhMCKHrOwrWrdNpwJ0hoQad6sOtGsbTuzmx5YlRf KDt1mbwkwXDJ9OrDzaL7LWI= X-Received: by 2002:a05:6402:14ca:b0:462:e375:a1f4 with SMTP id f10-20020a05640214ca00b00462e375a1f4mr54812108edx.344.1667883235303; Mon, 07 Nov 2022 20:53:55 -0800 (PST) Received: from hp-power-15.localdomain (mm-58-12-212-37.vitebsk.dynamic.pppoe.byfly.by. [37.212.12.58]) by smtp.gmail.com with ESMTPSA id p11-20020a05640210cb00b004637489cf08sm4994444edu.88.2022.11.07.20.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 20:53:54 -0800 (PST) From: Siarhei Volkau <lis8215@gmail.com> Cc: Siarhei Volkau <lis8215@gmail.com>, Paul Cercueil <paul@crapouillou.net>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Ulf Hansson <ulf.hansson@linaro.org>, linux-mips@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org Subject: [PATCH 1/2] mmc: jz4740: Don't change parent clock rate for some SoCs Date: Tue, 8 Nov 2022 07:52:59 +0300 Message-Id: <20221108045300.2084671-2-lis8215@gmail.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20221108045300.2084671-1-lis8215@gmail.com> References: <20221108045300.2084671-1-lis8215@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748902604544018267?= X-GMAIL-MSGID: =?utf-8?q?1748902651804147981?= |
Series |
mmc: jz4740: Don't change parent clock rate for some SoCs
|
|
Commit Message
Siarhei Volkau
Nov. 8, 2022, 4:52 a.m. UTC
Some SoCs have one clock divider for all MMC units, thus changing one
affects others as well. This leads to random hangs and memory
corruptions, observed on the JZ4755 based device with two MMC slots
used at the same time.
List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b.
However, the MMC driver doesn't distinguish JZ4760 and JZ4770
which shall remain its behavior. For the JZ4755 is sufficient to
use JZ4725b's binding. JZ4750 is outside of the patch.
The MMC core has its own clock divisor, rather coarse but suitable well,
and it shall keep the role of tuning clock for the MMC host in that
case.
Signed-off-by: Siarhei Volkau <lis8215@gmail.com>
---
drivers/mmc/host/jz4740_mmc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Comments
On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: > > Some SoCs have one clock divider for all MMC units, thus changing one > affects others as well. This leads to random hangs and memory > corruptions, observed on the JZ4755 based device with two MMC slots > used at the same time. Urgh, that sounds like broken HW to me. The MMC blocks could share a parent clock (that would need a fixed rate for it to be applied), assuming there is a separate gate/divider available per block. But there isn't'? > > List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. > However, the MMC driver doesn't distinguish JZ4760 and JZ4770 > which shall remain its behavior. For the JZ4755 is sufficient to > use JZ4725b's binding. JZ4750 is outside of the patch. > > The MMC core has its own clock divisor, rather coarse but suitable well, > and it shall keep the role of tuning clock for the MMC host in that > case. The mmc core doesn't have a clock divisor, but it does control the bus clock frequency through the ->set_ios() host ops. It needs to do that, to be able to conform to the (e)MMC, SD and SDIO specifications. Can you please try to elaborate on the above, so I can better understand your point? > > Signed-off-by: Siarhei Volkau <lis8215@gmail.com> Kind regards Uffe > --- > drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c > index dc2db9c18..d390ff31d 100644 > --- a/drivers/mmc/host/jz4740_mmc.c > +++ b/drivers/mmc/host/jz4740_mmc.c > @@ -114,6 +114,7 @@ enum jz4740_mmc_version { > JZ_MMC_JZ4740, > JZ_MMC_JZ4725B, > JZ_MMC_JZ4760, > + JZ_MMC_JZ4770, > JZ_MMC_JZ4780, > JZ_MMC_X1000, > }; > @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct jz4740_mmc_host *host, int rate) > int real_rate; > > jz4740_mmc_clock_disable(host); > - clk_set_rate(host->clk, host->mmc->f_max); > + > + /* > + * Changing rate on these SoCs affects other MMC units too. > + * Make sure the rate is configured properly by the CGU driver. > + */ > + if (host->version != JZ_MMC_JZ4725B && host->version != JZ_MMC_JZ4760) > + clk_set_rate(host->clk, host->mmc->f_max); > > real_rate = clk_get_rate(host->clk); > > @@ -992,6 +999,7 @@ static const struct of_device_id jz4740_mmc_of_match[] = { > { .compatible = "ingenic,jz4740-mmc", .data = (void *) JZ_MMC_JZ4740 }, > { .compatible = "ingenic,jz4725b-mmc", .data = (void *)JZ_MMC_JZ4725B }, > { .compatible = "ingenic,jz4760-mmc", .data = (void *) JZ_MMC_JZ4760 }, > + { .compatible = "ingenic,jz4770-mmc", .data = (void *) JZ_MMC_JZ4770 }, > { .compatible = "ingenic,jz4775-mmc", .data = (void *) JZ_MMC_JZ4780 }, > { .compatible = "ingenic,jz4780-mmc", .data = (void *) JZ_MMC_JZ4780 }, > { .compatible = "ingenic,x1000-mmc", .data = (void *) JZ_MMC_X1000 }, > -- > 2.36.1 >
Hi, (Ingenic SoCs maintainer here) Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson <ulf.hansson@linaro.org> a écrit : > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: >> >> Some SoCs have one clock divider for all MMC units, thus changing >> one >> affects others as well. This leads to random hangs and memory >> corruptions, observed on the JZ4755 based device with two MMC slots >> used at the same time. > > Urgh, that sounds like broken HW to me. > > The MMC blocks could share a parent clock (that would need a fixed > rate for it to be applied), assuming there is a separate gate/divider > available per block. But there isn't'? They do share a parent clock and have separate gates, and each MMC IP block has an internal divider for the bus frequency derived from that shared clock. >> >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 >> which shall remain its behavior. For the JZ4755 is sufficient to >> use JZ4725b's binding. JZ4750 is outside of the patch. >> >> The MMC core has its own clock divisor, rather coarse but suitable >> well, >> and it shall keep the role of tuning clock for the MMC host in that >> case. > > The mmc core doesn't have a clock divisor, but it does control the bus > clock frequency through the ->set_ios() host ops. It needs to do that, > to be able to conform to the (e)MMC, SD and SDIO specifications. > > Can you please try to elaborate on the above, so I can better > understand your point? Yes, I don't really understand the patch, TBH. The "clk_set_rate" call will only set the shared clock to the *maximum* clock frequency (host->mmc->f_max) which should be the exact same across all MMC IPs. So it doesn't matter if it's set 3 times by 3 different instances of the IP, as long as they all request the same value. Besides, I know for a fact that the mainline driver works fine on the JZ4760(B) and JZ4725B. Finally... even if it was correct, this change would break compatibility with old Device Tree files. Cheers, -Paul >> >> Signed-off-by: Siarhei Volkau <lis8215@gmail.com> > > Kind regards > Uffe > >> --- >> drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/host/jz4740_mmc.c >> b/drivers/mmc/host/jz4740_mmc.c >> index dc2db9c18..d390ff31d 100644 >> --- a/drivers/mmc/host/jz4740_mmc.c >> +++ b/drivers/mmc/host/jz4740_mmc.c >> @@ -114,6 +114,7 @@ enum jz4740_mmc_version { >> JZ_MMC_JZ4740, >> JZ_MMC_JZ4725B, >> JZ_MMC_JZ4760, >> + JZ_MMC_JZ4770, >> JZ_MMC_JZ4780, >> JZ_MMC_X1000, >> }; >> @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct >> jz4740_mmc_host *host, int rate) >> int real_rate; >> >> jz4740_mmc_clock_disable(host); >> - clk_set_rate(host->clk, host->mmc->f_max); >> + >> + /* >> + * Changing rate on these SoCs affects other MMC units too. >> + * Make sure the rate is configured properly by the CGU >> driver. >> + */ >> + if (host->version != JZ_MMC_JZ4725B && host->version != >> JZ_MMC_JZ4760) >> + clk_set_rate(host->clk, host->mmc->f_max); >> >> real_rate = clk_get_rate(host->clk); >> >> @@ -992,6 +999,7 @@ static const struct of_device_id >> jz4740_mmc_of_match[] = { >> { .compatible = "ingenic,jz4740-mmc", .data = (void *) >> JZ_MMC_JZ4740 }, >> { .compatible = "ingenic,jz4725b-mmc", .data = (void >> *)JZ_MMC_JZ4725B }, >> { .compatible = "ingenic,jz4760-mmc", .data = (void *) >> JZ_MMC_JZ4760 }, >> + { .compatible = "ingenic,jz4770-mmc", .data = (void *) >> JZ_MMC_JZ4770 }, >> { .compatible = "ingenic,jz4775-mmc", .data = (void *) >> JZ_MMC_JZ4780 }, >> { .compatible = "ingenic,jz4780-mmc", .data = (void *) >> JZ_MMC_JZ4780 }, >> { .compatible = "ingenic,x1000-mmc", .data = (void *) >> JZ_MMC_X1000 }, >> -- >> 2.36.1 >>
пт, 18 нояб. 2022 г. в 12:27, Paul Cercueil <paul@crapouillou.net>: > > Hi, > > (Ingenic SoCs maintainer here) > > Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson > <ulf.hansson@linaro.org> a écrit : > > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: > >> > >> Some SoCs have one clock divider for all MMC units, thus changing > >> one > >> affects others as well. This leads to random hangs and memory > >> corruptions, observed on the JZ4755 based device with two MMC slots > >> used at the same time. > > > > Urgh, that sounds like broken HW to me. > > > > The MMC blocks could share a parent clock (that would need a fixed > > rate for it to be applied), assuming there is a separate gate/divider > > available per block. But there isn't'? > > They do share a parent clock and have separate gates, and each MMC IP > block has an internal divider for the bus frequency derived from that > shared clock. > > >> > >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. > >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 > >> which shall remain its behavior. For the JZ4755 is sufficient to > >> use JZ4725b's binding. JZ4750 is outside of the patch. > >> > >> The MMC core has its own clock divisor, rather coarse but suitable > >> well, > >> and it shall keep the role of tuning clock for the MMC host in that > >> case. > > > > The mmc core doesn't have a clock divisor, but it does control the bus > > clock frequency through the ->set_ios() host ops. It needs to do that, > > to be able to conform to the (e)MMC, SD and SDIO specifications. > > > > Can you please try to elaborate on the above, so I can better > > understand your point? > > Yes, I don't really understand the patch, TBH. > > The "clk_set_rate" call will only set the shared clock to the *maximum* > clock frequency (host->mmc->f_max) which should be the exact same > across all MMC IPs. That's the case I need different "f_max" for my HW, for some reason internal slot can't do a full rate (48MHz) but the external can, the same card used for checking. So I want to set 24M for mmc0, and 48M for mmc1 with respect to hardware limitation. > > So it doesn't matter if it's set 3 times by 3 different instances of > the IP, as long as they all request the same value. > > Besides, I know for a fact that the mainline driver works fine on the > JZ4760(B) and JZ4725B. > > Finally... even if it was correct, this change would break > compatibility with old Device Tree files. > > Cheers, > -Paul > > >> > >> Signed-off-by: Siarhei Volkau <lis8215@gmail.com> > > > > Kind regards > > Uffe > > > >> --- > >> drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- > >> 1 file changed, 9 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/mmc/host/jz4740_mmc.c > >> b/drivers/mmc/host/jz4740_mmc.c > >> index dc2db9c18..d390ff31d 100644 > >> --- a/drivers/mmc/host/jz4740_mmc.c > >> +++ b/drivers/mmc/host/jz4740_mmc.c > >> @@ -114,6 +114,7 @@ enum jz4740_mmc_version { > >> JZ_MMC_JZ4740, > >> JZ_MMC_JZ4725B, > >> JZ_MMC_JZ4760, > >> + JZ_MMC_JZ4770, > >> JZ_MMC_JZ4780, > >> JZ_MMC_X1000, > >> }; > >> @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct > >> jz4740_mmc_host *host, int rate) > >> int real_rate; > >> > >> jz4740_mmc_clock_disable(host); > >> - clk_set_rate(host->clk, host->mmc->f_max); > >> + > >> + /* > >> + * Changing rate on these SoCs affects other MMC units too. > >> + * Make sure the rate is configured properly by the CGU > >> driver. > >> + */ > >> + if (host->version != JZ_MMC_JZ4725B && host->version != > >> JZ_MMC_JZ4760) > >> + clk_set_rate(host->clk, host->mmc->f_max); > >> > >> real_rate = clk_get_rate(host->clk); > >> > >> @@ -992,6 +999,7 @@ static const struct of_device_id > >> jz4740_mmc_of_match[] = { > >> { .compatible = "ingenic,jz4740-mmc", .data = (void *) > >> JZ_MMC_JZ4740 }, > >> { .compatible = "ingenic,jz4725b-mmc", .data = (void > >> *)JZ_MMC_JZ4725B }, > >> { .compatible = "ingenic,jz4760-mmc", .data = (void *) > >> JZ_MMC_JZ4760 }, > >> + { .compatible = "ingenic,jz4770-mmc", .data = (void *) > >> JZ_MMC_JZ4770 }, > >> { .compatible = "ingenic,jz4775-mmc", .data = (void *) > >> JZ_MMC_JZ4780 }, > >> { .compatible = "ingenic,jz4780-mmc", .data = (void *) > >> JZ_MMC_JZ4780 }, > >> { .compatible = "ingenic,x1000-mmc", .data = (void *) > >> JZ_MMC_X1000 }, > >> -- > >> 2.36.1 > >> > >
On Fri, 18 Nov 2022 at 10:52, Siarhei Volkau <lis8215@gmail.com> wrote: > > пт, 18 нояб. 2022 г. в 12:27, Paul Cercueil <paul@crapouillou.net>: > > > > Hi, > > > > (Ingenic SoCs maintainer here) > > > > Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson > > <ulf.hansson@linaro.org> a écrit : > > > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: > > >> > > >> Some SoCs have one clock divider for all MMC units, thus changing > > >> one > > >> affects others as well. This leads to random hangs and memory > > >> corruptions, observed on the JZ4755 based device with two MMC slots > > >> used at the same time. > > > > > > Urgh, that sounds like broken HW to me. > > > > > > The MMC blocks could share a parent clock (that would need a fixed > > > rate for it to be applied), assuming there is a separate gate/divider > > > available per block. But there isn't'? > > > > They do share a parent clock and have separate gates, and each MMC IP > > block has an internal divider for the bus frequency derived from that > > shared clock. > > > > >> > > >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. > > >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 > > >> which shall remain its behavior. For the JZ4755 is sufficient to > > >> use JZ4725b's binding. JZ4750 is outside of the patch. > > >> > > >> The MMC core has its own clock divisor, rather coarse but suitable > > >> well, > > >> and it shall keep the role of tuning clock for the MMC host in that > > >> case. > > > > > > The mmc core doesn't have a clock divisor, but it does control the bus > > > clock frequency through the ->set_ios() host ops. It needs to do that, > > > to be able to conform to the (e)MMC, SD and SDIO specifications. > > > > > > Can you please try to elaborate on the above, so I can better > > > understand your point? > > > > Yes, I don't really understand the patch, TBH. > > > > The "clk_set_rate" call will only set the shared clock to the *maximum* > > clock frequency (host->mmc->f_max) which should be the exact same > > across all MMC IPs. > > That's the case I need different "f_max" for my HW, for some reason > internal slot can't do a full rate (48MHz) but the external can, the same > card used for checking. So I want to set 24M for mmc0, and 48M for mmc1 > with respect to hardware limitation. This sounds like a board specific problem, right? The simple solution would be to use 24M for both hosts, but that would unnecessarily degrade the speed for the host for the internal slot. It sounds like we need a new DT binding to describe a capped max-frequency for the "broken slot". And in case that is available in the DTS, the mmc->f_max value should be overridden with it, while also respecting the original f_max value while calling clk_set_rate(). Br Uffe
пт, 18 нояб. 2022 г. в 13:06, Ulf Hansson <ulf.hansson@linaro.org>: > > On Fri, 18 Nov 2022 at 10:52, Siarhei Volkau <lis8215@gmail.com> wrote: > > > > пт, 18 нояб. 2022 г. в 12:27, Paul Cercueil <paul@crapouillou.net>: > > > > > > Hi, > > > > > > (Ingenic SoCs maintainer here) > > > > > > Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson > > > <ulf.hansson@linaro.org> a écrit : > > > > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: > > > >> > > > >> Some SoCs have one clock divider for all MMC units, thus changing > > > >> one > > > >> affects others as well. This leads to random hangs and memory > > > >> corruptions, observed on the JZ4755 based device with two MMC slots > > > >> used at the same time. > > > > > > > > Urgh, that sounds like broken HW to me. > > > > > > > > The MMC blocks could share a parent clock (that would need a fixed > > > > rate for it to be applied), assuming there is a separate gate/divider > > > > available per block. But there isn't'? > > > > > > They do share a parent clock and have separate gates, and each MMC IP > > > block has an internal divider for the bus frequency derived from that > > > shared clock. > > > > > > >> > > > >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. > > > >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 > > > >> which shall remain its behavior. For the JZ4755 is sufficient to > > > >> use JZ4725b's binding. JZ4750 is outside of the patch. > > > >> > > > >> The MMC core has its own clock divisor, rather coarse but suitable > > > >> well, > > > >> and it shall keep the role of tuning clock for the MMC host in that > > > >> case. > > > > > > > > The mmc core doesn't have a clock divisor, but it does control the bus > > > > clock frequency through the ->set_ios() host ops. It needs to do that, > > > > to be able to conform to the (e)MMC, SD and SDIO specifications. > > > > > > > > Can you please try to elaborate on the above, so I can better > > > > understand your point? > > > > > > Yes, I don't really understand the patch, TBH. > > > > > > The "clk_set_rate" call will only set the shared clock to the *maximum* > > > clock frequency (host->mmc->f_max) which should be the exact same > > > across all MMC IPs. > > > > That's the case I need different "f_max" for my HW, for some reason > > internal slot can't do a full rate (48MHz) but the external can, the same > > card used for checking. So I want to set 24M for mmc0, and 48M for mmc1 > > with respect to hardware limitation. > > This sounds like a board specific problem, right? Exactly. > > The simple solution would be to use 24M for both hosts, but that would > unnecessarily degrade the speed for the host for the internal slot. > Indeed. > It sounds like we need a new DT binding to describe a capped > max-frequency for the "broken slot". And in case that is available in > the DTS, the mmc->f_max value should be overridden with it, while also > respecting the original f_max value while calling clk_set_rate(). > > Br > Uffe I think it is unnecessary, "max-frequency" is enough and clear to use here, it just needs to be tuned independently for each controller. However, the controllers have hidden dependency on each other. Break this dependency that's the subject of the patchset. Siarhei
Hi Siarhei, Le ven. 18 nov. 2022 à 12:51:54 +0300, Siarhei Volkau <lis8215@gmail.com> a écrit : > пт, 18 нояб. 2022 г. в 12:27, Paul Cercueil > <paul@crapouillou.net>: >> >> Hi, >> >> (Ingenic SoCs maintainer here) >> >> Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson >> <ulf.hansson@linaro.org> a écrit : >> > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> >> wrote: >> >> >> >> Some SoCs have one clock divider for all MMC units, thus >> changing >> >> one >> >> affects others as well. This leads to random hangs and memory >> >> corruptions, observed on the JZ4755 based device with two MMC >> slots >> >> used at the same time. >> > >> > Urgh, that sounds like broken HW to me. >> > >> > The MMC blocks could share a parent clock (that would need a fixed >> > rate for it to be applied), assuming there is a separate >> gate/divider >> > available per block. But there isn't'? >> >> They do share a parent clock and have separate gates, and each MMC >> IP >> block has an internal divider for the bus frequency derived from >> that >> shared clock. >> >> >> >> >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and >> JZ4760b. >> >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 >> >> which shall remain its behavior. For the JZ4755 is sufficient to >> >> use JZ4725b's binding. JZ4750 is outside of the patch. >> >> >> >> The MMC core has its own clock divisor, rather coarse but >> suitable >> >> well, >> >> and it shall keep the role of tuning clock for the MMC host in >> that >> >> case. >> > >> > The mmc core doesn't have a clock divisor, but it does control >> the bus >> > clock frequency through the ->set_ios() host ops. It needs to do >> that, >> > to be able to conform to the (e)MMC, SD and SDIO specifications. >> > >> > Can you please try to elaborate on the above, so I can better >> > understand your point? >> >> Yes, I don't really understand the patch, TBH. >> >> The "clk_set_rate" call will only set the shared clock to the >> *maximum* >> clock frequency (host->mmc->f_max) which should be the exact same >> across all MMC IPs. > > That's the case I need different "f_max" for my HW, for some reason > internal slot can't do a full rate (48MHz) but the external can, the > same > card used for checking. So I want to set 24M for mmc0, and 48M for > mmc1 > with respect to hardware limitation. The JZ4760B programming manual states that the controller is "fully compatible with the SD Memory Card Specification 2.0". In that specification, the bus speed is max. 25 MHz. The programming manual also says: "In data transfer mode, the MSC controller can operate card with clock rate fpp (0 ~ 25Mhz)." So the max-frequency really should be 25 MHz. Cheers, -Paul >> >> So it doesn't matter if it's set 3 times by 3 different instances of >> the IP, as long as they all request the same value. >> >> Besides, I know for a fact that the mainline driver works fine on >> the >> JZ4760(B) and JZ4725B. >> >> Finally... even if it was correct, this change would break >> compatibility with old Device Tree files. >> >> Cheers, >> -Paul >> >> >> >> >> Signed-off-by: Siarhei Volkau <lis8215@gmail.com> >> > >> > Kind regards >> > Uffe >> > >> >> --- >> >> drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- >> >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/mmc/host/jz4740_mmc.c >> >> b/drivers/mmc/host/jz4740_mmc.c >> >> index dc2db9c18..d390ff31d 100644 >> >> --- a/drivers/mmc/host/jz4740_mmc.c >> >> +++ b/drivers/mmc/host/jz4740_mmc.c >> >> @@ -114,6 +114,7 @@ enum jz4740_mmc_version { >> >> JZ_MMC_JZ4740, >> >> JZ_MMC_JZ4725B, >> >> JZ_MMC_JZ4760, >> >> + JZ_MMC_JZ4770, >> >> JZ_MMC_JZ4780, >> >> JZ_MMC_X1000, >> >> }; >> >> @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct >> >> jz4740_mmc_host *host, int rate) >> >> int real_rate; >> >> >> >> jz4740_mmc_clock_disable(host); >> >> - clk_set_rate(host->clk, host->mmc->f_max); >> >> + >> >> + /* >> >> + * Changing rate on these SoCs affects other MMC units >> too. >> >> + * Make sure the rate is configured properly by the CGU >> >> driver. >> >> + */ >> >> + if (host->version != JZ_MMC_JZ4725B && host->version != >> >> JZ_MMC_JZ4760) >> >> + clk_set_rate(host->clk, host->mmc->f_max); >> >> >> >> real_rate = clk_get_rate(host->clk); >> >> >> >> @@ -992,6 +999,7 @@ static const struct of_device_id >> >> jz4740_mmc_of_match[] = { >> >> { .compatible = "ingenic,jz4740-mmc", .data = (void *) >> >> JZ_MMC_JZ4740 }, >> >> { .compatible = "ingenic,jz4725b-mmc", .data = (void >> >> *)JZ_MMC_JZ4725B }, >> >> { .compatible = "ingenic,jz4760-mmc", .data = (void *) >> >> JZ_MMC_JZ4760 }, >> >> + { .compatible = "ingenic,jz4770-mmc", .data = (void *) >> >> JZ_MMC_JZ4770 }, >> >> { .compatible = "ingenic,jz4775-mmc", .data = (void *) >> >> JZ_MMC_JZ4780 }, >> >> { .compatible = "ingenic,jz4780-mmc", .data = (void *) >> >> JZ_MMC_JZ4780 }, >> >> { .compatible = "ingenic,x1000-mmc", .data = (void *) >> >> JZ_MMC_X1000 }, >> >> -- >> >> 2.36.1 >> >> >> >>
Le ven. 18 nov. 2022 à 13:04:30 +0000, Paul Cercueil <paul@crapouillou.net> a écrit : > Hi Siarhei, > > Le ven. 18 nov. 2022 à 12:51:54 +0300, Siarhei Volkau > <lis8215@gmail.com> a écrit : >> пт, 18 нояб. 2022 г. в 12:27, Paul Cercueil >> <paul@crapouillou.net>: >>> >>> Hi, >>> >>> (Ingenic SoCs maintainer here) >>> >>> Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson >>> <ulf.hansson@linaro.org> a écrit : >>> > On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> >>> wrote: >>> >> >>> >> Some SoCs have one clock divider for all MMC units, thus >>> changing >>> >> one >>> >> affects others as well. This leads to random hangs and memory >>> >> corruptions, observed on the JZ4755 based device with two MMC >>> slots >>> >> used at the same time. >>> > >>> > Urgh, that sounds like broken HW to me. >>> > >>> > The MMC blocks could share a parent clock (that would need a >>> fixed >>> > rate for it to be applied), assuming there is a separate >>> gate/divider >>> > available per block. But there isn't'? >>> >>> They do share a parent clock and have separate gates, and each MMC >>> IP >>> block has an internal divider for the bus frequency derived from >>> that >>> shared clock. >>> >>> >> >>> >> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and >>> JZ4760b. >>> >> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 >>> >> which shall remain its behavior. For the JZ4755 is sufficient >>> to >>> >> use JZ4725b's binding. JZ4750 is outside of the patch. >>> >> >>> >> The MMC core has its own clock divisor, rather coarse but >>> suitable >>> >> well, >>> >> and it shall keep the role of tuning clock for the MMC host in >>> that >>> >> case. >>> > >>> > The mmc core doesn't have a clock divisor, but it does control >>> the bus >>> > clock frequency through the ->set_ios() host ops. It needs to do >>> that, >>> > to be able to conform to the (e)MMC, SD and SDIO specifications. >>> > >>> > Can you please try to elaborate on the above, so I can better >>> > understand your point? >>> >>> Yes, I don't really understand the patch, TBH. >>> >>> The "clk_set_rate" call will only set the shared clock to the >>> *maximum* >>> clock frequency (host->mmc->f_max) which should be the exact same >>> across all MMC IPs. >> >> That's the case I need different "f_max" for my HW, for some reason >> internal slot can't do a full rate (48MHz) but the external can, the >> same >> card used for checking. So I want to set 24M for mmc0, and 48M for >> mmc1 >> with respect to hardware limitation. > > The JZ4760B programming manual states that the controller is "fully > compatible with the SD Memory Card Specification 2.0". In that > specification, the bus speed is max. 25 MHz. > > The programming manual also says: "In data transfer mode, the MSC > controller can operate card with clock rate fpp (0 ~ 25Mhz)." > > So the max-frequency really should be 25 MHz. Nevermind. I read wrong, at least the SD spec. (the quote of the programming manual is still concerning though). It's rated for 25 MB/s, so 50 MHz on 4 lanes. Cheers, -Paul > >>> >>> So it doesn't matter if it's set 3 times by 3 different instances >>> of >>> the IP, as long as they all request the same value. >>> >>> Besides, I know for a fact that the mainline driver works fine on >>> the >>> JZ4760(B) and JZ4725B. >>> >>> Finally... even if it was correct, this change would break >>> compatibility with old Device Tree files. >>> >>> Cheers, >>> -Paul >>> >>> >> >>> >> Signed-off-by: Siarhei Volkau <lis8215@gmail.com> >>> > >>> > Kind regards >>> > Uffe >>> > >>> >> --- >>> >> drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- >>> >> 1 file changed, 9 insertions(+), 1 deletion(-) >>> >> >>> >> diff --git a/drivers/mmc/host/jz4740_mmc.c >>> >> b/drivers/mmc/host/jz4740_mmc.c >>> >> index dc2db9c18..d390ff31d 100644 >>> >> --- a/drivers/mmc/host/jz4740_mmc.c >>> >> +++ b/drivers/mmc/host/jz4740_mmc.c >>> >> @@ -114,6 +114,7 @@ enum jz4740_mmc_version { >>> >> JZ_MMC_JZ4740, >>> >> JZ_MMC_JZ4725B, >>> >> JZ_MMC_JZ4760, >>> >> + JZ_MMC_JZ4770, >>> >> JZ_MMC_JZ4780, >>> >> JZ_MMC_X1000, >>> >> }; >>> >> @@ -887,7 +888,13 @@ static int >>> jz4740_mmc_set_clock_rate(struct >>> >> jz4740_mmc_host *host, int rate) >>> >> int real_rate; >>> >> >>> >> jz4740_mmc_clock_disable(host); >>> >> - clk_set_rate(host->clk, host->mmc->f_max); >>> >> + >>> >> + /* >>> >> + * Changing rate on these SoCs affects other MMC units >>> too. >>> >> + * Make sure the rate is configured properly by the CGU >>> >> driver. >>> >> + */ >>> >> + if (host->version != JZ_MMC_JZ4725B && host->version != >>> >> JZ_MMC_JZ4760) >>> >> + clk_set_rate(host->clk, host->mmc->f_max); >>> >> >>> >> real_rate = clk_get_rate(host->clk); >>> >> >>> >> @@ -992,6 +999,7 @@ static const struct of_device_id >>> >> jz4740_mmc_of_match[] = { >>> >> { .compatible = "ingenic,jz4740-mmc", .data = (void *) >>> >> JZ_MMC_JZ4740 }, >>> >> { .compatible = "ingenic,jz4725b-mmc", .data = (void >>> >> *)JZ_MMC_JZ4725B }, >>> >> { .compatible = "ingenic,jz4760-mmc", .data = (void *) >>> >> JZ_MMC_JZ4760 }, >>> >> + { .compatible = "ingenic,jz4770-mmc", .data = (void *) >>> >> JZ_MMC_JZ4770 }, >>> >> { .compatible = "ingenic,jz4775-mmc", .data = (void *) >>> >> JZ_MMC_JZ4780 }, >>> >> { .compatible = "ingenic,jz4780-mmc", .data = (void *) >>> >> JZ_MMC_JZ4780 }, >>> >> { .compatible = "ingenic,x1000-mmc", .data = (void *) >>> >> JZ_MMC_X1000 }, >>> >> -- >>> >> 2.36.1 >>> >> >>> >>> >
Paul Cercueil <paul@crapouillou.net> writes: > Hi, > > (Ingenic SoCs maintainer here) > > Le ven. 18 nov. 2022 à 09:45:48 +0100, Ulf Hansson <ulf.hansson@linaro.org> a > écrit : >> On Tue, 8 Nov 2022 at 05:53, Siarhei Volkau <lis8215@gmail.com> wrote: >>> Some SoCs have one clock divider for all MMC units, thus changing one >>> affects others as well. This leads to random hangs and memory >>> corruptions, observed on the JZ4755 based device with two MMC slots >>> used at the same time. >> Urgh, that sounds like broken HW to me. >> The MMC blocks could share a parent clock (that would need a fixed >> rate for it to be applied), assuming there is a separate gate/divider >> available per block. But there isn't'? > > They do share a parent clock and have separate gates, and each MMC IP block has > an internal divider for the bus frequency derived from that shared clock. > >>> List of SoCs affected includes: JZ4725b, JZ4755, JZ4760 and JZ4760b. >>> However, the MMC driver doesn't distinguish JZ4760 and JZ4770 >>> which shall remain its behavior. For the JZ4755 is sufficient to >>> use JZ4725b's binding. JZ4750 is outside of the patch. >>> The MMC core has its own clock divisor, rather coarse but suitable well, >>> and it shall keep the role of tuning clock for the MMC host in that >>> case. >> The mmc core doesn't have a clock divisor, but it does control the bus >> clock frequency through the ->set_ios() host ops. It needs to do that, >> to be able to conform to the (e)MMC, SD and SDIO specifications. >> Can you please try to elaborate on the above, so I can better >> understand your point? > > Yes, I don't really understand the patch, TBH. > > The "clk_set_rate" call will only set the shared clock to the *maximum* clock > frequency (host->mmc->f_max) which should be the exact same across all MMC IPs. > > So it doesn't matter if it's set 3 times by 3 different instances of the IP, as > long as they all request the same value. Isn't the fact that 3 separate driver instances call clk_set_rate() on a shared clock kind of... problematic? Nor is it documented that all controllers need to use the same max-frequency. Given it's a shared clock which can't realistically be controlled by any of the consumers, I don't think it's unreasonable to assign the clock frequency from the DT, but it needs to be backward-compatible with old DTs. On another note, shouldn't the MMC mux parent be assigned from the DT? JZ4760 (and most other Ingenic SoCs) have multiple choices and I don't see the parent being assigned anywhere. Regards, Aidan > > Besides, I know for a fact that the mainline driver works fine on the JZ4760(B) > and JZ4725B. > > Finally... even if it was correct, this change would break compatibility with > old Device Tree files. > > Cheers, > -Paul > >>> Signed-off-by: Siarhei Volkau <lis8215@gmail.com> >> Kind regards >> Uffe >> >>> --- >>> drivers/mmc/host/jz4740_mmc.c | 10 +++++++++- >>> 1 file changed, 9 insertions(+), 1 deletion(-) >>> diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c >>> index dc2db9c18..d390ff31d 100644 >>> --- a/drivers/mmc/host/jz4740_mmc.c >>> +++ b/drivers/mmc/host/jz4740_mmc.c >>> @@ -114,6 +114,7 @@ enum jz4740_mmc_version { >>> JZ_MMC_JZ4740, >>> JZ_MMC_JZ4725B, >>> JZ_MMC_JZ4760, >>> + JZ_MMC_JZ4770, >>> JZ_MMC_JZ4780, >>> JZ_MMC_X1000, >>> }; >>> @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct >>> jz4740_mmc_host *host, int rate) >>> int real_rate; >>> jz4740_mmc_clock_disable(host); >>> - clk_set_rate(host->clk, host->mmc->f_max); >>> + >>> + /* >>> + * Changing rate on these SoCs affects other MMC units too. >>> + * Make sure the rate is configured properly by the CGU driver. >>> + */ >>> + if (host->version != JZ_MMC_JZ4725B && host->version != >>> JZ_MMC_JZ4760) >>> + clk_set_rate(host->clk, host->mmc->f_max); >>> real_rate = clk_get_rate(host->clk); >>> @@ -992,6 +999,7 @@ static const struct of_device_id jz4740_mmc_of_match[] >>> = { >>> { .compatible = "ingenic,jz4740-mmc", .data = (void *) >>> JZ_MMC_JZ4740 }, >>> { .compatible = "ingenic,jz4725b-mmc", .data = (void >>> *)JZ_MMC_JZ4725B }, >>> { .compatible = "ingenic,jz4760-mmc", .data = (void *) >>> JZ_MMC_JZ4760 }, >>> + { .compatible = "ingenic,jz4770-mmc", .data = (void *) >>> JZ_MMC_JZ4770 }, >>> { .compatible = "ingenic,jz4775-mmc", .data = (void *) >>> JZ_MMC_JZ4780 }, >>> { .compatible = "ingenic,jz4780-mmc", .data = (void *) >>> JZ_MMC_JZ4780 }, >>> { .compatible = "ingenic,x1000-mmc", .data = (void *) JZ_MMC_X1000 >>> }, >>> -- >>> 2.36.1 >>>
diff --git a/drivers/mmc/host/jz4740_mmc.c b/drivers/mmc/host/jz4740_mmc.c index dc2db9c18..d390ff31d 100644 --- a/drivers/mmc/host/jz4740_mmc.c +++ b/drivers/mmc/host/jz4740_mmc.c @@ -114,6 +114,7 @@ enum jz4740_mmc_version { JZ_MMC_JZ4740, JZ_MMC_JZ4725B, JZ_MMC_JZ4760, + JZ_MMC_JZ4770, JZ_MMC_JZ4780, JZ_MMC_X1000, }; @@ -887,7 +888,13 @@ static int jz4740_mmc_set_clock_rate(struct jz4740_mmc_host *host, int rate) int real_rate; jz4740_mmc_clock_disable(host); - clk_set_rate(host->clk, host->mmc->f_max); + + /* + * Changing rate on these SoCs affects other MMC units too. + * Make sure the rate is configured properly by the CGU driver. + */ + if (host->version != JZ_MMC_JZ4725B && host->version != JZ_MMC_JZ4760) + clk_set_rate(host->clk, host->mmc->f_max); real_rate = clk_get_rate(host->clk); @@ -992,6 +999,7 @@ static const struct of_device_id jz4740_mmc_of_match[] = { { .compatible = "ingenic,jz4740-mmc", .data = (void *) JZ_MMC_JZ4740 }, { .compatible = "ingenic,jz4725b-mmc", .data = (void *)JZ_MMC_JZ4725B }, { .compatible = "ingenic,jz4760-mmc", .data = (void *) JZ_MMC_JZ4760 }, + { .compatible = "ingenic,jz4770-mmc", .data = (void *) JZ_MMC_JZ4770 }, { .compatible = "ingenic,jz4775-mmc", .data = (void *) JZ_MMC_JZ4780 }, { .compatible = "ingenic,jz4780-mmc", .data = (void *) JZ_MMC_JZ4780 }, { .compatible = "ingenic,x1000-mmc", .data = (void *) JZ_MMC_X1000 },