Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933834AbbDOQwK (ORCPT ); Wed, 15 Apr 2015 12:52:10 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:34627 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756511AbbDOQwB (ORCPT ); Wed, 15 Apr 2015 12:52:01 -0400 Message-ID: <552E9714.10001@ti.com> Date: Wed, 15 Apr 2015 11:51:32 -0500 From: Nishanth Menon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Lennart Sorensen , Tony Lindgren CC: Linus Walleij , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Linux-OMAP , "linux-arm-kernel@lists.infradead.org" , Lokesh Vutla Subject: Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration References: <1425427237-11511-1-git-send-email-nm@ti.com> <1425427237-11511-2-git-send-email-nm@ti.com> <20150310153321.GO5264@atomide.com> <54FF28F5.4040707@ti.com> <20150310173115.GS5264@atomide.com> <54FF38F3.2030703@ti.com> <20150318014151.GL31346@atomide.com> <20150415012910.GA29560@csclub.uwaterloo.ca> In-Reply-To: <20150415012910.GA29560@csclub.uwaterloo.ca> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1540 Lines: 37 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/