[PATCH 2/3] ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins

[tony@atomide.com (Tony Lindgren)]

* Rajendra Nayak <rnayak@ti.com> [120216 08:19]:
> On Thursday 16 February 2012 10:05 PM, Tony Lindgren wrote:
> >>On Thursday 16 February 2012 03:33 PM, Rajendra Nayak wrote:
> >>>>  >better still, I think we should just populate them statically in
> >>>>  >omap2_hsmmc_info struct above, so omap_hsmmc_init() takes care
> >>>>  >of it already.
> >>>
> >>>  I just tried this and it seems to work...
> >>>
> >>>  ---
> >>>    arch/arm/mach-omap2/board-omap3beagle.c |    1 +
> >>>    1 file changed, 1 insertion(+)
> >>>
> >>>  Index: linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c
> >>>  ===================================================================
> >>>  --- linux-2.6.orig/arch/arm/mach-omap2/board-omap3beagle.c
> >>>  2012-02-16 15:38:47.046933403 +0530
> >>>  +++ linux-2.6/arch/arm/mach-omap2/board-omap3beagle.c   2012-02-16
> >>>  15:40:17.355349064 +0530
> >>>  @@ -253,6 +253,7 @@
> >>>                   .mmc            = 1,
> >>>                   .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
> >>>                   .gpio_wp        = -EINVAL,
> >>>  +               .gpio_cd        = OMAP_MAX_GPIO_LINES + 0,
> >>>                   .deferred       = true,
> >>>           },
> >>>           {}      /* Terminator */
> >Would be nice to avoid the hard coded gpio numbering for the
> >external chips though..
> 
> But if you look closely, thats exactly how its handled today.
> All board files hardcode gpio_base to OMAP_MAX_GPIO_LINES in
> twl4030_gpio_platform_data. And thats what gets passed back
> when the driver calls pdata->setup() from within probe.

Hmm that's not necessarily safe to do as you might have multiple
external GPIO connected, such as a PMIC and FPGA..

Anyways, it seems OK to me for now, as the DT solves that issue
properly and I don't think we currently have any boards with
multiple external GPIO chips.

Regards,

Tony