* Raphaël Assénat <raph@xxxxxx> [110704 12:51]: > > The am3505 is apparently so similar to the 3430 that it was treated as such > (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a > few differences that need to be addressed. I have therefore created a new > CHIP_IS and patched clocks, hwmod and power management related files > consequently. My system now boots until it complains that it is unable > to mount its root filesystem. Can you please describe where you need CHIP_IS for am3505? It seems that your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too? I'd rather see us improve the code so we can support am3505 properly without a need to patch all over the place.. > One of the next things I'll look at is how to properly support the ZCN package. > Right now, the CBB package is used (board-am3517evm.c for instance) but there > are differences that prevent some GPIOs from being configured properly. It would > be nice to know if someone is working on this before I start... You should be able to handle the differences easily just by adding a new package_subset to mux34xx.c, that just overrides the desired pins in omap3_muxmodes. Eventually we will be using device tree + common mux framework for this, but you might as well do the omap3_znc_subset meanwhile as we can then generate the device tree entries for all of them. That is assuming it's not a huge delta from omap3_muxmodes :) Regards, 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
