* Grant Likely <grant.likely@xxxxxxxxxxxx> [091202 09:24]: > On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson <olof@xxxxxxxxx> wrote: > > On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote: > > > >> Ah, you're talking about pin muxing configuration, right? Yes, that > >> GPIO binding deals with controllers, not pin mux. Pin mux is very > >> much an SoC specific thing that isn't mapped easily to a generic > >> binding. > > > > Yep. > > > >> On the 5200, I haven't attempted to describe pin-mux in the device > >> tree at all, and have either expected firmware to set it up correctly, > >> or fixed it up in the platform code. > > > > Yeah. And it's one of the things Tony commented on that firmware tends > > to get wrong, seems like people aren't doing complete mux configs in > > u-boot, etc. > > > > So, if it needs to be fixed up in platform code, there will (likely) be > > need for board-specific code there anyway. A bummer, since the device > > tree would otherwise make it real easy to bring up new boards without > > kernel code changes. > > I didn't create a binding on the 5200 because I actually see very > little buggy firmware in that regard (partially because I kept telling > people to go fix their firmware). :-) If it ends up being the norm > that the kernel has to fix it for a given SoC, then I would create an > SoC-specific binding for pin mux configuration in the device tree so > that some degree of common code can still fix it up. > > It should be feasible for board-specific code to be the exception, not the rule. The problem with pin multiplexing is that development boards such as Beagle don't know the desired configuration in the bootloader. There are pins available for connecting external hardware, such as I2C, SPI, or whatever to the 16-bit GPMC bus. Also, the bootloaders tend not to care about pin multiplexing for power management. We now have kernel cmdline override for pin multiplexing, but that does not help with adding platform_data for custom I2C or SPI devices. Just something to keep in mind, I still think we can benefit from the open firmware support in various ways :) 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
