On 22 August 2012 15:47, Chris Ball [off-list ref] wrote:

Hi,

On Wed, Aug 22 2012, Shawn Guo wrote:

quoted

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.