Hi Stephen On Fri, 26 Jul 2013, Stephen Warren wrote: > On 07/26/2013 09:51 AM, Guennadi Liakhovetski wrote: > > Add DT properties for UHS SDR12, SDR25, SDR50, SDR104 and DDR50 modes and > > for supported by the host in DDR mode VccQ values. Adding them to DT will > > automatically enable respective MMC host capabilities. > > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > > > +- uhs-sdr12: the host supports UHS SDR12 mode > > +- uhs-sdr25: the host supports UHS SDR25 mode > > +- uhs-sdr50: the host supports UHS SDR50 mode > > +- uhs-sdr104: the host supports UHS SDR104 mode > > +- uhs-ddr50: the host supports UHS DDR50 mode > > +- ddr-1v2: the host can support DDR, using 1.2V VccQ > > +- ddr-1v8: the host can support DDR, using 1.8V VccQ > > Surely the driver for the host controller already knows this, so there's > no need to represent it in DT? Not necessarily. One driver can handle several versions of the same chip, and some versions of the chip implement some of those features, others don't. So, your choice is really whether to specify a chip version in the compatible string or these properties. Now, when you consider that multiple drivers have to decide upon those, and sometimes you don't have an exact IP version of the SD/MMC controller but only the SoC version, you choice becomes: either _standard_ _common_ properties as above, or compatibility strings virtually in each driver for each SoC version. That's why I decided to use explicit properties for those. Example: sh_mmcif driver supports MMCIF IP blocks on various Renesas sh-, r-mobile and r-car SuperH and ARM SoCs. On some of them DDR50 is supported, on others it isn't. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
