From nobody Sat Sep 18 08:34:05 2021 X-Original-To: arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8227317CEBE3 for ; Sat, 18 Sep 2021 08:34:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HBPHh3N5Cz4gTF; Sat, 18 Sep 2021 08:34:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id F3AAA25DB3; Sat, 18 Sep 2021 08:34:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: arm@FreeBSD.org From: Andriy Gapon Cc: Emmanuel Vadot Subject: rk_gpio: high latency switching between input / output Message-ID: <4472ded5-1815-e7c0-0238-efd6935062e0@FreeBSD.org> Date: Sat, 18 Sep 2021 11:34:05 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N I noticed that rk_gpio has a rather high overhead when switching between input and output modes on a pin. This is typically required for software I2C (bit banging) and 1-wire protocols. The overhead is so bad that 1-wire in particular is very unreliable, barely working. It seems that a lot of that overhead in rk_gpio_pin_setflags() comes from FDT_PINCTRL_IS_GPIO() and FDT_PINCTRL_SET_FLAGS(). It's easy to shave off the latter as the call is not necessary when only GPIO_PIN_INPUT and GPIO_PIN_OUTPUT flags are changing. Not sure what can be done about FDT_PINCTRL_IS_GPIO(). On the one hand it's nice to have that sanity check, on the other hand it adds the overhead. Also, it might be racy as there is no common lock for gpio and pinctrl. Anyway, perhaps the overhead could be reduced if rk_pinctrl cached pin configurations instead of retrieving and re-parsing them every time like rk_pinctrl_is_gpio_locked() does. -- Andriy Gapon