[...] >> 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. > > 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. > I think we have reached a consensus on the viable options. As we haven't heard from Ivan, do someone want to send a patch for this or shall we just revert $subject patch (which I can deal with)? 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
