On Wed, Sep 11, 2013 at 4:26 AM, Dong Aisheng <b29396@xxxxxxxxxxxxx> wrote: > Hi Matt, > > I somehow agree with your idea on the naming. > But currently i'm just using the standard property defined in: > Documentation/devicetree/bindings/mmc/mmc.txt > - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on > this system, even if the controller claims it is. Whoever did that needs kicking :< >> This property should probably be called "voltage-selects" or something >> and you should put in a list of supported voltages (in uV units just >> like cpufreq operating points and regulators, please, for consistency, >> and update the binding). > > Here the no-1-8-v is for indicating no 1.8v signal voltage switch support, > not the host supply voltage. > The spec only defines 1.8v/3.3v switch, so no-1-8-v seems ok for me currently. I thought the spec also has a 1.2V mode.. so what do the MMC guys propose, adding no-1-2-v properties too? And if there exists in the future a 0.8V mode, another property? And another? > That's how sdhci driver used currently. > So i'm not sure if we really need add the voltage-selects on device tree > for mmc since that's regulator's work. Understood. My initial thought is simply that the MMC class should define a behavior which you could assume - in this case, that a host supports a certain set of voltages (for supply and for signalling), and a card supports a certain set of voltages (for supply and for signalling). In the case of the combinations here, this is all in the spec and defined. However, what device trees should do is essentially provide information where the defaults or documentation contain assumptions, and supplant them when necessary. An MMC host controller given a regulator now knows it can change voltages. But to what values? Most regulators are fixed or have a wide range. A regulator that is defined for 1.8V and 3.3V is defined as 1.8V *through* 3.3V meaning you COULD set it to 2.5V if you wanted to. A property defining the valid voltages is good here. For the case where someone screwed a board design or a regulator is weak somehow, you could put 1.85V in the property to say, this is my close-enough-to-1.8V value. Otherwise what happens is you get a regulator set failure if the range didn't include 1.8V, or weird issues because the voltage isn't high enough *for the design*. For signalling voltage, sure, there could be 1.8V and 3.3V defined in the host and the card, but the same applies - assume those in the driver, and the DT can define which ones are valid. For a driver probing, it can look in the DT table and see, I have a matching 1800000uV and a matching 3300000uV voltage. If it sees 1200000uV and it has no clue how to orient the system into using that voltage, it ignores it (it couldn't use it anyway, since it would have no knowledge of how to instruct a card to signal at that voltage). This works for the supply regulator setting and the signalling setting with a common, future-proof format.. In the future, it may work when the kernel is updated to support this as-of-yet non-existing functionality and the DT would have been correct from the start. > Anyway, above is just my initial thoughts on your question. > Since this issue actually is not related to this series, > maybe you could create a new mail thread about this if you want > or patching is welcome for the further discussion more specific. Well, a new thread.. sure. That might be for another day (it took me 2 weeks to get back to this one, I don't know the next time I will have enough time to go through LAKML :) I have written it on my whiteboard for future discussion, so I'll bring it up again as soon as I can.. -- Matt Sealey <neko@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
