* David Brownell <[EMAIL PROTECTED]> [081030 20:12]: > On Thursday 30 October 2008, Tony Lindgren wrote: > > @@ -212,7 +212,7 @@ static void __init overo_init(void) > > omap_board_config = overo_config; > > omap_board_config_size = ARRAY_SIZE(overo_config); > > omap_serial_init(); > > - hsmmc_init(); > > + hsmmc_init(HSMMC1); > > Overo has its SDIO WLAN chip (libertas) hard wired to the second controller, > as I understand things ... or maybe it's the third one. :)
OK > Related: shouldn't hsmmc_init() accept a set of params, maybe even a struct, > describing how each controller is wired? > > - which controller (1, 2, 3) > - how many data wires are used (1, 4, 8) > - supported voltages (mask) > - card detect gpio (or negative) ... assume gpio_to_irq(gpio) works > - write protect gpio (or negative) > - callback for updating the voltages > > That would support more complete functionality ... and get away from > the current hard-wiring of most of those parameters. Yeah I don't know what the right solution is.. I was thinking about passing the struct omap_mmc_platform_data to hsmmc_init, but then again hsmmc.c does not know anything about the custom configurations and the power functions. So right now hsmmc.c would only call omap2_init_mmc() with the custom struct omap_mmc_platform_data. Maybe we should just let the boards with non-standarad wiring additionally initialize the other mmc controllers from board-*.c by calling omap2_init_mmc()? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
