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.