From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9DB2BC43603 for ; Mon, 9 Dec 2019 00:20:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 547D1206E0 for ; Mon, 9 Dec 2019 00:20:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="YJ2Z9d1L" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726534AbfLIAU2 (ORCPT ); Sun, 8 Dec 2019 19:20:28 -0500 Received: from mail-lf1-f45.google.com ([209.85.167.45]:38275 "EHLO mail-lf1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbfLIAU2 (ORCPT ); Sun, 8 Dec 2019 19:20:28 -0500 Received: by mail-lf1-f45.google.com with SMTP id r14so9264888lfm.5 for ; Sun, 08 Dec 2019 16:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MHPwh1y/n4h6B3Kr1hQ3vt143Cypr4Zc4bxHvs1bL1s=; b=YJ2Z9d1LLO3HiNP5Cj86Xn9PhRPnCP461HYAfLOpE33VYg4X/b5RdZMTd5G8RTuLEx QcL1QGR9H3CYUKzsTz39bvQHbhtIt1XpuDyXeGSlBu4Mhw3gsH1mUAmUbFoJX5jOxC7m 4j2oYy6jJd7zrwoMAhPHfi20W3qlsFLgGZ2kLvaD+VU21KINczxmVb4OiITEOcWsPBZD bbdzjof/2gxGhZ/z0m6PXS0Fy7CLn/jNa0soMxwdUpbkfh4JMvOqyURODNZ16xDXqdhS FAk4OS0IEo8lvQLomW5Z4tV1tTGqQZKvOxFxlhpbQT9Of1ohFUmCpXXygdpESZeHVWz3 782Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MHPwh1y/n4h6B3Kr1hQ3vt143Cypr4Zc4bxHvs1bL1s=; b=ZfbGp+ZBT6SP3HZE+m5c2pgBI5qvpYdv3FQSCSgfuF8/kWxDU/AjfN9q9x3hpwSrj4 oqk5h7glW3uKtbSHYbsHepVn+Su2P+QJo8IEcHihFYfp+pTD2VPZ9xunFUA8c8epK0yW aOUpdadChEqMWWW+mop/XO+M4sT+cAEa0e+ZT2rY8MdnUft9cFICLY9LqXocmgNAwZd7 eP80MUlOY5HprTnR1Ez4RYHoVvOXxcLR+/mJ54lNFCiEm0M+bONQFq/mnMC+0yB7S2Qe o3+pprwKJM6VRKisxfX2cGMi+kc/rU9krXb5GQLcGwC+tH/zX07GGCkeunUqm/RbVe0d vDpw== X-Gm-Message-State: APjAAAXplEwxO7jmfbqvLTp+pRC21vUjSC3oFCTHGl3DY2YaM5253Piy oAE+NGDvSDWNa8PrnUKQ9PzIgUpCrxOrG19mSJEQIdxwe6F+8w== X-Google-Smtp-Source: APXvYqz1ICQM0K1LHeR6QTf4gipjvIQPfKyB9dj3sza1iGU1uUKxJniITX2rtw2pCgEXg1z77JkTiIlU37yi9pqJWBA= X-Received: by 2002:ac2:4945:: with SMTP id o5mr13375016lfi.93.1575850826412; Sun, 08 Dec 2019 16:20:26 -0800 (PST) MIME-Version: 1.0 References: <20191206173343.GX25745@shell.armlinux.org.uk> In-Reply-To: <20191206173343.GX25745@shell.armlinux.org.uk> From: Linus Walleij Date: Mon, 9 Dec 2019 01:20:15 +0100 Message-ID: Subject: Re: pinctrl states vs pinmux vs gpio (i2c bus recovery) To: Russell King - ARM Linux admin Cc: Linux ARM , "open list:GPIO SUBSYSTEM" Content-Type: text/plain; charset="UTF-8" Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Hi Russell, very nice description of this dual-mode problem. I wish I had a simple and elegant way we could make it unambiguous and simple to use ... but it beats me right now. On Fri, Dec 6, 2019 at 6:33 PM Russell King - ARM Linux admin wrote: > One may expect: > > pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default); > > to change them back to the default state, but that would be incorrect. > The first thing that pinctrl_select_state() does is check whether > > p->state == state > > which it will do, as the pinctrl layer hasn't been informed of the > change that has happened behind its back at the pinmux level. Some pin controllers have the .strict property set in their struct pinmux_ops: * @strict: do not allow simultaneous use of the same pin for GPIO and another * function. Check both gpio_owner and mux_owner strictly before approving * the pin request. The non-strict pin controllers are those that actually allow GPIO and device functions to be used on the same physical line at the same time. In this case there is not special GPIO mode for the line in some muxing registers, they are just physically connected somehow. One usecase is sort of like how tcpdump work for ethernet interfaces: a GPIO register can "snoop" on a pin while in used by another device. But it would notably also allow you to drive the line and interfere with the device. Which is exactly what this I2C recovery mechanism does, just that its pin controller is actually strict, will not allow the same line to be used for GPIO and some other function at the same time, so I suppose i.MX should probably explore the strict mode. Enabling that will sadly make the problem MORE complex for this I2C recovery, requiring a cycle of gpiod_put()/gpiod_get() to get it released from GPIO mode, i.e. we would need to just get the GPIO when this is strictly needed. Using devm_gpiod_get() and keeping a reference descriptor around would not work all of a sudden. I am thinking whether we can handle the non-strict controllers in a more elegant way, or add some API to explicitly hand over between device function and GPIO function. But I can't really see some obvious solution. Yours, Linus Walleij From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2A85C43603 for ; Mon, 9 Dec 2019 00:20:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73078206DB for ; Mon, 9 Dec 2019 00:20:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="c/q6rQYy"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="YJ2Z9d1L" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73078206DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LruXqF+PKBfS/6LTnHmemFVFM1yimturbpD07Hlwzwc=; b=c/q6rQYyQeq6e6 xVNTWkWWNsiW/m5qePA+ghIFdOWe3vsI+9zowjeFKp1Ojj/o46MJgpmJXQOoW5qu0HFaKIgQ4W9yX WmY7Olt46ah4v16fgesrLTdzdvktEJgEGUwqHkhmdaRj7icQKd8xWq+dJVSGv2XyFgVujgjUdVCS1 A+y82ckN2/P0CWV+TViztoF7YlkjpA8PsW2ptKUT4WN6KClbhGmdAuoet/KVOkXDYAh1Ntf3uoQUy ki+2TB9TjnrjjeXt4BcXps/GRvZ13BnMvAvLTdRkQjOyd4h7FiJdegrLu9PhkClmitXqBRba3JZbl PKlwWFFG83UQFWw7WtbA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ie6mu-0004r9-6j; Mon, 09 Dec 2019 00:20:32 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ie6mr-0004qZ-3M for linux-arm-kernel@lists.infradead.org; Mon, 09 Dec 2019 00:20:31 +0000 Received: by mail-lf1-x12b.google.com with SMTP id n12so9282546lfe.3 for ; Sun, 08 Dec 2019 16:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MHPwh1y/n4h6B3Kr1hQ3vt143Cypr4Zc4bxHvs1bL1s=; b=YJ2Z9d1LLO3HiNP5Cj86Xn9PhRPnCP461HYAfLOpE33VYg4X/b5RdZMTd5G8RTuLEx QcL1QGR9H3CYUKzsTz39bvQHbhtIt1XpuDyXeGSlBu4Mhw3gsH1mUAmUbFoJX5jOxC7m 4j2oYy6jJd7zrwoMAhPHfi20W3qlsFLgGZ2kLvaD+VU21KINczxmVb4OiITEOcWsPBZD bbdzjof/2gxGhZ/z0m6PXS0Fy7CLn/jNa0soMxwdUpbkfh4JMvOqyURODNZ16xDXqdhS FAk4OS0IEo8lvQLomW5Z4tV1tTGqQZKvOxFxlhpbQT9Of1ohFUmCpXXygdpESZeHVWz3 782Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MHPwh1y/n4h6B3Kr1hQ3vt143Cypr4Zc4bxHvs1bL1s=; b=BFOiAdVA7XZ/PngXYR/Pr+Zk13zGCF1dNmOPnqQTr8rX/KQReMMkpa0vFrNi4wH8KW EIgTeYjNq8/n3UzwFe4bgITUqWCra+NakytNMin5vsIgb/xNiV3grlgUPI4TllS6x7tv z6tB8ja8L5oeL10wYj80e1yA6ETkyGclZl/fPbY3AJfSlS5zfS5RFFXzj/u6klGtxrLi q7KYW7loJb/wbk01LoJb+puP9ZkWsMytRHaBs2lQNcOoK5DWORQ27yDGGlLEgmX4Guaf IRoObVe6/046f/hYKGsm4gtcvr/vC/CPemPuSp7aVfWkh91TjK2rAjNq92VihTHSwAAR D88w== X-Gm-Message-State: APjAAAWx0NIQTve3wanahxIoJN11ufY9N1cSQmx9SkT6411ef+VeIMHr yWnwoSIqVOJBMmAYoHuUTehl9I73iRZqfESDQKsKVA== X-Google-Smtp-Source: APXvYqz1ICQM0K1LHeR6QTf4gipjvIQPfKyB9dj3sza1iGU1uUKxJniITX2rtw2pCgEXg1z77JkTiIlU37yi9pqJWBA= X-Received: by 2002:ac2:4945:: with SMTP id o5mr13375016lfi.93.1575850826412; Sun, 08 Dec 2019 16:20:26 -0800 (PST) MIME-Version: 1.0 References: <20191206173343.GX25745@shell.armlinux.org.uk> In-Reply-To: <20191206173343.GX25745@shell.armlinux.org.uk> From: Linus Walleij Date: Mon, 9 Dec 2019 01:20:15 +0100 Message-ID: Subject: Re: pinctrl states vs pinmux vs gpio (i2c bus recovery) To: Russell King - ARM Linux admin X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191208_162029_348140_C013B6C9 X-CRM114-Status: GOOD ( 14.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:GPIO SUBSYSTEM" , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Russell, very nice description of this dual-mode problem. I wish I had a simple and elegant way we could make it unambiguous and simple to use ... but it beats me right now. On Fri, Dec 6, 2019 at 6:33 PM Russell King - ARM Linux admin wrote: > One may expect: > > pinctrl_select_state(i2c_imx->pinctrl, i2c_imx->pinctrl_pins_default); > > to change them back to the default state, but that would be incorrect. > The first thing that pinctrl_select_state() does is check whether > > p->state == state > > which it will do, as the pinctrl layer hasn't been informed of the > change that has happened behind its back at the pinmux level. Some pin controllers have the .strict property set in their struct pinmux_ops: * @strict: do not allow simultaneous use of the same pin for GPIO and another * function. Check both gpio_owner and mux_owner strictly before approving * the pin request. The non-strict pin controllers are those that actually allow GPIO and device functions to be used on the same physical line at the same time. In this case there is not special GPIO mode for the line in some muxing registers, they are just physically connected somehow. One usecase is sort of like how tcpdump work for ethernet interfaces: a GPIO register can "snoop" on a pin while in used by another device. But it would notably also allow you to drive the line and interfere with the device. Which is exactly what this I2C recovery mechanism does, just that its pin controller is actually strict, will not allow the same line to be used for GPIO and some other function at the same time, so I suppose i.MX should probably explore the strict mode. Enabling that will sadly make the problem MORE complex for this I2C recovery, requiring a cycle of gpiod_put()/gpiod_get() to get it released from GPIO mode, i.e. we would need to just get the GPIO when this is strictly needed. Using devm_gpiod_get() and keeping a reference descriptor around would not work all of a sudden. I am thinking whether we can handle the non-strict controllers in a more elegant way, or add some API to explicitly hand over between device function and GPIO function. But I can't really see some obvious solution. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel