On 04/14/2015 08:29 PM, Lennart Sorensen wrote: > On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote: >> Yeah agreed. I suggest discussing the binding and the generic >> parsing code for it first :) >> >> It seems with the generic binding the actual driver should be >> just the hardware specific code hopefully. > > Did this thread go anywhere in the last month? I am certainly looking > forward to seeing what the resolution is to this, given for our use the > boot loader setup is not appealing at all. > I am yet to post a new revision to this series - few other stuff got in the way. IODelay driver in no way removes the constraint that the SoC architecture has - most of the pins still need to be muxed in bootloader - we cannot escape that. The reasoning for doing the mux in bootloader is independent of the need for iodelay. Reasoning for mux in bootloader is because the mux and pull fields are glitchy - much more than previous generations of TI SoCs and significantly long enough to cause issues depending on the pins being muxed. Reasoning for iodelay is different - it is a hardware block meant to control the timing of signals in a particular signal path to ensure that specification compliance is met. Lets try not to mix the two. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
