| Message ID | 20180522120613.22526-1-yinbo.zhu@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 22 May 2018 at 14:06, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > From: yinbo.zhu <yinbo.zhu@nxp.com> > > Convert to use soc_device_match method to fix up eSDHC clock for > ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a > according to its datasheet. The maxmum speed for ls1021a eSDHC > high speed mode is 46.5MHz. Why not use mmc DT property "max-frequency" instead? Why exactly do you need a different max frequency depending on the selected speed mode? Kind regards Uffe > > Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com> > --- > drivers/mmc/host/sdhci-of-esdhc.c | 105 ++++++++++++++++++++++++++++++------- > 1 files changed, 85 insertions(+), 20 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c > index 4ffa6b1..4d82c6d 100644 > --- a/drivers/mmc/host/sdhci-of-esdhc.c > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > @@ -29,11 +29,58 @@ > #define VENDOR_V_22 0x12 > #define VENDOR_V_23 0x13 > > +struct esdhc_clk_fixup { > + /* SD speed modes */ > + long ds; > + long hs; > + long sdr12; > + long sdr25; > + long sdr50; > + long sdr104; > + long ddr50; > + /* MMC speed modes */ > + long mmc_ds; > + long mmc_hs; > + long hs200; > + long ddr52; > +}; > + > +static struct esdhc_clk_fixup ls1021a_esdhc_clk = { > + .mmc_hs = 46500000, > + .hs = 46500000, > +}; > + > +static struct esdhc_clk_fixup ls1046a_esdhc_clk = { > + .sdr104 = 167000000, > + .hs200 = 167000000, > +}; > + > +static struct esdhc_clk_fixup ls1012a_esdhc_clk = { > + .sdr104 = 125000000, > + .hs200 = 125000000, > +}; > + > +static struct esdhc_clk_fixup p1010_esdhc_clk = { > + .ds = 20000000, > + .hs = 40000000, > + .mmc_ds = 20000000, > + .mmc_hs = 42000000, > +}; > + > +static struct soc_device_attribute soc_esdhc_clk_fixup[] = { > + { .family = "QorIQ LS1021A", .data = &ls1021a_esdhc_clk}, > + { .family = "QorIQ LS1046A", .data = &ls1046a_esdhc_clk}, > + { .family = "QorIQ LS1012A", .data = &ls1012a_esdhc_clk}, > + { .family = "QorIQ P1010", .data = &p1010_esdhc_clk}, > + {}, > +}; > + > struct sdhci_esdhc { > u8 vendor_ver; > u8 spec_ver; > bool quirk_incorrect_hostver; > unsigned int peripheral_clock; > + const struct esdhc_clk_fixup *clk_fixup; > }; > > /** > @@ -485,6 +532,14 @@ static void esdhc_clock_enable(struct sdhci_host *host, bool enable) > } > } > > +static long esdhc_clock_fixup(long clock, long clock_standard, long fixup) > +{ > + if (!fixup) > + return clock; > + > + return (clock == clock_standard) ? fixup : clock; > +} > + > static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > { > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); > @@ -492,6 +547,7 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > int pre_div = 1; > int div = 1; > ktime_t timeout; > + long fixup; > u32 temp; > > host->mmc->actual_clock = 0; > @@ -505,26 +561,31 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > if (esdhc->vendor_ver < VENDOR_V_23) > pre_div = 2; > > - /* > - * Limit SD clock to 167MHz for ls1046a according to its datasheet > - */ > - if (clock > 167000000 && > - of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc")) > - clock = 167000000; > - > - /* > - * Limit SD clock to 125MHz for ls1012a according to its datasheet > - */ > - if (clock > 125000000 && > - of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc")) > - clock = 125000000; > - > - /* Workaround to reduce the clock frequency for p1010 esdhc */ > - if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) { > - if (clock > 20000000) > - clock -= 5000000; > - if (clock > 40000000) > - clock -= 5000000; > + switch (host->mmc->ios.timing) { > + case MMC_TIMING_LEGACY: > + fixup = esdhc->clk_fixup->ds; > + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); > + fixup = esdhc->clk_fixup->mmc_ds; > + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); > + break; > + case MMC_TIMING_SD_HS: > + fixup = esdhc->clk_fixup->hs; > + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); > + break; > + case MMC_TIMING_MMC_HS: > + fixup = esdhc->clk_fixup->mmc_hs; > + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); > + break; > + case MMC_TIMING_UHS_SDR104: > + fixup = esdhc->clk_fixup->sdr104; > + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); > + break; > + case MMC_TIMING_MMC_HS200: > + fixup = esdhc->clk_fixup->hs200; > + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); > + break; > + default: > + break; > } > > temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); > @@ -783,6 +844,7 @@ static SIMPLE_DEV_PM_OPS(esdhc_of_dev_pm_ops, > > static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) > { > + const struct soc_device_attribute *matches; > struct sdhci_pltfm_host *pltfm_host; > struct sdhci_esdhc *esdhc; > struct device_node *np; > @@ -802,6 +864,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) > else > esdhc->quirk_incorrect_hostver = false; > > + matches = soc_device_match(soc_esdhc_clk_fixup); > + if (matches) > + esdhc->clk_fixup = matches->data; > np = pdev->dev.of_node; > clk = of_clk_get(np, 0); > if (!IS_ERR(clk)) { > -- > 1.7.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBVbGYgSGFuc3NvbiBbbWFpbHRv OnVsZi5oYW5zc29uQGxpbmFyby5vcmddIA0KU2VudDogMjAxOOW5tDXmnIgyMuaXpSAyMDoxNg0K VG86IFlpbmJvIFpodSA8eWluYm8uemh1QG54cC5jb20+DQpDYzogWS5iLiBMdSA8eWFuZ2JvLmx1 QG54cC5jb20+OyBBZHJpYW4gSHVudGVyIDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT47IGxpbnV4 LW1tY0B2Z2VyLmtlcm5lbC5vcmc7IFhpYW9ibyBYaWUgPHhpYW9iby54aWVAbnhwLmNvbT4NClN1 YmplY3Q6IFJlOiBbUEFUQ0ggdjJdIG1tYzogc2RoY2ktb2YtZXNkaGM6IG1vZGlmeSB0aGUgc2Qg Y2xvY2sgaW4gc29jX2RldmljZV9tYXRjaCB3YXkNCg0KT24gMjIgTWF5IDIwMTggYXQgMTQ6MDYs IFlpbmJvIFpodSA8eWluYm8uemh1QG54cC5jb20+IHdyb3RlOg0KPiBGcm9tOiB5aW5iby56aHUg PHlpbmJvLnpodUBueHAuY29tPg0KPg0KPiBDb252ZXJ0IHRvIHVzZSBzb2NfZGV2aWNlX21hdGNo IG1ldGhvZCB0byBmaXggdXAgZVNESEMgY2xvY2sgZm9yIA0KPiBsczEwNDZhL2xzMTAxMmEvcDEw MTAuIEFsc28gYWRkIGVTREhDIGNsb2NrIGZpeHVwIGZvciBsczEwMjFhIA0KPiBhY2NvcmRpbmcg dG8gaXRzIGRhdGFzaGVldC4gVGhlIG1heG11bSBzcGVlZCBmb3IgbHMxMDIxYSBlU0RIQyBoaWdo IA0KPiBzcGVlZCBtb2RlIGlzIDQ2LjVNSHouDQoNCj5XaHkgbm90IHVzZSBtbWMgRFQgcHJvcGVy dHkgIm1heC1mcmVxdWVuY3kiIGluc3RlYWQ/DQoNCj5XaHkgZXhhY3RseSBkbyB5b3UgbmVlZCBh IGRpZmZlcmVudCBtYXggZnJlcXVlbmN5IGRlcGVuZGluZyBvbiB0aGUgc2VsZWN0ZWQgc3BlZWQg bW9kZT8NCg0KPktpbmQgcmVnYXJkcw0KPlVmZmUNCkFjY3JvZGluZyB0byBkYXRhc2hlZXQgdGhh dCB0aGUgZGlmZmVyZW50IG1heCBmcmVxdWVuY3kgZGVwZW5kaW5nIG9uIHRoZSBzbGVjdGVkIHNw ZWVkIG1vZGUgYW5kIFNvQywNCkluIHRoZSBjdXJyZW50IHN0YXRlIHRoYXQgd2hpY2ggb25seSBz aG93cyBvbmUgb2YgdGhlIG1heC1mcmVxdWVuY3ksIHNvIGl0IGNhbid0IHVzZSBtbWMgRFQgcHJv cGVydHkgIm1heC1mcmVxdWVuY3kiIGluc3RlYWQgIA0KDQpSZWdhcmRzDQpZaW5ibw0KPg0KPiBT aWduZWQtb2ZmLWJ5OiBZaW5ibyBaaHUgPHlpbmJvLnpodUBueHAuY29tPg0KPiAtLS0NCj4gIGRy aXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYyB8ICAxMDUgDQo+ICsrKysrKysrKysrKysr KysrKysrKysrKysrKysrKy0tLS0tLS0NCj4gIDEgZmlsZXMgY2hhbmdlZCwgODUgaW5zZXJ0aW9u cygrKSwgMjAgZGVsZXRpb25zKC0pDQo+DQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL21tYy9ob3N0 L3NkaGNpLW9mLWVzZGhjLmMgDQo+IGIvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5j DQo+IGluZGV4IDRmZmE2YjEuLjRkODJjNmQgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMvbW1jL2hv c3Qvc2RoY2ktb2YtZXNkaGMuYw0KPiArKysgYi9kcml2ZXJzL21tYy9ob3N0L3NkaGNpLW9mLWVz ZGhjLmMNCj4gQEAgLTI5LDExICsyOSw1OCBAQA0KPiAgI2RlZmluZSBWRU5ET1JfVl8yMiAgICAw eDEyDQo+ICAjZGVmaW5lIFZFTkRPUl9WXzIzICAgIDB4MTMNCj4NCj4gK3N0cnVjdCBlc2RoY19j bGtfZml4dXAgew0KPiArICAgICAgIC8qIFNEIHNwZWVkIG1vZGVzICovDQo+ICsgICAgICAgbG9u ZyBkczsNCj4gKyAgICAgICBsb25nIGhzOw0KPiArICAgICAgIGxvbmcgc2RyMTI7DQo+ICsgICAg ICAgbG9uZyBzZHIyNTsNCj4gKyAgICAgICBsb25nIHNkcjUwOw0KPiArICAgICAgIGxvbmcgc2Ry MTA0Ow0KPiArICAgICAgIGxvbmcgZGRyNTA7DQo+ICsgICAgICAgLyogTU1DIHNwZWVkIG1vZGVz ICovDQo+ICsgICAgICAgbG9uZyBtbWNfZHM7DQo+ICsgICAgICAgbG9uZyBtbWNfaHM7DQo+ICsg ICAgICAgbG9uZyBoczIwMDsNCj4gKyAgICAgICBsb25nIGRkcjUyOw0KPiArfTsNCj4gKw0KPiAr c3RhdGljIHN0cnVjdCBlc2RoY19jbGtfZml4dXAgbHMxMDIxYV9lc2RoY19jbGsgPSB7DQo+ICsg ICAgICAgLm1tY19ocyA9IDQ2NTAwMDAwLA0KPiArICAgICAgIC5ocyA9IDQ2NTAwMDAwLA0KPiAr fTsNCj4gKw0KPiArc3RhdGljIHN0cnVjdCBlc2RoY19jbGtfZml4dXAgbHMxMDQ2YV9lc2RoY19j bGsgPSB7DQo+ICsgICAgICAgLnNkcjEwNCA9IDE2NzAwMDAwMCwNCj4gKyAgICAgICAuaHMyMDAg PSAxNjcwMDAwMDAsDQo+ICt9Ow0KPiArDQo+ICtzdGF0aWMgc3RydWN0IGVzZGhjX2Nsa19maXh1 cCBsczEwMTJhX2VzZGhjX2NsayA9IHsNCj4gKyAgICAgICAuc2RyMTA0ID0gMTI1MDAwMDAwLA0K PiArICAgICAgIC5oczIwMCA9IDEyNTAwMDAwMCwNCj4gK307DQo+ICsNCj4gK3N0YXRpYyBzdHJ1 Y3QgZXNkaGNfY2xrX2ZpeHVwIHAxMDEwX2VzZGhjX2NsayA9IHsNCj4gKyAgICAgICAuZHMgPSAy MDAwMDAwMCwNCj4gKyAgICAgICAuaHMgPSA0MDAwMDAwMCwNCj4gKyAgICAgICAubW1jX2RzID0g MjAwMDAwMDAsDQo+ICsgICAgICAgLm1tY19ocyA9IDQyMDAwMDAwLA0KPiArfTsNCj4gKw0KPiAr c3RhdGljIHN0cnVjdCBzb2NfZGV2aWNlX2F0dHJpYnV0ZSBzb2NfZXNkaGNfY2xrX2ZpeHVwW10g PSB7DQo+ICsgICAgICAgeyAuZmFtaWx5ID0gIlFvcklRIExTMTAyMUEiLCAuZGF0YSA9ICZsczEw MjFhX2VzZGhjX2Nsa30sDQo+ICsgICAgICAgeyAuZmFtaWx5ID0gIlFvcklRIExTMTA0NkEiLCAu ZGF0YSA9ICZsczEwNDZhX2VzZGhjX2Nsa30sDQo+ICsgICAgICAgeyAuZmFtaWx5ID0gIlFvcklR IExTMTAxMkEiLCAuZGF0YSA9ICZsczEwMTJhX2VzZGhjX2Nsa30sDQo+ICsgICAgICAgeyAuZmFt aWx5ID0gIlFvcklRIFAxMDEwIiwgIC5kYXRhID0gJnAxMDEwX2VzZGhjX2Nsa30sDQo+ICsgICAg ICAge30sDQo+ICt9Ow0KPiArDQo+ICBzdHJ1Y3Qgc2RoY2lfZXNkaGMgew0KPiAgICAgICAgIHU4 IHZlbmRvcl92ZXI7DQo+ICAgICAgICAgdTggc3BlY192ZXI7DQo+ICAgICAgICAgYm9vbCBxdWly a19pbmNvcnJlY3RfaG9zdHZlcjsNCj4gICAgICAgICB1bnNpZ25lZCBpbnQgcGVyaXBoZXJhbF9j bG9jazsNCj4gKyAgICAgICBjb25zdCBzdHJ1Y3QgZXNkaGNfY2xrX2ZpeHVwICpjbGtfZml4dXA7 DQo+ICB9Ow0KPg0KPiAgLyoqDQo+IEBAIC00ODUsNiArNTMyLDE0IEBAIHN0YXRpYyB2b2lkIGVz ZGhjX2Nsb2NrX2VuYWJsZShzdHJ1Y3Qgc2RoY2lfaG9zdCAqaG9zdCwgYm9vbCBlbmFibGUpDQo+ ICAgICAgICAgfQ0KPiAgfQ0KPg0KPiArc3RhdGljIGxvbmcgZXNkaGNfY2xvY2tfZml4dXAobG9u ZyBjbG9jaywgbG9uZyBjbG9ja19zdGFuZGFyZCwgbG9uZyANCj4gK2ZpeHVwKSB7DQo+ICsgICAg ICAgaWYgKCFmaXh1cCkNCj4gKyAgICAgICAgICAgICAgIHJldHVybiBjbG9jazsNCj4gKw0KPiAr ICAgICAgIHJldHVybiAoY2xvY2sgPT0gY2xvY2tfc3RhbmRhcmQpID8gZml4dXAgOiBjbG9jazsg fQ0KPiArDQo+ICBzdGF0aWMgdm9pZCBlc2RoY19vZl9zZXRfY2xvY2soc3RydWN0IHNkaGNpX2hv c3QgKmhvc3QsIHVuc2lnbmVkIGludCANCj4gY2xvY2spICB7DQo+ICAgICAgICAgc3RydWN0IHNk aGNpX3BsdGZtX2hvc3QgKnBsdGZtX2hvc3QgPSBzZGhjaV9wcml2KGhvc3QpOyBAQCANCj4gLTQ5 Miw2ICs1NDcsNyBAQCBzdGF0aWMgdm9pZCBlc2RoY19vZl9zZXRfY2xvY2soc3RydWN0IHNkaGNp X2hvc3QgKmhvc3QsIHVuc2lnbmVkIGludCBjbG9jaykNCj4gICAgICAgICBpbnQgcHJlX2RpdiA9 IDE7DQo+ICAgICAgICAgaW50IGRpdiA9IDE7DQo+ICAgICAgICAga3RpbWVfdCB0aW1lb3V0Ow0K PiArICAgICAgIGxvbmcgZml4dXA7DQo+ICAgICAgICAgdTMyIHRlbXA7DQo+DQo+ICAgICAgICAg aG9zdC0+bW1jLT5hY3R1YWxfY2xvY2sgPSAwOw0KPiBAQCAtNTA1LDI2ICs1NjEsMzEgQEAgc3Rh dGljIHZvaWQgZXNkaGNfb2Zfc2V0X2Nsb2NrKHN0cnVjdCBzZGhjaV9ob3N0ICpob3N0LCB1bnNp Z25lZCBpbnQgY2xvY2spDQo+ICAgICAgICAgaWYgKGVzZGhjLT52ZW5kb3JfdmVyIDwgVkVORE9S X1ZfMjMpDQo+ICAgICAgICAgICAgICAgICBwcmVfZGl2ID0gMjsNCj4NCj4gLSAgICAgICAvKg0K PiAtICAgICAgICAqIExpbWl0IFNEIGNsb2NrIHRvIDE2N01IeiBmb3IgbHMxMDQ2YSBhY2NvcmRp bmcgdG8gaXRzIGRhdGFzaGVldA0KPiAtICAgICAgICAqLw0KPiAtICAgICAgIGlmIChjbG9jayA+ IDE2NzAwMDAwMCAmJg0KPiAtICAgICAgICAgICBvZl9maW5kX2NvbXBhdGlibGVfbm9kZShOVUxM LCBOVUxMLCAiZnNsLGxzMTA0NmEtZXNkaGMiKSkNCj4gLSAgICAgICAgICAgICAgIGNsb2NrID0g MTY3MDAwMDAwOw0KPiAtDQo+IC0gICAgICAgLyoNCj4gLSAgICAgICAgKiBMaW1pdCBTRCBjbG9j ayB0byAxMjVNSHogZm9yIGxzMTAxMmEgYWNjb3JkaW5nIHRvIGl0cyBkYXRhc2hlZXQNCj4gLSAg ICAgICAgKi8NCj4gLSAgICAgICBpZiAoY2xvY2sgPiAxMjUwMDAwMDAgJiYNCj4gLSAgICAgICAg ICAgb2ZfZmluZF9jb21wYXRpYmxlX25vZGUoTlVMTCwgTlVMTCwgImZzbCxsczEwMTJhLWVzZGhj IikpDQo+IC0gICAgICAgICAgICAgICBjbG9jayA9IDEyNTAwMDAwMDsNCj4gLQ0KPiAtICAgICAg IC8qIFdvcmthcm91bmQgdG8gcmVkdWNlIHRoZSBjbG9jayBmcmVxdWVuY3kgZm9yIHAxMDEwIGVz ZGhjICovDQo+IC0gICAgICAgaWYgKG9mX2ZpbmRfY29tcGF0aWJsZV9ub2RlKE5VTEwsIE5VTEws ICJmc2wscDEwMTAtZXNkaGMiKSkgew0KPiAtICAgICAgICAgICAgICAgaWYgKGNsb2NrID4gMjAw MDAwMDApDQo+IC0gICAgICAgICAgICAgICAgICAgICAgIGNsb2NrIC09IDUwMDAwMDA7DQo+IC0g ICAgICAgICAgICAgICBpZiAoY2xvY2sgPiA0MDAwMDAwMCkNCj4gLSAgICAgICAgICAgICAgICAg ICAgICAgY2xvY2sgLT0gNTAwMDAwMDsNCj4gKyAgICAgICBzd2l0Y2ggKGhvc3QtPm1tYy0+aW9z LnRpbWluZykgew0KPiArICAgICAgIGNhc2UgTU1DX1RJTUlOR19MRUdBQ1k6DQo+ICsgICAgICAg ICAgICAgICBmaXh1cCA9IGVzZGhjLT5jbGtfZml4dXAtPmRzOw0KPiArICAgICAgICAgICAgICAg Y2xvY2sgPSBlc2RoY19jbG9ja19maXh1cChjbG9jaywgRlVMTF9TUEVFRF9NQVhfRFRSLCBmaXh1 cCk7DQo+ICsgICAgICAgICAgICAgICBmaXh1cCA9IGVzZGhjLT5jbGtfZml4dXAtPm1tY19kczsN Cj4gKyAgICAgICAgICAgICAgIGNsb2NrID0gZXNkaGNfY2xvY2tfZml4dXAoY2xvY2ssIE1NQ19I SUdIXzI2X01BWF9EVFIsIGZpeHVwKTsNCj4gKyAgICAgICAgICAgICAgIGJyZWFrOw0KPiArICAg ICAgIGNhc2UgTU1DX1RJTUlOR19TRF9IUzoNCj4gKyAgICAgICAgICAgICAgIGZpeHVwID0gZXNk aGMtPmNsa19maXh1cC0+aHM7DQo+ICsgICAgICAgICAgICAgICBjbG9jayA9IGVzZGhjX2Nsb2Nr X2ZpeHVwKGNsb2NrLCBISUdIX1NQRUVEX01BWF9EVFIsIGZpeHVwKTsNCj4gKyAgICAgICAgICAg ICAgIGJyZWFrOw0KPiArICAgICAgIGNhc2UgTU1DX1RJTUlOR19NTUNfSFM6DQo+ICsgICAgICAg ICAgICAgICBmaXh1cCA9IGVzZGhjLT5jbGtfZml4dXAtPm1tY19oczsNCj4gKyAgICAgICAgICAg ICAgIGNsb2NrID0gZXNkaGNfY2xvY2tfZml4dXAoY2xvY2ssIE1NQ19ISUdIXzUyX01BWF9EVFIs IGZpeHVwKTsNCj4gKyAgICAgICAgICAgICAgIGJyZWFrOw0KPiArICAgICAgIGNhc2UgTU1DX1RJ TUlOR19VSFNfU0RSMTA0Og0KPiArICAgICAgICAgICAgICAgZml4dXAgPSBlc2RoYy0+Y2xrX2Zp eHVwLT5zZHIxMDQ7DQo+ICsgICAgICAgICAgICAgICBjbG9jayA9IGVzZGhjX2Nsb2NrX2ZpeHVw KGNsb2NrLCBVSFNfU0RSMTA0X01BWF9EVFIsIGZpeHVwKTsNCj4gKyAgICAgICAgICAgICAgIGJy ZWFrOw0KPiArICAgICAgIGNhc2UgTU1DX1RJTUlOR19NTUNfSFMyMDA6DQo+ICsgICAgICAgICAg ICAgICBmaXh1cCA9IGVzZGhjLT5jbGtfZml4dXAtPmhzMjAwOw0KPiArICAgICAgICAgICAgICAg Y2xvY2sgPSBlc2RoY19jbG9ja19maXh1cChjbG9jaywgTU1DX0hTMjAwX01BWF9EVFIsIGZpeHVw KTsNCj4gKyAgICAgICAgICAgICAgIGJyZWFrOw0KPiArICAgICAgIGRlZmF1bHQ6DQo+ICsgICAg ICAgICAgICAgICBicmVhazsNCj4gICAgICAgICB9DQo+DQo+ICAgICAgICAgdGVtcCA9IHNkaGNp X3JlYWRsKGhvc3QsIEVTREhDX1NZU1RFTV9DT05UUk9MKTsgQEAgLTc4Myw2IA0KPiArODQ0LDcg QEAgc3RhdGljIFNJTVBMRV9ERVZfUE1fT1BTKGVzZGhjX29mX2Rldl9wbV9vcHMsDQo+DQo+ICBz dGF0aWMgdm9pZCBlc2RoY19pbml0KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYsIHN0cnVj dCANCj4gc2RoY2lfaG9zdCAqaG9zdCkgIHsNCj4gKyAgICAgICBjb25zdCBzdHJ1Y3Qgc29jX2Rl dmljZV9hdHRyaWJ1dGUgKm1hdGNoZXM7DQo+ICAgICAgICAgc3RydWN0IHNkaGNpX3BsdGZtX2hv c3QgKnBsdGZtX2hvc3Q7DQo+ICAgICAgICAgc3RydWN0IHNkaGNpX2VzZGhjICplc2RoYzsNCj4g ICAgICAgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiBAQCAtODAyLDYgKzg2NCw5IEBAIHN0 YXRpYyB2b2lkIGVzZGhjX2luaXQoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldiwgc3RydWN0 IHNkaGNpX2hvc3QgKmhvc3QpDQo+ICAgICAgICAgZWxzZQ0KPiAgICAgICAgICAgICAgICAgZXNk aGMtPnF1aXJrX2luY29ycmVjdF9ob3N0dmVyID0gZmFsc2U7DQo+DQo+ICsgICAgICAgbWF0Y2hl cyA9IHNvY19kZXZpY2VfbWF0Y2goc29jX2VzZGhjX2Nsa19maXh1cCk7DQo+ICsgICAgICAgaWYg KG1hdGNoZXMpDQo+ICsgICAgICAgICAgICAgICBlc2RoYy0+Y2xrX2ZpeHVwID0gbWF0Y2hlcy0+ ZGF0YTsNCj4gICAgICAgICBucCA9IHBkZXYtPmRldi5vZl9ub2RlOw0KPiAgICAgICAgIGNsayA9 IG9mX2Nsa19nZXQobnAsIDApOw0KPiAgICAgICAgIGlmICghSVNfRVJSKGNsaykpIHsNCj4gLS0N Cj4gMS43LjENCj4NCj4gLS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQg dGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LW1tYyIgDQo+IGluIHRoZSBib2R5IG9mIGEgbWVz c2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1vcmUgbWFqb3Jkb21vIA0KPiBpbmZv IGF0ICANCj4gaHR0cHM6Ly9lbWVhMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwJTNBJTJGJTJGdmdlcg0KPiAua2VybmVsLm9yZyUyRm1ham9yZG9tby1pbmZvLmh0 bWwmZGF0YT0wMiU3QzAxJTdDeWluYm8uemh1JTQwbnhwLmNvbSU3DQo+IEMxYzVmYzdmM2MxYjY0 YzY3NWZkYjA4ZDViZmRkYmViMCU3QzY4NmVhMWQzYmMyYjRjNmZhOTJjZDk5YzVjMzAxNjM1JTcN Cj4gQzAlN0MwJTdDNjM2NjI1ODgxNDc1MDIwOTg1JnNkYXRhPU93TVFNR1hWdXhvNHF5eHFVekFE TTZLZyUyQm96ck0zSHVvWA0KPiBRVFdXekZiTkklM0QmcmVzZXJ2ZWQ9MA0K -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 May 2018 at 05:50, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > > > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: 2018年5月22日 20:16 > To: Yinbo Zhu <yinbo.zhu@nxp.com> > Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie <xiaobo.xie@nxp.com> > Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in soc_device_match way > > On 22 May 2018 at 14:06, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >> From: yinbo.zhu <yinbo.zhu@nxp.com> >> >> Convert to use soc_device_match method to fix up eSDHC clock for >> ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a >> according to its datasheet. The maxmum speed for ls1021a eSDHC high >> speed mode is 46.5MHz. > >>Why not use mmc DT property "max-frequency" instead? > >>Why exactly do you need a different max frequency depending on the selected speed mode? > >>Kind regards >>Uffe > Accroding to datasheet that the different max frequency depending on the slected speed mode and SoC, That it depends on the SoC, that I am or course fine with. My point is rather that I think it depends on the actual slot connector (or board), rather that on the speed mode. For example, one port may have an eMMC and for some reason it can be run in a speed mode using full clock rate. Another one may be an SD-card slot, and perhaps because of some external logic, the signal quality doesn't survive a too high clock-rate. Etc. Other SoCs and platforms works like this, I am sure yours do as well. No? > In the current state that which only shows one of the max-frequency, so it can't use mmc DT property "max-frequency" instead According to my comments above, could you please investigate once more, whether really "max-frequency" can be used as the DT binding? If it can't then I think we should consider introducing new mmc DT bindings instead. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 May 2018 at 10:55, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: 2018年5月23日 14:41 > To: Yinbo Zhu <yinbo.zhu@nxp.com> > Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie <xiaobo.xie@nxp.com> > Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in soc_device_match way > > On 23 May 2018 at 05:50, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >> >> >> -----Original Message----- >> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] >> Sent: 2018年5月22日 20:16 >> To: Yinbo Zhu <yinbo.zhu@nxp.com> >> Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter >> <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie >> <xiaobo.xie@nxp.com> >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >> soc_device_match way >> >> On 22 May 2018 at 14:06, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >>> From: yinbo.zhu <yinbo.zhu@nxp.com> >>> >>> Convert to use soc_device_match method to fix up eSDHC clock for >>> ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a >>> according to its datasheet. The maxmum speed for ls1021a eSDHC high >>> speed mode is 46.5MHz. >> >>>Why not use mmc DT property "max-frequency" instead? >> >>>Why exactly do you need a different max frequency depending on the selected speed mode? >> >>>Kind regards >>>Uffe >> Accroding to datasheet that the different max frequency depending on >> the slected speed mode and SoC, > >>That it depends on the SoC, that I am or course fine with. > >>My point is rather that I think it depends on the actual slot connector (or board), rather that on the speed mode. >>For example, one port may have an eMMC and for some reason it can be run in a speed mode using full clock rate. Another >>one may be an SD-card slot, and perhaps because of some external logic, the signal quality doesn't survive a too high clock- >>rate. Etc. > >>Other SoCs and platforms works like this, I am sure yours do as well. No? > >> In the current state that which only shows one of the max-frequency, >> so it can't use mmc DT property "max-frequency" instead > >>According to my comments above, could you please investigate once more, whether really "max-frequency" can be used as >>the DT binding? > >>If it can't then I think we should consider introducing new mmc DT bindings instead. > >>[...] > >>Kind regards >>Uffe > Hi Uffe, > > Attachment is some pictures which in data sheet, I think it can explain that max frequency depending on the slected speed mode and SoC, You can have a look. > Thanks, yes, this seems to confirm it. Kind of weird that none until now have raised issues about similar constraints to be needed. So, we can either use your suggested solution, via soc_device_match() method, if you prefer, else we need to invent a new DT property for each speed mode constraint. Both works for me, so whatever you prefer!? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 22/05/18 15:06, Yinbo Zhu wrote: > From: yinbo.zhu <yinbo.zhu@nxp.com> > > Convert to use soc_device_match method to fix up eSDHC clock for > ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a > according to its datasheet. The maxmum speed for ls1021a eSDHC > high speed mode is 46.5MHz. > > Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com> > --- > drivers/mmc/host/sdhci-of-esdhc.c | 105 ++++++++++++++++++++++++++++++------- > 1 files changed, 85 insertions(+), 20 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c > index 4ffa6b1..4d82c6d 100644 > --- a/drivers/mmc/host/sdhci-of-esdhc.c > +++ b/drivers/mmc/host/sdhci-of-esdhc.c > @@ -29,11 +29,58 @@ > #define VENDOR_V_22 0x12 > #define VENDOR_V_23 0x13 > > +struct esdhc_clk_fixup { > + /* SD speed modes */ > + long ds; > + long hs; > + long sdr12; > + long sdr25; > + long sdr50; > + long sdr104; > + long ddr50; > + /* MMC speed modes */ > + long mmc_ds; > + long mmc_hs; > + long hs200; > + long ddr52; > +}; > + > +static struct esdhc_clk_fixup ls1021a_esdhc_clk = { > + .mmc_hs = 46500000, > + .hs = 46500000, > +}; > + > +static struct esdhc_clk_fixup ls1046a_esdhc_clk = { > + .sdr104 = 167000000, > + .hs200 = 167000000, > +}; > + > +static struct esdhc_clk_fixup ls1012a_esdhc_clk = { > + .sdr104 = 125000000, > + .hs200 = 125000000, > +}; > + > +static struct esdhc_clk_fixup p1010_esdhc_clk = { > + .ds = 20000000, > + .hs = 40000000, > + .mmc_ds = 20000000, > + .mmc_hs = 42000000, > +}; > + > +static struct soc_device_attribute soc_esdhc_clk_fixup[] = { > + { .family = "QorIQ LS1021A", .data = &ls1021a_esdhc_clk}, > + { .family = "QorIQ LS1046A", .data = &ls1046a_esdhc_clk}, > + { .family = "QorIQ LS1012A", .data = &ls1012a_esdhc_clk}, > + { .family = "QorIQ P1010", .data = &p1010_esdhc_clk}, > + {}, > +}; These static structs could be const also. > + > struct sdhci_esdhc { > u8 vendor_ver; > u8 spec_ver; > bool quirk_incorrect_hostver; > unsigned int peripheral_clock; > + const struct esdhc_clk_fixup *clk_fixup; > }; > > /** > @@ -485,6 +532,14 @@ static void esdhc_clock_enable(struct sdhci_host *host, bool enable) > } > } > > +static long esdhc_clock_fixup(long clock, long clock_standard, long fixup) > +{ > + if (!fixup) > + return clock; > + > + return (clock == clock_standard) ? fixup : clock; > +} > + > static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > { > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); > @@ -492,6 +547,7 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > int pre_div = 1; > int div = 1; > ktime_t timeout; > + long fixup; > u32 temp; > > host->mmc->actual_clock = 0; > @@ -505,26 +561,31 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) > if (esdhc->vendor_ver < VENDOR_V_23) > pre_div = 2; > > - /* > - * Limit SD clock to 167MHz for ls1046a according to its datasheet > - */ > - if (clock > 167000000 && > - of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc")) > - clock = 167000000; > - > - /* > - * Limit SD clock to 125MHz for ls1012a according to its datasheet > - */ > - if (clock > 125000000 && > - of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc")) > - clock = 125000000; > - > - /* Workaround to reduce the clock frequency for p1010 esdhc */ > - if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) { > - if (clock > 20000000) > - clock -= 5000000; > - if (clock > 40000000) > - clock -= 5000000; > + switch (host->mmc->ios.timing) { > + case MMC_TIMING_LEGACY: > + fixup = esdhc->clk_fixup->ds; > + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); > + fixup = esdhc->clk_fixup->mmc_ds; > + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); > + break; > + case MMC_TIMING_SD_HS: > + fixup = esdhc->clk_fixup->hs; > + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); > + break; > + case MMC_TIMING_MMC_HS: > + fixup = esdhc->clk_fixup->mmc_hs; > + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); > + break; > + case MMC_TIMING_UHS_SDR104: > + fixup = esdhc->clk_fixup->sdr104; > + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); > + break; > + case MMC_TIMING_MMC_HS200: > + fixup = esdhc->clk_fixup->hs200; > + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); > + break; > + default: > + break; This logic looks fragile. I would expect to see something that looks more like: max_clk = esdhc->clk_fixup[host->mmc->ios.timing]; if (max_clk && clock > max_clk) clock = max_CLK; > } > > temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); > @@ -783,6 +844,7 @@ static SIMPLE_DEV_PM_OPS(esdhc_of_dev_pm_ops, > > static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) > { > + const struct soc_device_attribute *matches; > struct sdhci_pltfm_host *pltfm_host; > struct sdhci_esdhc *esdhc; > struct device_node *np; > @@ -802,6 +864,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) > else > esdhc->quirk_incorrect_hostver = false; > > + matches = soc_device_match(soc_esdhc_clk_fixup); > + if (matches) > + esdhc->clk_fixup = matches->data; > np = pdev->dev.of_node; > clk = of_clk_get(np, 0); > if (!IS_ERR(clk)) { > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBZHJpYW4gSHVudGVyIFttYWls dG86YWRyaWFuLmh1bnRlckBpbnRlbC5jb21dIA0KU2VudDogMjAxOOW5tDXmnIgyNOaXpSAxNjo1 OA0KVG86IFlpbmJvIFpodSA8eWluYm8uemh1QG54cC5jb20+OyBZLmIuIEx1IDx5YW5nYm8ubHVA bnhwLmNvbT47IGxpbnV4LW1tY0B2Z2VyLmtlcm5lbC5vcmcNCkNjOiBYaWFvYm8gWGllIDx4aWFv Ym8ueGllQG54cC5jb20+DQpTdWJqZWN0OiBSZTogW1BBVENIIHYyXSBtbWM6IHNkaGNpLW9mLWVz ZGhjOiBtb2RpZnkgdGhlIHNkIGNsb2NrIGluIHNvY19kZXZpY2VfbWF0Y2ggd2F5DQoNCk9uIDIy LzA1LzE4IDE1OjA2LCBZaW5ibyBaaHUgd3JvdGU6DQo+IEZyb206IHlpbmJvLnpodSA8eWluYm8u emh1QG54cC5jb20+DQo+IA0KPiBDb252ZXJ0IHRvIHVzZSBzb2NfZGV2aWNlX21hdGNoIG1ldGhv ZCB0byBmaXggdXAgZVNESEMgY2xvY2sgZm9yIA0KPiBsczEwNDZhL2xzMTAxMmEvcDEwMTAuIEFs c28gYWRkIGVTREhDIGNsb2NrIGZpeHVwIGZvciBsczEwMjFhIA0KPiBhY2NvcmRpbmcgdG8gaXRz IGRhdGFzaGVldC4gVGhlIG1heG11bSBzcGVlZCBmb3IgbHMxMDIxYSBlU0RIQyBoaWdoIA0KPiBz cGVlZCBtb2RlIGlzIDQ2LjVNSHouDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBZaW5ibyBaaHUgPHlp bmJvLnpodUBueHAuY29tPg0KPiAtLS0NCj4gIGRyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNk aGMuYyB8ICAxMDUgDQo+ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0NCj4g IDEgZmlsZXMgY2hhbmdlZCwgODUgaW5zZXJ0aW9ucygrKSwgMjAgZGVsZXRpb25zKC0pDQo+IA0K PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jIA0KPiBiL2Ry aXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYw0KPiBpbmRleCA0ZmZhNmIxLi40ZDgyYzZk IDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL21tYy9ob3N0L3NkaGNpLW9mLWVzZGhjLmMNCj4gKysr IGIvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jDQo+IEBAIC0yOSwxMSArMjksNTgg QEANCj4gICNkZWZpbmUgVkVORE9SX1ZfMjIJMHgxMg0KPiAgI2RlZmluZSBWRU5ET1JfVl8yMwkw eDEzDQo+ICANCj4gK3N0cnVjdCBlc2RoY19jbGtfZml4dXAgew0KPiArCS8qIFNEIHNwZWVkIG1v ZGVzICovDQo+ICsJbG9uZyBkczsNCj4gKwlsb25nIGhzOw0KPiArCWxvbmcgc2RyMTI7DQo+ICsJ bG9uZyBzZHIyNTsNCj4gKwlsb25nIHNkcjUwOw0KPiArCWxvbmcgc2RyMTA0Ow0KPiArCWxvbmcg ZGRyNTA7DQo+ICsJLyogTU1DIHNwZWVkIG1vZGVzICovDQo+ICsJbG9uZyBtbWNfZHM7DQo+ICsJ bG9uZyBtbWNfaHM7DQo+ICsJbG9uZyBoczIwMDsNCj4gKwlsb25nIGRkcjUyOw0KPiArfTsNCj4g Kw0KPiArc3RhdGljIHN0cnVjdCBlc2RoY19jbGtfZml4dXAgbHMxMDIxYV9lc2RoY19jbGsgPSB7 DQo+ICsJLm1tY19ocyA9IDQ2NTAwMDAwLA0KPiArCS5ocyA9IDQ2NTAwMDAwLA0KPiArfTsNCj4g Kw0KPiArc3RhdGljIHN0cnVjdCBlc2RoY19jbGtfZml4dXAgbHMxMDQ2YV9lc2RoY19jbGsgPSB7 DQo+ICsJLnNkcjEwNCA9IDE2NzAwMDAwMCwNCj4gKwkuaHMyMDAgPSAxNjcwMDAwMDAsDQo+ICt9 Ow0KPiArDQo+ICtzdGF0aWMgc3RydWN0IGVzZGhjX2Nsa19maXh1cCBsczEwMTJhX2VzZGhjX2Ns ayA9IHsNCj4gKwkuc2RyMTA0ID0gMTI1MDAwMDAwLA0KPiArCS5oczIwMCA9IDEyNTAwMDAwMCwN Cj4gK307DQo+ICsNCj4gK3N0YXRpYyBzdHJ1Y3QgZXNkaGNfY2xrX2ZpeHVwIHAxMDEwX2VzZGhj X2NsayA9IHsNCj4gKwkuZHMgPSAyMDAwMDAwMCwNCj4gKwkuaHMgPSA0MDAwMDAwMCwNCj4gKwku bW1jX2RzID0gMjAwMDAwMDAsDQo+ICsJLm1tY19ocyA9IDQyMDAwMDAwLA0KPiArfTsNCj4gKw0K PiArc3RhdGljIHN0cnVjdCBzb2NfZGV2aWNlX2F0dHJpYnV0ZSBzb2NfZXNkaGNfY2xrX2ZpeHVw W10gPSB7DQo+ICsJeyAuZmFtaWx5ID0gIlFvcklRIExTMTAyMUEiLCAuZGF0YSA9ICZsczEwMjFh X2VzZGhjX2Nsa30sDQo+ICsJeyAuZmFtaWx5ID0gIlFvcklRIExTMTA0NkEiLCAuZGF0YSA9ICZs czEwNDZhX2VzZGhjX2Nsa30sDQo+ICsJeyAuZmFtaWx5ID0gIlFvcklRIExTMTAxMkEiLCAuZGF0 YSA9ICZsczEwMTJhX2VzZGhjX2Nsa30sDQo+ICsJeyAuZmFtaWx5ID0gIlFvcklRIFAxMDEwIiwg IC5kYXRhID0gJnAxMDEwX2VzZGhjX2Nsa30sDQo+ICsJe30sDQo+ICt9Ow0KDQo+VGhlc2Ugc3Rh dGljIHN0cnVjdHMgY291bGQgYmUgY29uc3QgYWxzby4NClRoYW5rcywgSSdtIGdvaW5nIHRvIGNv cnJlY3QgdGhhdA0KPiArDQo+ICBzdHJ1Y3Qgc2RoY2lfZXNkaGMgew0KPiAgCXU4IHZlbmRvcl92 ZXI7DQo+ICAJdTggc3BlY192ZXI7DQo+ICAJYm9vbCBxdWlya19pbmNvcnJlY3RfaG9zdHZlcjsN Cj4gIAl1bnNpZ25lZCBpbnQgcGVyaXBoZXJhbF9jbG9jazsNCj4gKwljb25zdCBzdHJ1Y3QgZXNk aGNfY2xrX2ZpeHVwICpjbGtfZml4dXA7DQo+ICB9Ow0KPiAgDQo+ICAvKioNCj4gQEAgLTQ4NSw2 ICs1MzIsMTQgQEAgc3RhdGljIHZvaWQgZXNkaGNfY2xvY2tfZW5hYmxlKHN0cnVjdCBzZGhjaV9o b3N0ICpob3N0LCBib29sIGVuYWJsZSkNCj4gIAl9DQo+ICB9DQo+ICANCj4gK3N0YXRpYyBsb25n IGVzZGhjX2Nsb2NrX2ZpeHVwKGxvbmcgY2xvY2ssIGxvbmcgY2xvY2tfc3RhbmRhcmQsIGxvbmcg DQo+ICtmaXh1cCkgew0KPiArCWlmICghZml4dXApDQo+ICsJCXJldHVybiBjbG9jazsNCj4gKw0K PiArCXJldHVybiAoY2xvY2sgPT0gY2xvY2tfc3RhbmRhcmQpID8gZml4dXAgOiBjbG9jazsgfQ0K PiArDQo+ICBzdGF0aWMgdm9pZCBlc2RoY19vZl9zZXRfY2xvY2soc3RydWN0IHNkaGNpX2hvc3Qg Kmhvc3QsIHVuc2lnbmVkIGludCANCj4gY2xvY2spICB7DQo+ICAJc3RydWN0IHNkaGNpX3BsdGZt X2hvc3QgKnBsdGZtX2hvc3QgPSBzZGhjaV9wcml2KGhvc3QpOyBAQCAtNDkyLDYgDQo+ICs1NDcs NyBAQCBzdGF0aWMgdm9pZCBlc2RoY19vZl9zZXRfY2xvY2soc3RydWN0IHNkaGNpX2hvc3QgKmhv c3QsIHVuc2lnbmVkIGludCBjbG9jaykNCj4gIAlpbnQgcHJlX2RpdiA9IDE7DQo+ICAJaW50IGRp diA9IDE7DQo+ICAJa3RpbWVfdCB0aW1lb3V0Ow0KPiArCWxvbmcgZml4dXA7DQo+ICAJdTMyIHRl bXA7DQo+ICANCj4gIAlob3N0LT5tbWMtPmFjdHVhbF9jbG9jayA9IDA7DQo+IEBAIC01MDUsMjYg KzU2MSwzMSBAQCBzdGF0aWMgdm9pZCBlc2RoY19vZl9zZXRfY2xvY2soc3RydWN0IHNkaGNpX2hv c3QgKmhvc3QsIHVuc2lnbmVkIGludCBjbG9jaykNCj4gIAlpZiAoZXNkaGMtPnZlbmRvcl92ZXIg PCBWRU5ET1JfVl8yMykNCj4gIAkJcHJlX2RpdiA9IDI7DQo+ICANCj4gLQkvKg0KPiAtCSAqIExp bWl0IFNEIGNsb2NrIHRvIDE2N01IeiBmb3IgbHMxMDQ2YSBhY2NvcmRpbmcgdG8gaXRzIGRhdGFz aGVldA0KPiAtCSAqLw0KPiAtCWlmIChjbG9jayA+IDE2NzAwMDAwMCAmJg0KPiAtCSAgICBvZl9m aW5kX2NvbXBhdGlibGVfbm9kZShOVUxMLCBOVUxMLCAiZnNsLGxzMTA0NmEtZXNkaGMiKSkNCj4g LQkJY2xvY2sgPSAxNjcwMDAwMDA7DQo+IC0NCj4gLQkvKg0KPiAtCSAqIExpbWl0IFNEIGNsb2Nr IHRvIDEyNU1IeiBmb3IgbHMxMDEyYSBhY2NvcmRpbmcgdG8gaXRzIGRhdGFzaGVldA0KPiAtCSAq Lw0KPiAtCWlmIChjbG9jayA+IDEyNTAwMDAwMCAmJg0KPiAtCSAgICBvZl9maW5kX2NvbXBhdGli bGVfbm9kZShOVUxMLCBOVUxMLCAiZnNsLGxzMTAxMmEtZXNkaGMiKSkNCj4gLQkJY2xvY2sgPSAx MjUwMDAwMDA7DQo+IC0NCj4gLQkvKiBXb3JrYXJvdW5kIHRvIHJlZHVjZSB0aGUgY2xvY2sgZnJl cXVlbmN5IGZvciBwMTAxMCBlc2RoYyAqLw0KPiAtCWlmIChvZl9maW5kX2NvbXBhdGlibGVfbm9k ZShOVUxMLCBOVUxMLCAiZnNsLHAxMDEwLWVzZGhjIikpIHsNCj4gLQkJaWYgKGNsb2NrID4gMjAw MDAwMDApDQo+IC0JCQljbG9jayAtPSA1MDAwMDAwOw0KPiAtCQlpZiAoY2xvY2sgPiA0MDAwMDAw MCkNCj4gLQkJCWNsb2NrIC09IDUwMDAwMDA7DQo+ICsJc3dpdGNoIChob3N0LT5tbWMtPmlvcy50 aW1pbmcpIHsNCj4gKwljYXNlIE1NQ19USU1JTkdfTEVHQUNZOg0KPiArCQlmaXh1cCA9IGVzZGhj LT5jbGtfZml4dXAtPmRzOw0KPiArCQljbG9jayA9IGVzZGhjX2Nsb2NrX2ZpeHVwKGNsb2NrLCBG VUxMX1NQRUVEX01BWF9EVFIsIGZpeHVwKTsNCj4gKwkJZml4dXAgPSBlc2RoYy0+Y2xrX2ZpeHVw LT5tbWNfZHM7DQo+ICsJCWNsb2NrID0gZXNkaGNfY2xvY2tfZml4dXAoY2xvY2ssIE1NQ19ISUdI XzI2X01BWF9EVFIsIGZpeHVwKTsNCj4gKwkJYnJlYWs7DQo+ICsJY2FzZSBNTUNfVElNSU5HX1NE X0hTOg0KPiArCQlmaXh1cCA9IGVzZGhjLT5jbGtfZml4dXAtPmhzOw0KPiArCQljbG9jayA9IGVz ZGhjX2Nsb2NrX2ZpeHVwKGNsb2NrLCBISUdIX1NQRUVEX01BWF9EVFIsIGZpeHVwKTsNCj4gKwkJ YnJlYWs7DQo+ICsJY2FzZSBNTUNfVElNSU5HX01NQ19IUzoNCj4gKwkJZml4dXAgPSBlc2RoYy0+ Y2xrX2ZpeHVwLT5tbWNfaHM7DQo+ICsJCWNsb2NrID0gZXNkaGNfY2xvY2tfZml4dXAoY2xvY2ss IE1NQ19ISUdIXzUyX01BWF9EVFIsIGZpeHVwKTsNCj4gKwkJYnJlYWs7DQo+ICsJY2FzZSBNTUNf VElNSU5HX1VIU19TRFIxMDQ6DQo+ICsJCWZpeHVwID0gZXNkaGMtPmNsa19maXh1cC0+c2RyMTA0 Ow0KPiArCQljbG9jayA9IGVzZGhjX2Nsb2NrX2ZpeHVwKGNsb2NrLCBVSFNfU0RSMTA0X01BWF9E VFIsIGZpeHVwKTsNCj4gKwkJYnJlYWs7DQo+ICsJY2FzZSBNTUNfVElNSU5HX01NQ19IUzIwMDoN Cj4gKwkJZml4dXAgPSBlc2RoYy0+Y2xrX2ZpeHVwLT5oczIwMDsNCj4gKwkJY2xvY2sgPSBlc2Ro Y19jbG9ja19maXh1cChjbG9jaywgTU1DX0hTMjAwX01BWF9EVFIsIGZpeHVwKTsNCj4gKwkJYnJl YWs7DQo+ICsJZGVmYXVsdDoNCj4gKwkJYnJlYWs7DQoNCj5UaGlzIGxvZ2ljIGxvb2tzIGZyYWdp bGUuICBJIHdvdWxkIGV4cGVjdCB0byBzZWUgc29tZXRoaW5nIHRoYXQgbG9va3MgbW9yZSBsaWtl Og0KDQo+CW1heF9jbGsgPSBlc2RoYy0+Y2xrX2ZpeHVwW2hvc3QtPm1tYy0+aW9zLnRpbWluZ107 DQo+CWlmIChtYXhfY2xrICYmIGNsb2NrID4gbWF4X2NsaykNCj4JCWNsb2NrID0gbWF4X0NMSzsN CkhpIEFkcmlhbiBIdW50ZXIsDQoNClRoYW5rcyB5b3VyIGFkdmljZSwgeW91ciB3YXkgd2lsbCBt YWtlIGNvZGUgbG9naWMgbW9yZSBjbGVhcmx5LCBidXQNCk1NQyBkZWZhdWx0IG1heCBjbG9jayBp cyAyNk1IeiwgU0QgZGVmYXVsdCBtYXggY2xvY2sgaXMgMjVNSHosIHRoZXkgYWxsIHVzZSB0aGUg c2FtZSBpb3MudGltaW5nIGluIHB1YmxpYyBjb2RlLA0KSWYgdXNlIGFycmF5LCBUaGVyZSB3aWxs IGJlIGEgY29uZmxpY3QsIERvIHlvdSBoYXZlIGFueSBnb29kIHdheXMgdG8gcmVzb2x2ZSB0aGUg Y29uZmxpY3QuDQpUaGFua3MuDQoNClJlZ2FyZHMsDQpZaW5ibw0KDQo+ICAJfQ0KPiAgDQo+ICAJ dGVtcCA9IHNkaGNpX3JlYWRsKGhvc3QsIEVTREhDX1NZU1RFTV9DT05UUk9MKTsgQEAgLTc4Myw2 ICs4NDQsNyBAQCANCj4gc3RhdGljIFNJTVBMRV9ERVZfUE1fT1BTKGVzZGhjX29mX2Rldl9wbV9v cHMsDQo+ICANCj4gIHN0YXRpYyB2b2lkIGVzZGhjX2luaXQoc3RydWN0IHBsYXRmb3JtX2Rldmlj ZSAqcGRldiwgc3RydWN0IA0KPiBzZGhjaV9ob3N0ICpob3N0KSAgew0KPiArCWNvbnN0IHN0cnVj dCBzb2NfZGV2aWNlX2F0dHJpYnV0ZSAqbWF0Y2hlczsNCj4gIAlzdHJ1Y3Qgc2RoY2lfcGx0Zm1f aG9zdCAqcGx0Zm1faG9zdDsNCj4gIAlzdHJ1Y3Qgc2RoY2lfZXNkaGMgKmVzZGhjOw0KPiAgCXN0 cnVjdCBkZXZpY2Vfbm9kZSAqbnA7DQo+IEBAIC04MDIsNiArODY0LDkgQEAgc3RhdGljIHZvaWQg ZXNkaGNfaW5pdChzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2LCBzdHJ1Y3Qgc2RoY2lfaG9z dCAqaG9zdCkNCj4gIAllbHNlDQo+ICAJCWVzZGhjLT5xdWlya19pbmNvcnJlY3RfaG9zdHZlciA9 IGZhbHNlOw0KPiAgDQo+ICsJbWF0Y2hlcyA9IHNvY19kZXZpY2VfbWF0Y2goc29jX2VzZGhjX2Ns a19maXh1cCk7DQo+ICsJaWYgKG1hdGNoZXMpDQo+ICsJCWVzZGhjLT5jbGtfZml4dXAgPSBtYXRj aGVzLT5kYXRhOw0KPiAgCW5wID0gcGRldi0+ZGV2Lm9mX25vZGU7DQo+ICAJY2xrID0gb2ZfY2xr X2dldChucCwgMCk7DQo+ICAJaWYgKCFJU19FUlIoY2xrKSkgew0KPiANCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi yinbo.zhu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc7 next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yinbo-Zhu/mmc-sdhci-of-esdhc-modify-the-sd-clock-in-soc_device_match-way/20180524-164326
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/mmc/host/sdhci-of-esdhc.c: In function 'esdhc_of_set_clock':
>> drivers/mmc/host/sdhci-of-esdhc.c:567:36: error: 'FULL_SPEED_MAX_DTR' undeclared (first use in this function); did you mean 'HIGH_SPEED_MAX_DTR'?
clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup);
^~~~~~~~~~~~~~~~~~
HIGH_SPEED_MAX_DTR
drivers/mmc/host/sdhci-of-esdhc.c:567:36: note: each undeclared identifier is reported only once for each function it appears in
vim +567 drivers/mmc/host/sdhci-of-esdhc.c
542
543 static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock)
544 {
545 struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
546 struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
547 int pre_div = 1;
548 int div = 1;
549 ktime_t timeout;
550 long fixup;
551 u32 temp;
552
553 host->mmc->actual_clock = 0;
554
555 if (clock == 0) {
556 esdhc_clock_enable(host, false);
557 return;
558 }
559
560 /* Workaround to start pre_div at 2 for VNN < VENDOR_V_23 */
561 if (esdhc->vendor_ver < VENDOR_V_23)
562 pre_div = 2;
563
564 switch (host->mmc->ios.timing) {
565 case MMC_TIMING_LEGACY:
566 fixup = esdhc->clk_fixup->ds;
> 567 clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup);
568 fixup = esdhc->clk_fixup->mmc_ds;
569 clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup);
570 break;
571 case MMC_TIMING_SD_HS:
572 fixup = esdhc->clk_fixup->hs;
573 clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup);
574 break;
575 case MMC_TIMING_MMC_HS:
576 fixup = esdhc->clk_fixup->mmc_hs;
577 clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup);
578 break;
579 case MMC_TIMING_UHS_SDR104:
580 fixup = esdhc->clk_fixup->sdr104;
581 clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup);
582 break;
583 case MMC_TIMING_MMC_HS200:
584 fixup = esdhc->clk_fixup->hs200;
585 clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup);
586 break;
587 default:
588 break;
589 }
590
591 temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
592 temp &= ~(ESDHC_CLOCK_SDCLKEN | ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN |
593 ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
594 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
595
596 while (host->max_clk / pre_div / 16 > clock && pre_div < 256)
597 pre_div *= 2;
598
599 while (host->max_clk / pre_div / div > clock && div < 16)
600 div++;
601
602 dev_dbg(mmc_dev(host->mmc), "desired SD clock: %d, actual: %d\n",
603 clock, host->max_clk / pre_div / div);
604 host->mmc->actual_clock = host->max_clk / pre_div / div;
605 pre_div >>= 1;
606 div--;
607
608 temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
609 temp |= (ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN
610 | (div << ESDHC_DIVIDER_SHIFT)
611 | (pre_div << ESDHC_PREDIV_SHIFT));
612 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
613
614 /* Wait max 20 ms */
615 timeout = ktime_add_ms(ktime_get(), 20);
616 while (!(sdhci_readl(host, ESDHC_PRSSTAT) & ESDHC_CLOCK_STABLE)) {
617 if (ktime_after(ktime_get(), timeout)) {
618 pr_err("%s: Internal clock never stabilised.\n",
619 mmc_hostname(host->mmc));
620 return;
621 }
622 udelay(10);
623 }
624
625 temp |= ESDHC_CLOCK_SDCLKEN;
626 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
627 }
628
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi lkp, this patch compile error is due to it is not svnchronized in time that follow the another patch "mmc: sd: Define name for default speed dtr", I consider Adrian hunter's advice, that I will give a new version for this. Thanks Regards, Yinbo -----Original Message----- From: kbuild test robot [mailto:lkp@intel.com] Sent: 2018年5月30日 17:04 To: Yinbo Zhu <yinbo.zhu@nxp.com> Cc: kbuild-all@01.org; Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie <xiaobo.xie@nxp.com> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in soc_device_match way Hi yinbo.zhu, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc7 next-20180529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommits%2FYinbo-Zhu%2Fmmc-sdhci-of-esdhc-modify-the-sd-clock-in-soc_device_match-way%2F20180524-164326&data=02%7C01%7Cyinbo.zhu%40nxp.com%7C10f70ccc11e447b63f1208d5c60c6a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636632682102290618&sdata=rfubgM%2FTqTFqkyVxJCK%2FLhVR%2BB5bmZGTRDCd1LgwE8w%3D&reserved=0 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.cross&data=02%7C01%7Cyinbo.zhu%40nxp.com%7C10f70ccc11e447b63f1208d5c60c6a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636632682102290618&sdata=MrUHMMy5HWaanczMNS%2BhW1KCezhejmWKbW3XOXodP2o%3D&reserved=0 -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/mmc/host/sdhci-of-esdhc.c: In function 'esdhc_of_set_clock': >> drivers/mmc/host/sdhci-of-esdhc.c:567:36: error: 'FULL_SPEED_MAX_DTR' undeclared (first use in this function); did you mean 'HIGH_SPEED_MAX_DTR'? clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); ^~~~~~~~~~~~~~~~~~ HIGH_SPEED_MAX_DTR drivers/mmc/host/sdhci-of-esdhc.c:567:36: note: each undeclared identifier is reported only once for each function it appears in vim +567 drivers/mmc/host/sdhci-of-esdhc.c 542 543 static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) 544 { 545 struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); 546 struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host); 547 int pre_div = 1; 548 int div = 1; 549 ktime_t timeout; 550 long fixup; 551 u32 temp; 552 553 host->mmc->actual_clock = 0; 554 555 if (clock == 0) { 556 esdhc_clock_enable(host, false); 557 return; 558 } 559 560 /* Workaround to start pre_div at 2 for VNN < VENDOR_V_23 */ 561 if (esdhc->vendor_ver < VENDOR_V_23) 562 pre_div = 2; 563 564 switch (host->mmc->ios.timing) { 565 case MMC_TIMING_LEGACY: 566 fixup = esdhc->clk_fixup->ds; > 567 clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); 568 fixup = esdhc->clk_fixup->mmc_ds; 569 clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); 570 break; 571 case MMC_TIMING_SD_HS: 572 fixup = esdhc->clk_fixup->hs; 573 clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); 574 break; 575 case MMC_TIMING_MMC_HS: 576 fixup = esdhc->clk_fixup->mmc_hs; 577 clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); 578 break; 579 case MMC_TIMING_UHS_SDR104: 580 fixup = esdhc->clk_fixup->sdr104; 581 clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); 582 break; 583 case MMC_TIMING_MMC_HS200: 584 fixup = esdhc->clk_fixup->hs200; 585 clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); 586 break; 587 default: 588 break; 589 } 590 591 temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); 592 temp &= ~(ESDHC_CLOCK_SDCLKEN | ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | 593 ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK); 594 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL); 595 596 while (host->max_clk / pre_div / 16 > clock && pre_div < 256) 597 pre_div *= 2; 598 599 while (host->max_clk / pre_div / div > clock && div < 16) 600 div++; 601 602 dev_dbg(mmc_dev(host->mmc), "desired SD clock: %d, actual: %d\n", 603 clock, host->max_clk / pre_div / div); 604 host->mmc->actual_clock = host->max_clk / pre_div / div; 605 pre_div >>= 1; 606 div--; 607 608 temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); 609 temp |= (ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN 610 | (div << ESDHC_DIVIDER_SHIFT) 611 | (pre_div << ESDHC_PREDIV_SHIFT)); 612 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL); 613 614 /* Wait max 20 ms */ 615 timeout = ktime_add_ms(ktime_get(), 20); 616 while (!(sdhci_readl(host, ESDHC_PRSSTAT) & ESDHC_CLOCK_STABLE)) { 617 if (ktime_after(ktime_get(), timeout)) { 618 pr_err("%s: Internal clock never stabilised.\n", 619 mmc_hostname(host->mmc)); 620 return; 621 } 622 udelay(10); 623 } 624 625 temp |= ESDHC_CLOCK_SDCLKEN; 626 sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL); 627 } 628 --- 0-DAY kernel test infrastructure Open Source Technology Center https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fpipermail%2Fkbuild-all&data=02%7C01%7Cyinbo.zhu%40nxp.com%7C10f70ccc11e447b63f1208d5c60c6a60%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636632682102290618&sdata=FBlJ3bdWhYaBSqGq1nn%2BoPTEVXk1MTZfgI3gbk2l05Q%3D&reserved=0 Intel Corporation
> -----Original Message----- > From: Yinbo Zhu > Sent: Monday, May 28, 2018 5:58 PM > To: Adrian Hunter <adrian.hunter@intel.com>; Y.b. Lu <yangbo.lu@nxp.com>; > linux-mmc@vger.kernel.org > Cc: Xiaobo Xie <xiaobo.xie@nxp.com> > Subject: RE: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > soc_device_match way > > > > -----Original Message----- > From: Adrian Hunter [mailto:adrian.hunter@intel.com] > Sent: 2018年5月24日 16:58 > To: Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; > linux-mmc@vger.kernel.org > Cc: Xiaobo Xie <xiaobo.xie@nxp.com> > Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > soc_device_match way > > On 22/05/18 15:06, Yinbo Zhu wrote: [...] > > + switch (host->mmc->ios.timing) { > > + case MMC_TIMING_LEGACY: > > + fixup = esdhc->clk_fixup->ds; > > + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); > > + fixup = esdhc->clk_fixup->mmc_ds; > > + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); > > + break; > > + case MMC_TIMING_SD_HS: > > + fixup = esdhc->clk_fixup->hs; > > + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); > > + break; > > + case MMC_TIMING_MMC_HS: > > + fixup = esdhc->clk_fixup->mmc_hs; > > + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); > > + break; > > + case MMC_TIMING_UHS_SDR104: > > + fixup = esdhc->clk_fixup->sdr104; > > + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); > > + break; > > + case MMC_TIMING_MMC_HS200: > > + fixup = esdhc->clk_fixup->hs200; > > + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); > > + break; > > + default: > > + break; > > >This logic looks fragile. I would expect to see something that looks more > like: > > > max_clk = esdhc->clk_fixup[host->mmc->ios.timing]; > > if (max_clk && clock > max_clk) > > clock = max_CLK; > Hi Adrian Hunter, > > Thanks your advice, your way will make code logic more clearly, but MMC > default max clock is 26MHz, SD default max clock is 25MHz, they all use the > same ios.timing in public code, If use array, There will be a conflict, Do you > have any good ways to resolve the conflict. > Thanks. > > Regards, > Yinbo > [Y.b. Lu] The MMC core driver used the timing MMC_TIMING_LEGACY for both MMC and SD/SDIO at card initialization. However, the timing was different between MMC and SD/SDIO at initialization. MMC was at legacy speed mode (up to 26MHz) while SD/SDIO was at default speed mode (up to 25MHz). Actually I think we should define MMC_TIMING_MMC_LEGACY and MMC_TIMING_SD_DEFAULT for MMC and SD/SDIO initializing timing. And use the right timing at the beginning in mmc_attach_sd/sdio/mmc(). Any suggestion? Adrian and Uffe :) #define MMC_TIMING_LEGACY 0 #define MMC_TIMING_MMC_LEGACY 1 #define MMC_TIMING_SD_DEFAULT 2 #define MMC_TIMING_MMC_HS 3 #define MMC_TIMING_SD_HS 4 #define MMC_TIMING_UHS_SDR12 5 #define MMC_TIMING_UHS_SDR25 6 #define MMC_TIMING_UHS_SDR50 7 #define MMC_TIMING_UHS_SDR104 8 #define MMC_TIMING_UHS_DDR50 9 #define MMC_TIMING_MMC_DDR52 10 #define MMC_TIMING_MMC_HS200 11 #define MMC_TIMING_MMC_HS400 12
On 1 June 2018 at 08:31, Y.b. Lu <yangbo.lu@nxp.com> wrote: >> -----Original Message----- >> From: Yinbo Zhu >> Sent: Monday, May 28, 2018 5:58 PM >> To: Adrian Hunter <adrian.hunter@intel.com>; Y.b. Lu <yangbo.lu@nxp.com>; >> linux-mmc@vger.kernel.org >> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> >> Subject: RE: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >> soc_device_match way >> >> >> >> -----Original Message----- >> From: Adrian Hunter [mailto:adrian.hunter@intel.com] >> Sent: 2018年5月24日 16:58 >> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; >> linux-mmc@vger.kernel.org >> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >> soc_device_match way >> >> On 22/05/18 15:06, Yinbo Zhu wrote: > [...] >> > + switch (host->mmc->ios.timing) { >> > + case MMC_TIMING_LEGACY: >> > + fixup = esdhc->clk_fixup->ds; >> > + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); >> > + fixup = esdhc->clk_fixup->mmc_ds; >> > + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); >> > + break; >> > + case MMC_TIMING_SD_HS: >> > + fixup = esdhc->clk_fixup->hs; >> > + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); >> > + break; >> > + case MMC_TIMING_MMC_HS: >> > + fixup = esdhc->clk_fixup->mmc_hs; >> > + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); >> > + break; >> > + case MMC_TIMING_UHS_SDR104: >> > + fixup = esdhc->clk_fixup->sdr104; >> > + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); >> > + break; >> > + case MMC_TIMING_MMC_HS200: >> > + fixup = esdhc->clk_fixup->hs200; >> > + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); >> > + break; >> > + default: >> > + break; >> >> >This logic looks fragile. I would expect to see something that looks more >> like: >> >> > max_clk = esdhc->clk_fixup[host->mmc->ios.timing]; >> > if (max_clk && clock > max_clk) >> > clock = max_CLK; >> Hi Adrian Hunter, >> >> Thanks your advice, your way will make code logic more clearly, but MMC >> default max clock is 26MHz, SD default max clock is 25MHz, they all use the >> same ios.timing in public code, If use array, There will be a conflict, Do you >> have any good ways to resolve the conflict. >> Thanks. >> >> Regards, >> Yinbo >> > > [Y.b. Lu] The MMC core driver used the timing MMC_TIMING_LEGACY for both MMC and SD/SDIO at card initialization. > However, the timing was different between MMC and SD/SDIO at initialization. MMC was at legacy speed mode (up to 26MHz) while SD/SDIO was at default speed mode (up to 25MHz). > Actually I think we should define MMC_TIMING_MMC_LEGACY and MMC_TIMING_SD_DEFAULT for MMC and SD/SDIO initializing timing. > And use the right timing at the beginning in mmc_attach_sd/sdio/mmc(). > Any suggestion? Adrian and Uffe :) I am fine with that. However, you need to make sure all host drivers can cope with changing this. Perhaps, it's also sufficient to introduce MMC_TIMING_DEFAULT (used for SD) and keep MMC_TIMING_LEGACY (for MMC). > > #define MMC_TIMING_LEGACY 0 > #define MMC_TIMING_MMC_LEGACY 1 > #define MMC_TIMING_SD_DEFAULT 2 > #define MMC_TIMING_MMC_HS 3 > #define MMC_TIMING_SD_HS 4 > #define MMC_TIMING_UHS_SDR12 5 > #define MMC_TIMING_UHS_SDR25 6 > #define MMC_TIMING_UHS_SDR50 7 > #define MMC_TIMING_UHS_SDR104 8 > #define MMC_TIMING_UHS_DDR50 9 > #define MMC_TIMING_MMC_DDR52 10 > #define MMC_TIMING_MMC_HS200 11 > #define MMC_TIMING_MMC_HS400 12 > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: Friday, June 1, 2018 2:38 PM > To: Y.b. Lu <yangbo.lu@nxp.com> > Cc: Yinbo Zhu <yinbo.zhu@nxp.com>; Adrian Hunter > <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie > <xiaobo.xie@nxp.com> > Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > soc_device_match way > > On 1 June 2018 at 08:31, Y.b. Lu <yangbo.lu@nxp.com> wrote: > >> -----Original Message----- > >> From: Yinbo Zhu > >> Sent: Monday, May 28, 2018 5:58 PM > >> To: Adrian Hunter <adrian.hunter@intel.com>; Y.b. Lu > >> <yangbo.lu@nxp.com>; linux-mmc@vger.kernel.org > >> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> > >> Subject: RE: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > >> soc_device_match way > >> > >> > >> > >> -----Original Message----- > >> From: Adrian Hunter [mailto:adrian.hunter@intel.com] > >> Sent: 2018年5月24日 16:58 > >> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; > >> linux-mmc@vger.kernel.org > >> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> > >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > >> soc_device_match way > >> > >> On 22/05/18 15:06, Yinbo Zhu wrote: > > [...] > >> > + switch (host->mmc->ios.timing) { > >> > + case MMC_TIMING_LEGACY: > >> > + fixup = esdhc->clk_fixup->ds; > >> > + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, > fixup); > >> > + fixup = esdhc->clk_fixup->mmc_ds; > >> > + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, > fixup); > >> > + break; > >> > + case MMC_TIMING_SD_HS: > >> > + fixup = esdhc->clk_fixup->hs; > >> > + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, > fixup); > >> > + break; > >> > + case MMC_TIMING_MMC_HS: > >> > + fixup = esdhc->clk_fixup->mmc_hs; > >> > + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, > fixup); > >> > + break; > >> > + case MMC_TIMING_UHS_SDR104: > >> > + fixup = esdhc->clk_fixup->sdr104; > >> > + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, > fixup); > >> > + break; > >> > + case MMC_TIMING_MMC_HS200: > >> > + fixup = esdhc->clk_fixup->hs200; > >> > + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, > fixup); > >> > + break; > >> > + default: > >> > + break; > >> > >> >This logic looks fragile. I would expect to see something that > >> >looks more > >> like: > >> > >> > max_clk = esdhc->clk_fixup[host->mmc->ios.timing]; > >> > if (max_clk && clock > max_clk) > >> > clock = max_CLK; > >> Hi Adrian Hunter, > >> > >> Thanks your advice, your way will make code logic more clearly, but > >> MMC default max clock is 26MHz, SD default max clock is 25MHz, they > >> all use the same ios.timing in public code, If use array, There will > >> be a conflict, Do you have any good ways to resolve the conflict. > >> Thanks. > >> > >> Regards, > >> Yinbo > >> > > > > [Y.b. Lu] The MMC core driver used the timing MMC_TIMING_LEGACY for > both MMC and SD/SDIO at card initialization. > > However, the timing was different between MMC and SD/SDIO at > initialization. MMC was at legacy speed mode (up to 26MHz) while SD/SDIO > was at default speed mode (up to 25MHz). > > Actually I think we should define MMC_TIMING_MMC_LEGACY and > MMC_TIMING_SD_DEFAULT for MMC and SD/SDIO initializing timing. > > And use the right timing at the beginning in mmc_attach_sd/sdio/mmc(). > > Any suggestion? Adrian and Uffe :) > > I am fine with that. However, you need to make sure all host drivers can cope > with changing this. > > Perhaps, it's also sufficient to introduce MMC_TIMING_DEFAULT (used for SD) > and keep MMC_TIMING_LEGACY (for MMC). [Y.b. Lu] Great. It's safe to just introduce MMC_TIMING_DEFAULT. Thanks. > > > > > #define MMC_TIMING_LEGACY 0 > > #define MMC_TIMING_MMC_LEGACY 1 > > #define MMC_TIMING_SD_DEFAULT 2 > > #define MMC_TIMING_MMC_HS 3 > > #define MMC_TIMING_SD_HS 4 > > #define MMC_TIMING_UHS_SDR12 5 > > #define MMC_TIMING_UHS_SDR25 6 > > #define MMC_TIMING_UHS_SDR50 7 > > #define MMC_TIMING_UHS_SDR104 8 > > #define MMC_TIMING_UHS_DDR50 9 > > #define MMC_TIMING_MMC_DDR52 10 > > #define MMC_TIMING_MMC_HS200 11 > > #define MMC_TIMING_MMC_HS400 12 > > > > Kind regards > Uffe
[...] >> > [Y.b. Lu] The MMC core driver used the timing MMC_TIMING_LEGACY for >> both MMC and SD/SDIO at card initialization. >> > However, the timing was different between MMC and SD/SDIO at >> initialization. MMC was at legacy speed mode (up to 26MHz) while SD/SDIO >> was at default speed mode (up to 25MHz). >> > Actually I think we should define MMC_TIMING_MMC_LEGACY and >> MMC_TIMING_SD_DEFAULT for MMC and SD/SDIO initializing timing. >> > And use the right timing at the beginning in mmc_attach_sd/sdio/mmc(). >> > Any suggestion? Adrian and Uffe :) >> >> I am fine with that. However, you need to make sure all host drivers can cope >> with changing this. >> >> Perhaps, it's also sufficient to introduce MMC_TIMING_DEFAULT (used for SD) >> and keep MMC_TIMING_LEGACY (for MMC). > > [Y.b. Lu] Great. It's safe to just introduce MMC_TIMING_DEFAULT. Thanks. Not sure what you mean by safe. I assume you know that changing this, requires changes all of the place. The mmc core, mmc host drivers and even an sdio func driver that is abusing the mmc host interface... I guess patches will show what you have in mind. :-) Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/06/18 09:53, Y.b. Lu wrote: >> -----Original Message----- >> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] >> Sent: Friday, June 1, 2018 2:38 PM >> To: Y.b. Lu <yangbo.lu@nxp.com> >> Cc: Yinbo Zhu <yinbo.zhu@nxp.com>; Adrian Hunter >> <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie >> <xiaobo.xie@nxp.com> >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >> soc_device_match way >> >> On 1 June 2018 at 08:31, Y.b. Lu <yangbo.lu@nxp.com> wrote: >>>> -----Original Message----- >>>> From: Yinbo Zhu >>>> Sent: Monday, May 28, 2018 5:58 PM >>>> To: Adrian Hunter <adrian.hunter@intel.com>; Y.b. Lu >>>> <yangbo.lu@nxp.com>; linux-mmc@vger.kernel.org >>>> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> >>>> Subject: RE: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >>>> soc_device_match way >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Adrian Hunter [mailto:adrian.hunter@intel.com] >>>> Sent: 2018年5月24日 16:58 >>>> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; >>>> linux-mmc@vger.kernel.org >>>> Cc: Xiaobo Xie <xiaobo.xie@nxp.com> >>>> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >>>> soc_device_match way >>>> >>>> On 22/05/18 15:06, Yinbo Zhu wrote: >>> [...] >>>>> + switch (host->mmc->ios.timing) { >>>>> + case MMC_TIMING_LEGACY: >>>>> + fixup = esdhc->clk_fixup->ds; >>>>> + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, >> fixup); >>>>> + fixup = esdhc->clk_fixup->mmc_ds; >>>>> + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, >> fixup); >>>>> + break; >>>>> + case MMC_TIMING_SD_HS: >>>>> + fixup = esdhc->clk_fixup->hs; >>>>> + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, >> fixup); >>>>> + break; >>>>> + case MMC_TIMING_MMC_HS: >>>>> + fixup = esdhc->clk_fixup->mmc_hs; >>>>> + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, >> fixup); >>>>> + break; >>>>> + case MMC_TIMING_UHS_SDR104: >>>>> + fixup = esdhc->clk_fixup->sdr104; >>>>> + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, >> fixup); >>>>> + break; >>>>> + case MMC_TIMING_MMC_HS200: >>>>> + fixup = esdhc->clk_fixup->hs200; >>>>> + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, >> fixup); >>>>> + break; >>>>> + default: >>>>> + break; >>>> >>>>> This logic looks fragile. I would expect to see something that >>>>> looks more >>>> like: >>>> >>>>> max_clk = esdhc->clk_fixup[host->mmc->ios.timing]; >>>>> if (max_clk && clock > max_clk) >>>>> clock = max_CLK; >>>> Hi Adrian Hunter, >>>> >>>> Thanks your advice, your way will make code logic more clearly, but >>>> MMC default max clock is 26MHz, SD default max clock is 25MHz, they >>>> all use the same ios.timing in public code, If use array, There will >>>> be a conflict, Do you have any good ways to resolve the conflict. >>>> Thanks. >>>> >>>> Regards, >>>> Yinbo >>>> >>> >>> [Y.b. Lu] The MMC core driver used the timing MMC_TIMING_LEGACY for >> both MMC and SD/SDIO at card initialization. >>> However, the timing was different between MMC and SD/SDIO at >> initialization. MMC was at legacy speed mode (up to 26MHz) while SD/SDIO >> was at default speed mode (up to 25MHz). >>> Actually I think we should define MMC_TIMING_MMC_LEGACY and >> MMC_TIMING_SD_DEFAULT for MMC and SD/SDIO initializing timing. >>> And use the right timing at the beginning in mmc_attach_sd/sdio/mmc(). >>> Any suggestion? Adrian and Uffe :) >> >> I am fine with that. However, you need to make sure all host drivers can cope >> with changing this. >> >> Perhaps, it's also sufficient to introduce MMC_TIMING_DEFAULT (used for SD) >> and keep MMC_TIMING_LEGACY (for MMC). > > [Y.b. Lu] Great. It's safe to just introduce MMC_TIMING_DEFAULT. Thanks. Several drivers check MMC_TIMING_LEGACY and we don't know if it is MMC or SD when initializing. I suggest just making a special case in your logic: if (host->card && mmc_card_sd(host->card) && host->mmc->ios.timing == MMC_TIMING_LEGACY) max_clk = esdhc->clk_fixup.sd_dflt_max_clk; else max_clk = esdhc->clk_fixup.max_clk[host->mmc->ios.timing]; > > >> >>> >>> #define MMC_TIMING_LEGACY 0 >>> #define MMC_TIMING_MMC_LEGACY 1 >>> #define MMC_TIMING_SD_DEFAULT 2 >>> #define MMC_TIMING_MMC_HS 3 >>> #define MMC_TIMING_SD_HS 4 >>> #define MMC_TIMING_UHS_SDR12 5 >>> #define MMC_TIMING_UHS_SDR25 6 >>> #define MMC_TIMING_UHS_SDR50 7 >>> #define MMC_TIMING_UHS_SDR104 8 >>> #define MMC_TIMING_UHS_DDR50 9 >>> #define MMC_TIMING_MMC_DDR52 10 >>> #define MMC_TIMING_MMC_HS200 11 >>> #define MMC_TIMING_MMC_HS400 12 >>> >> >> Kind regards >> Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 23, 2018 at 4:21 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 23 May 2018 at 10:55, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >> >> -----Original Message----- >> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] >> Sent: 2018年5月23日 14:41 >> To: Yinbo Zhu <yinbo.zhu@nxp.com> >> Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie <xiaobo.xie@nxp.com> >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in soc_device_match way >> >> On 23 May 2018 at 05:50, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >>> >>> >>> -----Original Message----- >>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] >>> Sent: 2018年5月22日 20:16 >>> To: Yinbo Zhu <yinbo.zhu@nxp.com> >>> Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter >>> <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie >>> <xiaobo.xie@nxp.com> >>> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in >>> soc_device_match way >>> >>> On 22 May 2018 at 14:06, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: >>>> From: yinbo.zhu <yinbo.zhu@nxp.com> >>>> >>>> Convert to use soc_device_match method to fix up eSDHC clock for >>>> ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a >>>> according to its datasheet. The maxmum speed for ls1021a eSDHC high >>>> speed mode is 46.5MHz. >>> >>>>Why not use mmc DT property "max-frequency" instead? >>> >>>>Why exactly do you need a different max frequency depending on the selected speed mode? >>> >>>>Kind regards >>>>Uffe >>> Accroding to datasheet that the different max frequency depending on >>> the slected speed mode and SoC, >> >>>That it depends on the SoC, that I am or course fine with. >> >>>My point is rather that I think it depends on the actual slot connector (or board), rather that on the speed mode. >>>For example, one port may have an eMMC and for some reason it can be run in a speed mode using full clock rate. Another >>>one may be an SD-card slot, and perhaps because of some external logic, the signal quality doesn't survive a too high clock- >>>rate. Etc. >> >>>Other SoCs and platforms works like this, I am sure yours do as well. No? >> >>> In the current state that which only shows one of the max-frequency, >>> so it can't use mmc DT property "max-frequency" instead >> >>>According to my comments above, could you please investigate once more, whether really "max-frequency" can be used as >>>the DT binding? >> >>>If it can't then I think we should consider introducing new mmc DT bindings instead. >> >>>[...] >> >>>Kind regards >>>Uffe >> Hi Uffe, >> >> Attachment is some pictures which in data sheet, I think it can explain that max frequency depending on the slected speed mode and SoC, You can have a look. >> > > Thanks, yes, this seems to confirm it. Kind of weird that none until > now have raised issues about similar constraints to be needed. > > So, we can either use your suggested solution, via soc_device_match() > method, if you prefer, else we need to invent a new DT property for > each speed mode constraint. Yinbo, According to the comment of the soc_device_match() API, it is for cases when device tree doesn't provide enough information to identify the variant. But I don't think it is the case for the SoCs you added in this patch, they all have unique compatible strings in the dts files. Why don't we use of_match_node() instead? Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGkgTGVvLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExpIFlhbmcg W21haWx0bzpsZW95YW5nLmxpQG54cC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDcsIDIw MTggNDowNCBBTQ0KPiBUbzogVWxmIEhhbnNzb24gPHVsZi5oYW5zc29uQGxpbmFyby5vcmc+DQo+ IENjOiBZaW5ibyBaaHUgPHlpbmJvLnpodUBueHAuY29tPjsgWS5iLiBMdSA8eWFuZ2JvLmx1QG54 cC5jb20+OyBBZHJpYW4NCj4gSHVudGVyIDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT47IGxpbnV4 LW1tY0B2Z2VyLmtlcm5lbC5vcmc7IFhpYW9ibyBYaWUNCj4gPHhpYW9iby54aWVAbnhwLmNvbT4N Cj4gU3ViamVjdDogUmU6IFtQQVRDSCB2Ml0gbW1jOiBzZGhjaS1vZi1lc2RoYzogbW9kaWZ5IHRo ZSBzZCBjbG9jayBpbg0KPiBzb2NfZGV2aWNlX21hdGNoIHdheQ0KPiANCj4gT24gV2VkLCBNYXkg MjMsIDIwMTggYXQgNDoyMSBBTSwgVWxmIEhhbnNzb24gPHVsZi5oYW5zc29uQGxpbmFyby5vcmc+ DQo+IHdyb3RlOg0KPiA+IE9uIDIzIE1heSAyMDE4IGF0IDEwOjU1LCBZaW5ibyBaaHUgPHlpbmJv LnpodUBueHAuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogVWxmIEhhbnNzb24gW21haWx0bzp1bGYuaGFuc3NvbkBsaW5hcm8ub3Jn XQ0KPiA+PiBTZW50OiAyMDE45bm0NeaciDIz5pelIDE0OjQxDQo+ID4+IFRvOiBZaW5ibyBaaHUg PHlpbmJvLnpodUBueHAuY29tPg0KPiA+PiBDYzogWS5iLiBMdSA8eWFuZ2JvLmx1QG54cC5jb20+ OyBBZHJpYW4gSHVudGVyDQo+ID4+IDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT47IGxpbnV4LW1t Y0B2Z2VyLmtlcm5lbC5vcmc7IFhpYW9ibyBYaWUNCj4gPj4gPHhpYW9iby54aWVAbnhwLmNvbT4N Cj4gPj4gU3ViamVjdDogUmU6IFtQQVRDSCB2Ml0gbW1jOiBzZGhjaS1vZi1lc2RoYzogbW9kaWZ5 IHRoZSBzZCBjbG9jayBpbg0KPiA+PiBzb2NfZGV2aWNlX21hdGNoIHdheQ0KPiA+Pg0KPiA+PiBP biAyMyBNYXkgMjAxOCBhdCAwNTo1MCwgWWluYm8gWmh1IDx5aW5iby56aHVAbnhwLmNvbT4gd3Jv dGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ PiBGcm9tOiBVbGYgSGFuc3NvbiBbbWFpbHRvOnVsZi5oYW5zc29uQGxpbmFyby5vcmddDQo+ID4+ PiBTZW50OiAyMDE45bm0NeaciDIy5pelIDIwOjE2DQo+ID4+PiBUbzogWWluYm8gWmh1IDx5aW5i by56aHVAbnhwLmNvbT4NCj4gPj4+IENjOiBZLmIuIEx1IDx5YW5nYm8ubHVAbnhwLmNvbT47IEFk cmlhbiBIdW50ZXINCj4gPj4+IDxhZHJpYW4uaHVudGVyQGludGVsLmNvbT47IGxpbnV4LW1tY0B2 Z2VyLmtlcm5lbC5vcmc7IFhpYW9ibyBYaWUNCj4gPj4+IDx4aWFvYm8ueGllQG54cC5jb20+DQo+ ID4+PiBTdWJqZWN0OiBSZTogW1BBVENIIHYyXSBtbWM6IHNkaGNpLW9mLWVzZGhjOiBtb2RpZnkg dGhlIHNkIGNsb2NrIGluDQo+ID4+PiBzb2NfZGV2aWNlX21hdGNoIHdheQ0KPiA+Pj4NCj4gPj4+ IE9uIDIyIE1heSAyMDE4IGF0IDE0OjA2LCBZaW5ibyBaaHUgPHlpbmJvLnpodUBueHAuY29tPiB3 cm90ZToNCj4gPj4+PiBGcm9tOiB5aW5iby56aHUgPHlpbmJvLnpodUBueHAuY29tPg0KPiA+Pj4+ DQo+ID4+Pj4gQ29udmVydCB0byB1c2Ugc29jX2RldmljZV9tYXRjaCBtZXRob2QgdG8gZml4IHVw IGVTREhDIGNsb2NrIGZvcg0KPiA+Pj4+IGxzMTA0NmEvbHMxMDEyYS9wMTAxMC4gQWxzbyBhZGQg ZVNESEMgY2xvY2sgZml4dXAgZm9yIGxzMTAyMWENCj4gPj4+PiBhY2NvcmRpbmcgdG8gaXRzIGRh dGFzaGVldC4gVGhlIG1heG11bSBzcGVlZCBmb3IgbHMxMDIxYSBlU0RIQyBoaWdoDQo+ID4+Pj4g c3BlZWQgbW9kZSBpcyA0Ni41TUh6Lg0KPiA+Pj4NCj4gPj4+PldoeSBub3QgdXNlIG1tYyBEVCBw cm9wZXJ0eSAibWF4LWZyZXF1ZW5jeSIgaW5zdGVhZD8NCj4gPj4+DQo+ID4+Pj5XaHkgZXhhY3Rs eSBkbyB5b3UgbmVlZCBhIGRpZmZlcmVudCBtYXggZnJlcXVlbmN5IGRlcGVuZGluZyBvbiB0aGUN Cj4gc2VsZWN0ZWQgc3BlZWQgbW9kZT8NCj4gPj4+DQo+ID4+Pj5LaW5kIHJlZ2FyZHMNCj4gPj4+ PlVmZmUNCj4gPj4+IEFjY3JvZGluZyB0byBkYXRhc2hlZXQgdGhhdCB0aGUgZGlmZmVyZW50IG1h eCBmcmVxdWVuY3kgZGVwZW5kaW5nIG9uDQo+ID4+PiB0aGUgc2xlY3RlZCBzcGVlZCBtb2RlIGFu ZCBTb0MsDQo+ID4+DQo+ID4+PlRoYXQgaXQgZGVwZW5kcyBvbiB0aGUgU29DLCB0aGF0IEkgYW0g b3IgY291cnNlIGZpbmUgd2l0aC4NCj4gPj4NCj4gPj4+TXkgcG9pbnQgaXMgcmF0aGVyIHRoYXQg SSB0aGluayBpdCBkZXBlbmRzIG9uIHRoZSBhY3R1YWwgc2xvdCBjb25uZWN0b3IgKG9yDQo+IGJv YXJkKSwgcmF0aGVyIHRoYXQgb24gdGhlIHNwZWVkIG1vZGUuDQo+ID4+PkZvciBleGFtcGxlLCBv bmUgcG9ydCBtYXkgaGF2ZSBhbiBlTU1DIGFuZCBmb3Igc29tZSByZWFzb24gaXQgY2FuIGJlDQo+ ID4+PnJ1biBpbiBhIHNwZWVkIG1vZGUgdXNpbmcgZnVsbCBjbG9jayByYXRlLiBBbm90aGVyIG9u ZSBtYXkgYmUgYW4NCj4gPj4+U0QtY2FyZCBzbG90LCBhbmQgcGVyaGFwcyBiZWNhdXNlIG9mIHNv bWUgZXh0ZXJuYWwgbG9naWMsIHRoZSBzaWduYWwgcXVhbGl0eQ0KPiBkb2Vzbid0IHN1cnZpdmUg YSB0b28gaGlnaCBjbG9jay0gcmF0ZS4gRXRjLg0KPiA+Pg0KPiA+Pj5PdGhlciBTb0NzIGFuZCBw bGF0Zm9ybXMgd29ya3MgbGlrZSB0aGlzLCBJIGFtIHN1cmUgeW91cnMgZG8gYXMgd2VsbC4gTm8/ DQo+ID4+DQo+ID4+PiBJbiB0aGUgY3VycmVudCBzdGF0ZSB0aGF0IHdoaWNoIG9ubHkgc2hvd3Mg b25lIG9mIHRoZSBtYXgtZnJlcXVlbmN5LA0KPiA+Pj4gc28gaXQgY2FuJ3QgdXNlIG1tYyBEVCBw cm9wZXJ0eSAibWF4LWZyZXF1ZW5jeSIgaW5zdGVhZA0KPiA+Pg0KPiA+Pj5BY2NvcmRpbmcgdG8g bXkgY29tbWVudHMgYWJvdmUsIGNvdWxkIHlvdSBwbGVhc2UgaW52ZXN0aWdhdGUgb25jZQ0KPiA+ Pj5tb3JlLCB3aGV0aGVyIHJlYWxseSAibWF4LWZyZXF1ZW5jeSIgY2FuIGJlIHVzZWQgYXMgdGhl IERUIGJpbmRpbmc/DQo+ID4+DQo+ID4+PklmIGl0IGNhbid0IHRoZW4gSSB0aGluayB3ZSBzaG91 bGQgY29uc2lkZXIgaW50cm9kdWNpbmcgbmV3IG1tYyBEVA0KPiBiaW5kaW5ncyBpbnN0ZWFkLg0K PiA+Pg0KPiA+Pj5bLi4uXQ0KPiA+Pg0KPiA+Pj5LaW5kIHJlZ2FyZHMNCj4gPj4+VWZmZQ0KPiA+ PiBIaSBVZmZlLA0KPiA+Pg0KPiA+PiBBdHRhY2htZW50IGlzIHNvbWUgcGljdHVyZXMgd2hpY2gg aW4gZGF0YSBzaGVldCwgSSB0aGluayBpdCBjYW4gZXhwbGFpbiB0aGF0DQo+IG1heCBmcmVxdWVu Y3kgZGVwZW5kaW5nIG9uIHRoZSBzbGVjdGVkIHNwZWVkIG1vZGUgYW5kIFNvQywgWW91IGNhbiBo YXZlIGENCj4gbG9vay4NCj4gPj4NCj4gPg0KPiA+IFRoYW5rcywgeWVzLCB0aGlzIHNlZW1zIHRv IGNvbmZpcm0gaXQuIEtpbmQgb2Ygd2VpcmQgdGhhdCBub25lIHVudGlsDQo+ID4gbm93IGhhdmUg cmFpc2VkIGlzc3VlcyBhYm91dCBzaW1pbGFyIGNvbnN0cmFpbnRzIHRvIGJlIG5lZWRlZC4NCj4g Pg0KPiA+IFNvLCB3ZSBjYW4gZWl0aGVyIHVzZSB5b3VyIHN1Z2dlc3RlZCBzb2x1dGlvbiwgdmlh IHNvY19kZXZpY2VfbWF0Y2goKQ0KPiA+IG1ldGhvZCwgaWYgeW91IHByZWZlciwgZWxzZSB3ZSBu ZWVkIHRvIGludmVudCBhIG5ldyBEVCBwcm9wZXJ0eSBmb3INCj4gPiBlYWNoIHNwZWVkIG1vZGUg Y29uc3RyYWludC4NCj4gDQo+IFlpbmJvLA0KPiANCj4gQWNjb3JkaW5nIHRvIHRoZSBjb21tZW50 IG9mIHRoZSBzb2NfZGV2aWNlX21hdGNoKCkgQVBJLCBpdCBpcyBmb3IgY2FzZXMgd2hlbg0KPiBk ZXZpY2UgdHJlZSBkb2Vzbid0IHByb3ZpZGUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGlkZW50aWZ5 IHRoZSB2YXJpYW50LiAgQnV0IEkNCj4gZG9uJ3QgdGhpbmsgaXQgaXMgdGhlIGNhc2UgZm9yIHRo ZSBTb0NzIHlvdSBhZGRlZCBpbiB0aGlzIHBhdGNoLCB0aGV5IGFsbCBoYXZlDQo+IHVuaXF1ZSBj b21wYXRpYmxlIHN0cmluZ3MgaW4gdGhlIGR0cyBmaWxlcy4gIFdoeSBkb24ndCB3ZSB1c2Ugb2Zf bWF0Y2hfbm9kZSgpDQo+IGluc3RlYWQ/DQo+IA0KDQpbWS5iLiBMdV0gQnkgbm93IHRoZSBvZl9t YXRjaF9ub2RlKCkgY291bGQgaGFuZGxlIHRoaXMgY2FzZS4gV2hhdCBpZiB0aGlzIGtpbmQgZXJy YXR1bSBoYXBwZW5zIG9uIHNwZWNpZmljIHNvYyByZXZpc2lvbiBpbiB0aGUgZnV0dXJlPw0KDQo+ IFJlZ2FyZHMsDQo+IExlbw0K -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 11, 2018 at 1:26 AM, Y.b. Lu <yangbo.lu@nxp.com> wrote: > > Hi Leo, > > > -----Original Message----- > > From: Li Yang [mailto:leoyang.li@nxp.com] > > Sent: Thursday, June 7, 2018 4:04 AM > > To: Ulf Hansson <ulf.hansson@linaro.org> > > Cc: Yinbo Zhu <yinbo.zhu@nxp.com>; Y.b. Lu <yangbo.lu@nxp.com>; Adrian > > Hunter <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie > > <xiaobo.xie@nxp.com> > > Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > > soc_device_match way > > > > On Wed, May 23, 2018 at 4:21 AM, Ulf Hansson <ulf.hansson@linaro.org> > > wrote: > > > On 23 May 2018 at 10:55, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > > >> > > >> -----Original Message----- > > >> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > > >> Sent: 2018年5月23日 14:41 > > >> To: Yinbo Zhu <yinbo.zhu@nxp.com> > > >> Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter > > >> <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie > > >> <xiaobo.xie@nxp.com> > > >> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > > >> soc_device_match way > > >> > > >> On 23 May 2018 at 05:50, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > > >>> Sent: 2018年5月22日 20:16 > > >>> To: Yinbo Zhu <yinbo.zhu@nxp.com> > > >>> Cc: Y.b. Lu <yangbo.lu@nxp.com>; Adrian Hunter > > >>> <adrian.hunter@intel.com>; linux-mmc@vger.kernel.org; Xiaobo Xie > > >>> <xiaobo.xie@nxp.com> > > >>> Subject: Re: [PATCH v2] mmc: sdhci-of-esdhc: modify the sd clock in > > >>> soc_device_match way > > >>> > > >>> On 22 May 2018 at 14:06, Yinbo Zhu <yinbo.zhu@nxp.com> wrote: > > >>>> From: yinbo.zhu <yinbo.zhu@nxp.com> > > >>>> > > >>>> Convert to use soc_device_match method to fix up eSDHC clock for > > >>>> ls1046a/ls1012a/p1010. Also add eSDHC clock fixup for ls1021a > > >>>> according to its datasheet. The maxmum speed for ls1021a eSDHC high > > >>>> speed mode is 46.5MHz. > > >>> > > >>>>Why not use mmc DT property "max-frequency" instead? > > >>> > > >>>>Why exactly do you need a different max frequency depending on the > > selected speed mode? > > >>> > > >>>>Kind regards > > >>>>Uffe > > >>> Accroding to datasheet that the different max frequency depending on > > >>> the slected speed mode and SoC, > > >> > > >>>That it depends on the SoC, that I am or course fine with. > > >> > > >>>My point is rather that I think it depends on the actual slot connector (or > > board), rather that on the speed mode. > > >>>For example, one port may have an eMMC and for some reason it can be > > >>>run in a speed mode using full clock rate. Another one may be an > > >>>SD-card slot, and perhaps because of some external logic, the signal quality > > doesn't survive a too high clock- rate. Etc. > > >> > > >>>Other SoCs and platforms works like this, I am sure yours do as well. No? > > >> > > >>> In the current state that which only shows one of the max-frequency, > > >>> so it can't use mmc DT property "max-frequency" instead > > >> > > >>>According to my comments above, could you please investigate once > > >>>more, whether really "max-frequency" can be used as the DT binding? > > >> > > >>>If it can't then I think we should consider introducing new mmc DT > > bindings instead. > > >> > > >>>[...] > > >> > > >>>Kind regards > > >>>Uffe > > >> Hi Uffe, > > >> > > >> Attachment is some pictures which in data sheet, I think it can explain that > > max frequency depending on the slected speed mode and SoC, You can have a > > look. > > >> > > > > > > Thanks, yes, this seems to confirm it. Kind of weird that none until > > > now have raised issues about similar constraints to be needed. > > > > > > So, we can either use your suggested solution, via soc_device_match() > > > method, if you prefer, else we need to invent a new DT property for > > > each speed mode constraint. > > > > Yinbo, > > > > According to the comment of the soc_device_match() API, it is for cases when > > device tree doesn't provide enough information to identify the variant. But I > > don't think it is the case for the SoCs you added in this patch, they all have > > unique compatible strings in the dts files. Why don't we use of_match_node() > > instead? > > > > [Y.b. Lu] By now the of_match_node() could handle this case. What if this kind erratum happens on specific soc revision in the future? If that happens in the future, we should define new compatible string for that revision. "For new devices, the DT binding should always provide unique compatible strings that allow the use of of_match_node() instead." quoted from soc_device_match(). If there is new problem found on old SoCs without unique compatible string, we could then use this soc_device_match() mechanism. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index 4ffa6b1..4d82c6d 100644 --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -29,11 +29,58 @@ #define VENDOR_V_22 0x12 #define VENDOR_V_23 0x13 +struct esdhc_clk_fixup { + /* SD speed modes */ + long ds; + long hs; + long sdr12; + long sdr25; + long sdr50; + long sdr104; + long ddr50; + /* MMC speed modes */ + long mmc_ds; + long mmc_hs; + long hs200; + long ddr52; +}; + +static struct esdhc_clk_fixup ls1021a_esdhc_clk = { + .mmc_hs = 46500000, + .hs = 46500000, +}; + +static struct esdhc_clk_fixup ls1046a_esdhc_clk = { + .sdr104 = 167000000, + .hs200 = 167000000, +}; + +static struct esdhc_clk_fixup ls1012a_esdhc_clk = { + .sdr104 = 125000000, + .hs200 = 125000000, +}; + +static struct esdhc_clk_fixup p1010_esdhc_clk = { + .ds = 20000000, + .hs = 40000000, + .mmc_ds = 20000000, + .mmc_hs = 42000000, +}; + +static struct soc_device_attribute soc_esdhc_clk_fixup[] = { + { .family = "QorIQ LS1021A", .data = &ls1021a_esdhc_clk}, + { .family = "QorIQ LS1046A", .data = &ls1046a_esdhc_clk}, + { .family = "QorIQ LS1012A", .data = &ls1012a_esdhc_clk}, + { .family = "QorIQ P1010", .data = &p1010_esdhc_clk}, + {}, +}; + struct sdhci_esdhc { u8 vendor_ver; u8 spec_ver; bool quirk_incorrect_hostver; unsigned int peripheral_clock; + const struct esdhc_clk_fixup *clk_fixup; }; /** @@ -485,6 +532,14 @@ static void esdhc_clock_enable(struct sdhci_host *host, bool enable) } } +static long esdhc_clock_fixup(long clock, long clock_standard, long fixup) +{ + if (!fixup) + return clock; + + return (clock == clock_standard) ? fixup : clock; +} + static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) { struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); @@ -492,6 +547,7 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) int pre_div = 1; int div = 1; ktime_t timeout; + long fixup; u32 temp; host->mmc->actual_clock = 0; @@ -505,26 +561,31 @@ static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock) if (esdhc->vendor_ver < VENDOR_V_23) pre_div = 2; - /* - * Limit SD clock to 167MHz for ls1046a according to its datasheet - */ - if (clock > 167000000 && - of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc")) - clock = 167000000; - - /* - * Limit SD clock to 125MHz for ls1012a according to its datasheet - */ - if (clock > 125000000 && - of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc")) - clock = 125000000; - - /* Workaround to reduce the clock frequency for p1010 esdhc */ - if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) { - if (clock > 20000000) - clock -= 5000000; - if (clock > 40000000) - clock -= 5000000; + switch (host->mmc->ios.timing) { + case MMC_TIMING_LEGACY: + fixup = esdhc->clk_fixup->ds; + clock = esdhc_clock_fixup(clock, FULL_SPEED_MAX_DTR, fixup); + fixup = esdhc->clk_fixup->mmc_ds; + clock = esdhc_clock_fixup(clock, MMC_HIGH_26_MAX_DTR, fixup); + break; + case MMC_TIMING_SD_HS: + fixup = esdhc->clk_fixup->hs; + clock = esdhc_clock_fixup(clock, HIGH_SPEED_MAX_DTR, fixup); + break; + case MMC_TIMING_MMC_HS: + fixup = esdhc->clk_fixup->mmc_hs; + clock = esdhc_clock_fixup(clock, MMC_HIGH_52_MAX_DTR, fixup); + break; + case MMC_TIMING_UHS_SDR104: + fixup = esdhc->clk_fixup->sdr104; + clock = esdhc_clock_fixup(clock, UHS_SDR104_MAX_DTR, fixup); + break; + case MMC_TIMING_MMC_HS200: + fixup = esdhc->clk_fixup->hs200; + clock = esdhc_clock_fixup(clock, MMC_HS200_MAX_DTR, fixup); + break; + default: + break; } temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL); @@ -783,6 +844,7 @@ static SIMPLE_DEV_PM_OPS(esdhc_of_dev_pm_ops, static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) { + const struct soc_device_attribute *matches; struct sdhci_pltfm_host *pltfm_host; struct sdhci_esdhc *esdhc; struct device_node *np; @@ -802,6 +864,9 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host) else esdhc->quirk_incorrect_hostver = false; + matches = soc_device_match(soc_esdhc_clk_fixup); + if (matches) + esdhc->clk_fixup = matches->data; np = pdev->dev.of_node; clk = of_clk_get(np, 0); if (!IS_ERR(clk)) {