Hi Chris On Mon, 5 Aug 2013, Chris Ball wrote: > Hi Guennadi, > > On Mon, Aug 05 2013, Guennadi Liakhovetski wrote: > > Add compatibility strings to configure MMCIF revision-specific features. > > MMCIF blocks are always integrated into SoCs, so, we use SoC model to > > distinguish between MMCIF versions. > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas@xxxxxxxxx> > > --- > > > > Hi Chris, > > I marked this as RFC, because having no access to the MMC standard I'm not > > certain about VccQ requirements for MMC DDR. On the one hand a comment in > > mmc.c says > > * EXT_CSD_CARD_TYPE_DDR_1_8V means 3.3V or 1.8V vccq. > > which suggests, that DDR (DDR50?) can be used with VccQ = 3.3V, 1.8V and > > 1.2V at least. But in mmc_init_card() DDR50 is only requested from the > > driver if either MMC_CAP_1_8V_DDR or MMC_CAP_1_2V_DDR is specified in > > host's capabilities. So, I'm actually not sure whether MMC_CAP_UHS_DDR50 > > alone without 1_8V or 1_2V makes sense. That's also what I implemented in > > this patch - DDR50 is only enabled in combination with either 1.2 or 1.8V > > capability. Is this correct? > > OLPC's using DDR50 at 3.3V in production. Honestly, I don't know > whether it's spec compliant (I think the spec claims that 1.8V is > required) but it happens to work on these parts. The host controller > does support 1.8V, there's just no hardware capable of supplying 1.8V > to MMC on the board. Thanks for the example. So, I think, for now it should be ok to just act in a way, compatible with the mmc core, i.e. always set one of MMC_CAP_1_8V_DDR or MMC_CAP_1_2V_DDR, when aiming at MMC_CAP_UHS_DDR50. So, the patch should be ok then. 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
