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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B7984E80AA6 for ; Wed, 27 Sep 2023 13:50:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UrUT9eUOAOCrSBV1OcgZbzg0lFD3VdqMyIgJVWp5akE=; b=cybgUc4NeMjB80 xkc9gjXZLoSD5hkEyJ1o4vk2nwdkCK9KGRKN0MTmNZ68gc3/qyPlTGcAs4HYLL6Zy/RTxAxwXf2d2 UoiqJTyhdFQlILKKlO1acJEJo223tgrFfw2LY7pBZspjoPmkzX7xwn+IpD6nWqwHjJfP+vdfRjyqX SxqGvz5nViCv6Ix/x2PRV35Uj6IT4vz7wav+ii9dQf0AbsCcTnpuTjHmhEL9VaBCJp9tIyA/HBqC3 EmtXeBDk/G/nylYhvCWXYkPfHa8AYQKv8B9blHCpB8/vLOzrFfuyAnyVcXkzyt/WOqH+yhXK5IZdf 12pRvPceL0jPZJkjMU1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qlUvE-00138D-2e; Wed, 27 Sep 2023 13:49:48 +0000 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlUvB-00137V-2y for linux-arm-kernel@lists.infradead.org; Wed, 27 Sep 2023 13:49:47 +0000 Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-690b7cb71aeso8482849b3a.0 for ; Wed, 27 Sep 2023 06:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695822583; x=1696427383; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3Aw5E5IBdNowjjS4PH7xoOgoqlu9/7i3Bf6Q6v3vpo4=; b=KpcbqSDhtasznvCh9yFm1AaQrI/4Veh1h1QY2uNYObB94a9yYGHGCZThCoIEFOPU/8 syB+/sGLzSZ0Cs6Ww9nW/RnFHkxl0wRkhXGLDpsiivTLR2M6pkG91yTksSdzwwf7ioPS HEAvz+4jNcKHMppiTcQmzZUmNCaTeDflouppJph6Shi8mDU5SbV1ia5hRSdfLdY8xsXQ 9chFzhTffw9UyFsiVV6/JV+qiu59i7Wsr4vQjKZWGtK+r+RkOsBwaGbc9NpNJ5cc3ofc 588RLKeLzI/Y6zolxjxavIARlNlA3wDE/WvT6tW3NZgzxQ2m/Tgukja72/bVvwRFyqDw +CIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695822583; x=1696427383; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3Aw5E5IBdNowjjS4PH7xoOgoqlu9/7i3Bf6Q6v3vpo4=; b=bQnBmL2vHpsME/6UbdsN8FqaserBUnPXBCrzbOQ6bLAgkel0PvddljFYLUMX9GBsFU NwF34JXexiYcMTr9H9Z5hN0fBjPxFBfS7sYezDK+kGFT33xyL+f1czjLhLFtkM/5AWLX mn8vtulks8n0aWASmoogQpzNwDfc4GyEROiGPlpuF5aLW56VyA/0AYPC5v71J6Zv2AE1 GN3yON9SI0rvFfjc39S+FYajcutWwOazamC1XXl6PK0NIKQjMYDJnPTBbUCxMMdb5Cq0 7lKJf4jNInQ5KwqUgbI3B33tIo2pY6y4jB2i1s6tK45bMrvgBInZUbMRb3Iec9lEAsLU 4ugw== X-Gm-Message-State: AOJu0Yzg7vMZlhTpkk+tkj1wkpbGkYU/nG9ZW0Qme62pf1YCm6ISiQUX ejlsA1INJDrf9uO50TwU1wA= X-Google-Smtp-Source: AGHT+IG/evsQgn7DeYX5iik16MARw8RfmoTuwvd81Rkjd5uGTbhh8UnGs20mcGZ5gNA/VOOeDNWxgg== X-Received: by 2002:a05:6a20:734e:b0:13e:90aa:8c8b with SMTP id v14-20020a056a20734e00b0013e90aa8c8bmr3270011pzc.4.1695822583550; Wed, 27 Sep 2023 06:49:43 -0700 (PDT) Received: from sol ([118.209.204.34]) by smtp.gmail.com with ESMTPSA id c16-20020aa781d0000000b00686edf28c22sm11779046pfn.87.2023.09.27.06.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Sep 2023 06:49:43 -0700 (PDT) Date: Wed, 27 Sep 2023 21:49:35 +0800 From: Kent Gibson To: Andy Shevchenko Cc: Linus Walleij , Bartosz Golaszewski , Yury Norov , linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Shubhrajyoti Datta , Srinivas Neeli , Michal Simek , Bartosz Golaszewski , Rasmus Villemoes , Marek =?iso-8859-1?Q?Beh=FAn?= Subject: Re: [PATCH v1 5/5] gpiolib: cdev: Utilize more bitmap APIs Message-ID: References: <20230926052007.3917389-1-andriy.shevchenko@linux.intel.com> <20230926052007.3917389-6-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230927_064945_963066_8CF261D8 X-CRM114-Status: GOOD ( 35.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 27, 2023 at 03:17:06PM +0300, Andy Shevchenko wrote: > On Wed, Sep 27, 2023 at 09:32:11AM +0800, Kent Gibson wrote: > > On Tue, Sep 26, 2023 at 08:20:07AM +0300, Andy Shevchenko wrote: > > > Currently we have a few bitmap calls that are open coded in the library > > > module. Let's convert them to use generic bitmap APIs instead. > > > > Firstly, I didn't consider using the bitmap module here as, in my mind at > > least, that is intended for bitmaps wider than 64 bits, or with variable > > width. In this case the bitmap is fixed at 64 bits, so bitops seemed more > > appropriate. > > > > And I would argue that they aren't "open coded" - they are parallelized > > to reduce the number of passes over the bitmap. > > This change serialises them, e.g. the get used to require 2 passes over > > the bitmap, it now requires 3 or 4. The set used to require 1 and now > > requires 2. > > And there are additional copies that the original doesn't require. > > So your change looks less efficient to me - unless there is direct > > hardware support for bitmap ops?? > > > > Wrt the argument that the serialized form is clearer and more > > maintainable, optimised code is frequently more cryptic - as noted in > > bitmap.c itself, and this code has remained unchanged since it was merged > > 3 years ago, so the only maintenance it has required is to be more > > maintainable?? Ok then. > > > > Your patch is functionally equivalent and pass my uAPI tests, so > > > > Tested-by: Kent Gibson > > Thanks for testing! > Not a problem - that is what test suites are for. > > but my preference is to leave it as is. > > As Yury mentioned we need to look at bitmap APIs and make them possible to have > a compile-time optimizations. With that in mind, I would prefer bitmap APIs > over open-coded stuff which is hardly to be understood (yes, I still point > out that it takes a few hours to me, maybe because I'm stupid enough, to > get what's the heck is going one there, esp. for the == 1 case). > Really? With all the bits out in the open it seems pretty clear to me. Clearer than scatter/gather in fact. Sure, if there is suitable hardware support then bitmaps COULD be faster than bitops. But without that, and that is the general case, it will be slower. Do you have ANY cases where your implementation is currently faster? Then you would have a stronger case. And if you find the existing implementation unclear then the appropriate solution is to better document it, as bitmaps itself does, not replace it with something simpler and slower. > Yet, it opens a way to scale this in case we might have v3 ABI that let's say > allows to work with 512 GPIOs at a time. With your code it will be much harder > to achieve and see what you wrote about maintenance (in that case). > v3 ABI?? libgpiod v2 is barely out the door! Do you have any cases where 64 lines per request is limiting? If that sort of speculation isn't premature optimisation then I don't know what is. Cheers, Kent. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel