>-----Original Message----- >From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >Sent: Wednesday, June 17, 2009 5:58 PM >To: Hunter, Jon >Cc: Pandita, Vikram; Tony Lindgren; Hugo Vincent; linux-omap@xxxxxxxxxxxxxxx; Chikkature Rajashekar, >Madhusudhan >Subject: Re: [PATCH] OMAP3: MMC: Add mux for pins > >Jon Hunter <jon-hunter@xxxxxx> writes: > >> Kevin Hilman wrote: >>> "Pandita, Vikram" <vikram.pandita@xxxxxx> writes: >>> >>>>> -----Original Message----- >>>>> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>>> >>>>>>> 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 >>>>> Is this common across 34xx and 35xx? >>>> Yes this is common. >>>> Both are same OMAP3 marketed differently. >>> >>> Yes, but they are in different packages, so I was curious if the pin >>> muxing is identical across the different packages. >> >> The ball/pad numbers may change due to the package, but the registers >> used to configure the pin muxing and the pin muxing options will not >> change. So from a software standpoint it is the same. >> >> The OMAP3530 is available in 3 packages, namely CBB, CBC and CUS >> according to the data manual [1]. The OMAP3430 is only available in >> the CBB package. >> >> What this means is that the name "N28_3430_MMC1_CLK", which associates >> ball N28 with signal MMC1_CLK, is appliable to the OMAP3430 and >> OMAP3530 CBB package, but not applicable to the OMAP3530 CBC and CUS >> packages >> as this ball number does not exist on these packages. This is simply a >> difference in naming of the balls between the packages but does not >> impact the pin muxing options. So looks like I should keep the MMC mux under cpu_is_omap3430() And not include 3530 as CBC and CUS may not be valid cases for this mux. > >OK, good. Thanks for the clarification. > >Tony and I were thinking a few weeks back that we should drop the ball >names from these mux options anyways as they don't really add any >value, and seem to add more confusion. Sounds like it's the right >thing to do in this context. > >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
