On 01/25/2013 01:57 PM, Lucas Stach wrote: > Am Samstag, den 26.01.2013, 10:49 +1300 schrieb Simon Glass: > [...] >>> But yes in the end we want to pack this information into the DT files. >>> But even then it would be nice if people would test this pachset, as I >>> imagine DT based pinmux is the same as tablebased pinmux, just in a >>> slightly different flavour. ;) So if people test the tablebased config >>> now, we can do the conversion to DT based with a lot more confidence. >>> >>> I'll look into using the kernel pinmux binding minus the MUX stuff, as I >>> think there's no real reason to have this in U-Boot. >> >> Well I would rather than we get that running than switch to >> table-driven mux, assuming it is not too big a job? >> >> I imagine perhaps naively that a function could be written which >> parses the pinmux and sets it up in U-Boot - effectively using the FDT >> as the pinmux table. > > That's my plan. But still even if we keep the binding the same, the > actual pinmux config would differ between the kernel and U-Boot (a lot > more pads kept in tristate in U-Boot). So as the FDT would effectively > resemble the same tables I included in this patchset, some testing > coverage of that would smoothen the transition.
Why wouldn't the pinmux tables in the FDT passed to U-Boot either be identical to (a) the kernel, or (b) the small subset of the pinmux options that U-Boot used to program via code? I don't see any reason for U-Boot to program all the pingroups to TRISTATE etc.; if it's programming those pingroups at all, it may as well just program the correct final value. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot