* Jon Hunter <jon-hunter@xxxxxx> [090618 03:08]: > > Pandita, Vikram wrote: >>>> 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. > > Actually, the mux configuration is still valid for the CBC and CUS > packages. The only difference is the balls have different names. Sorry > if this is not clear. > > For example, on the OMAP3530 CBB package if you look at ball N28 you > will find: > > mux-mode0 --> mmc1_clk > mux-mode4 --> gpio120 > mux-mode7 --> safe mode > > For the OMAP3530 CBC package you will find the same options on N19 and > for the CUS package the same options on ball M23. > > I have been doing a bit more looking at this and we do need to becareful > here. I think that we really need to view the OMAP3430 as a superset of > the OMAP3530. One example being, with the OMAP3530 I don't see support > for peripherals such as DSI, CSI, and MS. Hence, muxing options for the > signals corresponding to these peripherals are not shown in the OMAP3530 > data manual. > > This just means that there are less muxing options on some of the balls > for the OMAP3530, but the good news is that there will not be any > conflicts between the OMAP3430 and OMAP3530 as far as muxing goes. Sounds good. We also need to consider the number of MMC data lines used for muxing, that's available as wires from the board-*.c files. >>> 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. > > I was thinking this too. For different applications different packages > make sense. So this is fairly common to see. So dropping the ball name > would make this easier. > > I guess the only benefit is knowing the actual ball that you are using > for hardware purposes. However, on OMAP2/3 the register names imply what > is mux-mode0 and so it fairly easy to figure out the ball number from > the data manual. Yeah let's plan on making that change. Tony -- 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
