[U-Boot] OMAP_HSMMC and MMC getcd discrepancy

[Adam Ford]

I am trying to port my OMAP3630 board to use DM_MMC and
OMAP_HSMMC_USE_GPIO without CONFIG_DM_MMC_OPS and with OF support by
porting the OMAP3 device tree and I think there might be an issue with
card detect. I am hoping someone might be able to clarify it for me.

For what it's worth, the card detection in the device tree I have
works fine under Linux, so I think the issue is more related to U-Boot
than the device tree itself.

My understanding of mmc_getwp and mmc_getcd from mmc.c is that both of
them are going to be pointing to a functions that reads the status of
the write protect and card detect pins.  The omap_hsmmc driver maps
these functions to omap_hsmmc_getcd and omap_hsmmc_getwp.

There are two versions, one when DM_MMC is defined and one without it defined.

Looking at the two getcd functions, it appears as if they boot look
for the returned value of the gpio pin.  Since  CD pins are asserted
low, I would expect that when the card is detected the CD pin would be
0 and 1 when absent.  I would also expect the same for the WP pin.

The non-DM_MMC version of the card detect function appears to address
this in a comment "/* NOTE: assumes card detect signal is active-low
*/ and returns the opposite of the gpio value with
!gpio_get_value(cd_gpio);

However, the DM_MMC version has a check to see if the flag is
inverted. Since these signals are passed to the higher level mmc
driver, it seems like when the gpio is low, the return value should be
high (card is detected when gpio = 0), yet it only inverts when the
extra flag is set in the device tree and it seems like the logic is
backwards.

I am wondering if the omap_hsmmc_getcd using DM_MMC should instead read use:

  if (priv->cd_inverted)
     return value;
  return !value;

If this makes sense, I can supply a patch, but I wanted to make sure I
have the correct understanding first.  Can someone please confirm if I
am understanding this correctly?

adam