* Rajendra Nayak <rnayak@xxxxxx> [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
--
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
