[...] >> Ahh, I see. >> >> It seems like a reasonable assumption that the controller can't cope >> with a higher clock rate than 100 MHz as "input" clock. That would >> then mean that there are different versions of the controller, as it >> seems like for some version it's fine with 200MHz and for some 100MHz. >> >> According to the DT compatible strings, *one* version is currently >> supported, "qcom,sdhci-msm-v4"... > > The same version of hardware is there 4 times. The difference is > the maximum clock frequency supported by them is different. In > downstream kernels we've handled this by trimming the frequency > tables for the different controllers in the clock driver. > Setting the clock to INT_MAX will make it run at 400MHz, which > doesn't look to be supported by anything besides sdc1 on 8974ac. > >> >> I see two viable solutions. One would be to limit the clock rate >> depending on the version of the controller (new compatible strings >> needs to be added). Another one would be to limit the clock rate by >> using the existing DT binding for max-frequency, and thus do a >> clk_set_rate(mmc->f_max) during probe. >> > > I'd rather see that done via OPP tables in DT, but I suppose > max-frequency is fine too. We'll need to use OPPs soon enough > because there's a voltage associated with that frequency. Okay, thanks for sharing the details. > > In case you're wondering, the max frequency for sdc1 on 8974ac is > 400MHz. If it's just a plain 8974pro then the max frequency is > 200MHz. Otherwise, sdc2 maxes out at 200Mhz and sdc3 and sdc4 max > out at 100MHz. When you say that sdc1 supports 400MHz, what does that mean? That it actually can cope with that clock rate when communicating with the MMC card? This makes me wonder how you deal with power management (DVFS). For example when you have the possibility to gate this clock (at request inactivity) when the rate is set to 400 MHz and OPP is increased, how will then that clock gating affect the OPP? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
