From nobody Thu Sep 23 07:18:21 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 B417E17C3D7B for ; Thu, 23 Sep 2021 07:18:35 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HFRN90RnJz3Ggc; Thu, 23 Sep 2021 07:18:32 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1632381504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wO3zMNuiaPPTrn8X+OxXYU8E9yYzhLGEhE9k5fX6mhM=; b=fpIilzlcE590Z9ZZmgYLq0jEMitIwtFMDwJVmNwJx/a4HTwi8JC9oF7TiHXmgxZCvJbwCP 3QNLwaVkpNwamyxSnajChdm0Lu9IopA+ozB5Ej04TsQ2X3m5SvGG83dCd51fXAmzTQUtfa TlmIHnOC/eppSezjIvaoGRpU4vu7Fkc= Received: from skull.home.blih.net (lfbn-idf2-1-644-191.w86-247.abo.wanadoo.fr [86.247.100.191]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 1eb990de (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 23 Sep 2021 07:18:24 +0000 (UTC) Date: Thu, 23 Sep 2021 09:18:21 +0200 From: Emmanuel Vadot To: Andriy Gapon Cc: arm@FreeBSD.org, Emmanuel Vadot Subject: Re: rk_gpio: high latency switching between input / output Message-Id: <20210923091821.dd92732fa44d30f94a9415b1@bidouilliste.com> In-Reply-To: <4472ded5-1815-e7c0-0238-efd6935062e0@FreeBSD.org> References: <4472ded5-1815-e7c0-0238-efd6935062e0@FreeBSD.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.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=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HFRN90RnJz3Ggc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=fpIilzlc; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Andriy, On Sat, 18 Sep 2021 11:34:05 +0300 Andriy Gapon wrote: > > 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 > I've made some tests on my rock64 board. The program I used [1] is, I think, the worst possible scenario that can happen as it : - Set the pin to output - Toggle the pin - Set the pin to input - Read the pin - Set the pin to output With it I get a ~30khz signal produced on the pin. I did some change to rk_gpio [2], those changes are : - Cache the pin info (gpio or not) and flags (pullup/pulldown) - Remove useless reads for the pin direction and value when we're setting or toggling the pin (so output mode only). With this and the same program I manage to have a ~50khz signal output on the pin. I'm not sure I can get higher result for now. All test where done on main (c96da199458) with GENERIC kernel. Obviously you will have better result for kernel operation but I choose to do userland to have the worst case possible. Let me know if this helps you in your case, otherwise I'll hookup some 1wire temp sensors and try to make them work while the scope is still plugged on the board. Cheers, 1: https://people.freebsd.org/~manu/rk_gpio/gpio_test.c 2: https://people.freebsd.org/~manu/rk_gpio/0001-arm64-rockchip-rk_gpio-Improve-mode-switching.patch -- Emmanuel Vadot