On Mon, 17 Mar 2008 20:42:14 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > > Dear Grant, > > > > > > in message <[EMAIL PROTECTED]> you wrote: > > > > > > However, I have declined (for now) to pick up the defconfigs for those > > > boards and instead merged in the config features they require into the > > > mpc5200 defconfig. My primary reason for doing so is to increase the > > > likelyhood that full featured kernels are built and tested so that > > > situations where board ports conflict with each other are caught and > > > fixed. > > > > I know what you mean, and I agree with the idea. > > > > Unfortunately I think it's impossible to implement, especially on such > > embedded processors with their high level of pin multiplexing. > > > > For example, if you want to include testing of the FEC ethernet > > driver, you will probably fail to test the second USB port. I think > > it's simply not possible to test all possible options in a single > > kernel configuration - first it doesn't work (for example because of > > pin multiplexing issues), second you will likely not be able to find > > hardware that implements all features at once. > > I don't think this example really applies. Yes, I agree that I cannot > test all the functions, but that does not preclude building in all the > drivers and making sure that they don't cause a conflict by just being > present. For instance, I can build a single kernel image right now > that should boot and fully run on the Efika, lite5200, tqm and motion > pro boards (although the Efika has a different wrapper). I can only > test it on the Efika and lite5200 boards and I have to rely on other > people for the boards I don't have. If it breaks; I expect to receive > an irate email in my Inbox telling me to fix it! > > pin multiplexing shouldn't be an issue at all. Only the devices which > are instantiated in the device tree will actually get initialized so > if the pins aren't hooked up then it shouldn't be in the tree. That's not entirely true. Devices that are muxed can be added to the tree just fine. What I've done on 440 boards that have devices that share pins is to add a status = "disabled"; property to the device that doesn't have pins at the moment. See my patch for of_device_is_available for how to query that. I'll be throwing that in my tree soon if Paul doesn't pick it up. josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
