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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 43359C46470 for ; Tue, 7 Aug 2018 17:47:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F148B215F9 for ; Tue, 7 Aug 2018 17:47:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F148B215F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403833AbeHGUDB (ORCPT ); Tue, 7 Aug 2018 16:03:01 -0400 Received: from mail.bootlin.com ([62.4.15.54]:38027 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403794AbeHGUDA (ORCPT ); Tue, 7 Aug 2018 16:03:00 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 09405207AB; Tue, 7 Aug 2018 19:47:32 +0200 (CEST) Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 8ED7420737; Tue, 7 Aug 2018 19:47:21 +0200 (CEST) Date: Tue, 7 Aug 2018 19:47:22 +0200 From: Boris Brezillon To: Janusz Krzysztofik Cc: Linus Walleij , Jonathan Corbet , =?UTF-8?B?TWlxdcOobA==?= Raynal , Richard Weinberger , David Woodhouse , Brian Norris , Mark Vasut , ext Tony Lindgren , Aaro Koskinen , Linux ARM , Linux-OMAP , linux-mtd@lists.infradead.org, linux-doc@vger.kernel.org, "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions Message-ID: <20180807194722.5aabb6da@bbrezillon> In-Reply-To: <11711552.OvaP4pOjBH@z50> References: <20180718235710.18242-1-jmkrzyszt@gmail.com> <20180806222918.12644-13-jmkrzyszt@gmail.com> <11711552.OvaP4pOjBH@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 Hi Janusz, On Tue, 07 Aug 2018 19:29:53 +0200 Janusz Krzysztofik wrote: > On Tuesday, August 7, 2018 1:43:56 AM CEST Linus Walleij wrote: > > On Tue, Aug 7, 2018 at 12:29 AM Janusz Krzysztofik > wrote: > > > > Hi Janusz! > > > > > Certain GPIO descriptor arrays returned by gpio_get_array() may contain > > > information on a single GPIO chip driving array member pins in hardware > > > order. In such cases, bitmaps of values can be passed directly to the > > > chip callback functions without wasting time on iterations. > > > > > > Add respective code to gpiod_get/set_array_bitmap_complex() functions. > > > > > > Signed-off-by: Janusz Krzysztofik > > > > I think it would be disappointing to leave all the users of the old > > array API without the performance improvement. I think we need to > > deal with this in a way such that everyone can benefit from it. I agree with Linus on that one. When I initially proposed the gpio bitbanging API I had something more advanced in mind where the GPIO framework would be responsible for toggling the GPIOs on its own when it's given an array of bytes to transmit (this way you avoid going back and forth between the GPIO user and the GPIO framework). But this approach would clearly be more invasive than what you propose here (turning the int array into a bitmap and optimizing). So, if we go for the "int array -> bitmap" approach I think all users should be converted so that we end up with a single API. > > There are a few issues to be resolved: > > 1) array size limited by bitmap size: > - are we ready to limit array size to a single bitmap for all users? > - if not, how can we pass a bitmap of an arbitrary size? > - if as an array of bitmaps, is that still clear enough and easy to use? > - other ideas? What we call a bitmap is an array of unsigned longs each entry containing NBITS_PER_LONG bits, so yes, it's an arbitrary size (see the bitmap API here [1]). > > 2) arbitrary array support: > - are we ready to drop that? > - if not, do we agree to require all users to pack their arbitrary arrays > inside the gpio_descs structure? I could only find one user, and it's the core itself (for the ioctl), so that shouldn't be too hard to convert all users. Did you find more. > > Maybe more. > > > Also it is kludgy if users (consumers) would need to handle the case > > where all lines are on the same chip separately, through the bitmap > > API. > > Not true as long as array size fits (arbitrary arrays can be packed by users), > but I see your point. I think the API should be the same and the framework should decide to take the fast path if all gpios belong to the same chip (which AFAICT is already the case, except it's putting the result in an int array instead of a bitmap) > > > What we need is an API that: > > > > - All drivers handling arrays can use (including current users). > > > > - Enables speed-up if the lines are all on the same chip/register. > > > > - Doesn't require consumers to know if they are all on the same > > chip or not. > > > > This means a deep API with a small surface. > > > > How do we achieve this the best way? > > I think widely accepted solutions to those two issues I've mentioned above can > give the answer. I'd still like to see how far we are from the initial perfs (the one poking the GPIO regs directly) with this approach, and what's the improvement compared to the int array solution we already have in place. Regards, Boris [1]https://elixir.bootlin.com/linux/v4.18-rc8/source/include/linux/bitmap.h