>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > >"Pandita, Vikram" <vikram.pandita@xxxxxx> writes: > >>>-----Original Message----- >>>From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] >>>Sent: Monday, June 15, 2009 6:05 AM >>>To: Hugo Vincent >>>Cc: Pandita, Vikram; linux-omap@xxxxxxxxxxxxxxx; Chikkature Rajashekar, Madhusudhan >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins >>> >>>* Hugo Vincent <hugo.vincent@xxxxxxxxx> [090615 03:44]: >>>> >>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote: >>>> >>>>> * Vikram Pandita <vikram.pandita@xxxxxx> [090612 15:43]: >>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux >>>>>> >>>>>> Signed-off-by: Chikkature Rajashekar <madhu.cr@xxxxxx> >>>>>> Signed-off-by: Vikram Pandita <vikram.pandita@xxxxxx> >>>>>> --- >>>>>> arch/arm/mach-omap2/devices.c | 33 ++++++++++++++++++++++ >>>>>> arch/arm/mach-omap2/mux.c | 49 +++++++++++++++++++++++ >>>>>> ++++++++++ >>>>>> arch/arm/plat-omap/include/mach/mux.h | 28 +++++++++++++++++++ >>>>> >>>>> Great, just one issue: All data pins may not be connected, so you >>>>> need to look at wires in struct omap_mmc_slot_data to see how many >>>>> data pins to mux. >>>> >>>> There is another issue: different mux-outs are possible for different >>>> board layouts; for example, I'm using AE10_3430_MMC3_CMD instead of >>>> AC3_3430_MMC3_CMD. I'm not sure what the best way of handling this is, >>>> but at a minimum, perhaps make mux setting optional, e.g. add no_mux to >>>> struct omap_mmc_slot_data. >>> >>>Hmm, yeah that's right. I guess only the common pins should be muxed >>>in devices.c, and any optional pins should be muxed in the board-*.c >>>files. >> >> Please check this patch set: >> [PATCH 1/2] OMAP3: MMC: Pass pin muxing control flag >> >> I used the nomux flag to do this distinction. >> > >This still doesn't address the problem that when you do mux, you mux >all OMAP3 platforms the same way, and that is not correct. The patch tries to address this exact concern. Using nomux flag, the board file decides if the default mux for each MMC(n) controller is good for it or not. In case default is good, then MMC(n).nomux=0 In case default mux for any one MMC controller is not good, then for that MMC(n).nomux=1 And the board file specifies the mux for that MMC(n) only. I do not see any advantage to control mux at ball level for each mmc controller instance. > >Only some of it is common, the others are platform specific. > >Kevin -- 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
