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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
