Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux