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. 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
