On 22 August 2012 15:47, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi, > > On Wed, Aug 22 2012, Shawn Guo wrote: >> The following is what I have on my mind. >> >> broken-cd cd-gpios implication >> ------------------------------------------- >> no no SDHCI CD >> no yes GPIO CD >> yes no NO CD / Broken CD >> yes yes Invalid >> >> yes: property presents >> no: property does not present > > This matches Mitch's last suggestion exactly -- I think we're all agreed > on these properties now. The only remaining question is how to handle > the pinctrl for CD in Thomas's case. Hi Chris, For sdhci-s3c driver, the 'broken-cd' and 'cd-gpios' bindings are sufficient. But, are drivers free to use implementation specific behavior when using these bindings. Or do we strictly adhere to the table which Shawn has listed. For sdhci-s3c driver, I would like to deviate from the "implication" column listed above. On second thoughts, I now understand that gpio's terminate at the gpio controller, not at the card-detect pad of the mmc host controller. Those that terminate at the mmc controller pads are actually mux functions. I do agree that the long term solution for sdhci-s3c driver is to use the pinctrl driver. If sdhci-s3c has to strictly adhere to the Shawn's table above, then I prefer to postpone the device tree support in sdhci-s3c driver after having proper support for Samsung pinctrl driver. But then, sdhci-s3c driver is used on multiple Samsung SoC's, all of which might not get pinctrl driver support anytime soon. Hence, for sdhci-s3c driver, 'broken-cd' and 'cd-gpios' bindings are sufficient, but sdhci-s3c driver should be free to use these bindings in a implementation specific way. Thanks, Thomas. -- 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
