On 04/14/2015 08:29 PM, Lennart Sorensen wrote:

On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote:

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html