>-----Original Message-----
>From: Tony Lindgren [mailto:[email protected]]
>
>* Pandita, Vikram <[email protected]> [090616 09:50]:
>>
>> >From: Kevin Hilman [mailto:[email protected]]
>> >
>> >"Pandita, Vikram" <[email protected]> writes:
>> >
>> >>>-----Original Message-----
>> >>>From: Tony Lindgren [mailto:[email protected]]
>> >>>Sent: Monday, June 15, 2009 6:05 AM
>> >>>To: Hugo Vincent
>> >>>Cc: Pandita, Vikram; [email protected]; Chikkature Rajashekar,
>> >>>Madhusudhan
>> >>>Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins
>> >>>
>> >>>* Hugo Vincent <[email protected]> [090615 03:44]:
>> >>>>
>> >>>> On 15/06/2009, at 8:12 PM, Tony Lindgren wrote:
>> >>>>
>> >>>>> * Vikram Pandita <[email protected]> [090612 15:43]:
>> >>>>>> For OMAP3 add MMC1 MMC2 and MMC3 pin mux
>> >>>>>>
>> >>>>>> Signed-off-by: Chikkature Rajashekar <[email protected]>
>> >>>>>> Signed-off-by: Vikram Pandita <[email protected]>
>> >>>>>> ---
>> >>>>>> 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.
>
>To me it seems cleanest just to do the muxing in board-*.c files and not even
>attempt to do it in a generic way. As we also support doing the muxing in
>the bootloader only, adding a flag for nomux can easily create hard to
>track bugs.
Ok.
>
>If some pins are always needed, and don't have alternative pinouts, then
>the common pins could be muxed in devices.c.
This is the algo we can use for MMC pin muxing in that case:
MMC1: No pin has mux clash
Mux all 10 pins in devices.c
MMC2: MUX CLK,CMD,D0-D3 in devices.c: D4-D7 have mux clash
In case board needs 8 bit support,
then in devices.c print KERN_WARNING "Configure MMC2:D4-D7 mux in board
file"
MMC3: All pins have mux clash: No mux done in devices.c
In case board specifies MMC3 usage,
then in devices.c print KERN_WARNING "Configure MMC3 mux in board file"
Let me know if this is final and I can submit a patch.
>
>Regards,
>
>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
