Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3247721imm; Fri, 20 Jul 2018 12:49:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd5eNaNSUFXzxMM247dHGKtgki8zFtbWzyaLLSaM6lHRwLxmlAwtL7z0szoSHQlwImKrxcY X-Received: by 2002:a63:a919:: with SMTP id u25-v6mr3366761pge.211.1532116153453; Fri, 20 Jul 2018 12:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532116153; cv=none; d=google.com; s=arc-20160816; b=vjiG1IBmG/AbIHfnNac20GTKdPVTRZi+QZb9jlpLPVNIT0/+lVAOkrq7IoxCEo9iZH 4PTwq8pNvRDhk1emNKRiSZFV9y47HT1Tsz9BbiBA0pD4drwKJaKu5hwcpKwk2xaLr9zK R8AQ0gM3ZVk1w0lt6HpIuQn+Vqw6xzbMisEEO7V9+j90ZsDTd+0Ke0WKfon1iTccBQ6s gNTWbI5Lf/HU9QksXh8M4kUuxvLYbzZkyFzKqtO4FCb/rs7LIb4jCpTVIx1eUadbW7vQ nZTxgt8SEZA631yPtrkh5LfYB6klys0S/078qNbeZWT3Iwyz3IZjYY7WYJ+lxVJk5y32 Fv+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=6Ds1YBTvr3FDkugvOgcV7PA9/zsDwk5W1XgzVyA9NWU=; b=tFAwk8rNJSLc2K5pUVKY9ccs6vXf9pIkLqXt8dQ/WvpsSlGETZQ3oOerZijtqzueDL fNIRtlZkDEq1fiO1yYx10nl2uqNcXWBs/DEgtZOws2UK3DkwIFjXI1EeZpBhhsi5kt0Z dd4w633kZcns/YXl4fhotkM750etA9AHZb5ak8sCwGAFuZx+VCO/wFcyF8Lmpzk4td8V 3KqVXnKtLo0UdJwWE5FPwcU/1ORZNeqGbeh4hd38rGbrrvaCSh2iIyW2k4hBN8jwGN37 RWUlI/oZyNbwLUITbNz0TElmDYhiRnPo7O7EnnGRvemjbgnBvwkLPQqgp3QFPX+OoabQ +nhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9-v6si2335631pla.59.2018.07.20.12.48.58; Fri, 20 Jul 2018 12:49:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727812AbeGTUiJ (ORCPT + 99 others); Fri, 20 Jul 2018 16:38:09 -0400 Received: from mail.bootlin.com ([62.4.15.54]:35120 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727571AbeGTUiJ (ORCPT ); Fri, 20 Jul 2018 16:38:09 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id A4A5020733; Fri, 20 Jul 2018 21:48:22 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (unknown [37.173.220.171]) by mail.bootlin.com (Postfix) with ESMTPSA id 16A7A206D8; Fri, 20 Jul 2018 21:48:11 +0200 (CEST) Date: Fri, 20 Jul 2018 21:48:08 +0200 From: Boris Brezillon To: Janusz Krzysztofik Cc: Miquel Raynal , Tony Lindgren , Aaro Koskinen , Grygorii Strashko , Santosh Shilimkar , Kevin Hilman , Linus Walleij , Richard Weinberger , David Woodhouse , Brian Norris , Marek Vasut , linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Artem Bityutskiy Subject: Re: [RFC PATCH 8/8] mtd: rawnand: ams-delta: Use GPIO callbacks for data I/O Message-ID: <20180720214808.0c19234e@bbrezillon> In-Reply-To: <2165137.iTHcPHRtIn@z50> References: <20180718235710.18242-1-jmkrzyszt@gmail.com> <20180718235710.18242-9-jmkrzyszt@gmail.com> <20180719084749.25ca96a6@bbrezillon> <2165137.iTHcPHRtIn@z50> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Janusz, On Fri, 20 Jul 2018 20:38:15 +0200 Janusz Krzysztofik wrote: > On Thursday, July 19, 2018 8:47:49 AM CEST Boris Brezillon wrote: > > On Thu, 19 Jul 2018 01:57:10 +0200 > > Janusz Krzysztofik wrote: > > > > > Don't readw()/writew() data directly from/to GPIO port which is under > > > control of gpio-omap driver, use GPIO chip callbacks instead. > > > > > > Thanks to utilization of get/set_multiple() callbacks, performance > > > degrade is minor for typical data transfers. > > > > Same comment here, don't use the gpio_chip hooks directly, use the > > consumer API instead. > > I tired but performance was not acceptable. You tried to use gpiod_{get,set}_array_value(), right? Did you investigate on where the overhead comes from? > > I see your point but please understand, what I'm trying to do here is not to > develop a shiny general purpose fully GPIO based NAND driver, I'm trying to > resolve issues with NAND driver for Amstrad Delta I like to play with, without > loosing much performance. That's not a reason to violate the consumer/driver separation provided by the GPIO framework. I'm not saying the current consumer APIs are good enough for what you want to do (bit-bang a parallel data bus in an efficient way), but bypassing the GPIO core like you do is definitely not a good thing. Maybe you should discuss with Linus the possibility of introducing a gpio_bitbang API that would provide you some guarantees on the access time by making sure the pins all belong to the same bank (and can thus be accessed in an atomic way). And maybe provide a way to read/write several bytes by defining a delay between each access, the size of the bus and the control pin if any (in our case NRE/NWE). > > I'm going to reconsider all possible options, not only doing data I/O over > GPIO inside the driver, to have the task completed. Once done, I can get > back to the GPIO based code I developed so far and create a new generic driver > as my free time permits, or anyone can do that if needed, the code is open > source after all. Let's forget the generic nand-gpio driver for now. All I'm asking is that you do not bypass the GPIO framework like you intend do in this patch. Regards, Boris