Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1293542ybk; Sun, 10 May 2020 12:10:08 -0700 (PDT) X-Google-Smtp-Source: APiQypJ2advSEGA9X2GoXEEd2u3XuG53O0280SSJ1tUQuMPpiIE17jlKqII2XTO+AoqvlgfVrbn+ X-Received: by 2002:a17:906:d8b4:: with SMTP id qc20mr10323519ejb.253.1589137808511; Sun, 10 May 2020 12:10:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589137808; cv=none; d=google.com; s=arc-20160816; b=xdF0vb0seXSHKscI5CPMAnGQS3GndfxuweCE8HKmC7IQouZ1Fd5vHcdvfJN+d/jdCA 8cByJxbic2nuzFXx0D9oyb3T3iMWZnynil9TgMmUGl+0ijmQMQ40pmzLOpugKGZIlNoG DNnvAT+wdSzsxlkJNmMts7Xa7eEoPrcWW3LI5CMAovw5thLUGHJjPidr+EDTR2ZeMBVZ Xe2i9Ihb0moqUOYqpZIuV1g+tLBw424H2RM5hPV9+W18JANaPw2ZNZyEl+HyJnofc9C4 yYJ4CQm5rhGDTnsAERbPHZXkVE/Xmxqr2bm92TaeCIIOtMdlbjIRQm8qs3IXwd/LsbYg F0Ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TrDysAnyzIqn5Cn1iMOx1jHu5Zp3yUHwKX37t/G/0oo=; b=wupk9TKphyMN31gDNMWO7DiFE8I4+jO+ojTB4h1vu+bOBdCOaEbnR3ys1TUu6/pZHg zTn9AuWvY5+X0//Z0U5+a/EmMJTMjeOLWMcftAYMXWw/0jodC9Z1kD7ubahgkefwTQ9W Mlopg1hKvJXUGvHZ313nz09pDVcu04NIT/0P1HB4wecYAdxKl8qGtOg8U4LuyzZav3Jf bZrPpobKQdZex4d4rW5iVtASKadetKHnOp/UkMEGkt6z7dpaPPtiQjOnJNmQjHVINpVt 5MDNITk5TnIfL7ib2ogfTpy7OBdpKYGxbKTj7xQn+yLjit8LSRu82d3chc2vV9dGi9wX B8kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Tusd/kAI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e22si4696883eje.203.2020.05.10.12.09.44; Sun, 10 May 2020 12:10:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Tusd/kAI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729225AbgEJTFv (ORCPT + 99 others); Sun, 10 May 2020 15:05:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728385AbgEJTFu (ORCPT ); Sun, 10 May 2020 15:05:50 -0400 Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4567C061A0C; Sun, 10 May 2020 12:05:50 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id d22so3495231pgk.3; Sun, 10 May 2020 12:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TrDysAnyzIqn5Cn1iMOx1jHu5Zp3yUHwKX37t/G/0oo=; b=Tusd/kAIJ93DCgBlGio6JGtGTJMloGM3X+oLDhyeqDPqSqCXLICnX9B8HMn/Jd0Tik +k7rp+0JfNDOaOh23t8jMPC6KRZz/xaa8oDPLQ+uXPvlcS1bGZ1DLNaxEcN5K35fNAUQ K4+XmSRSvOCSjx8VciY3xSCCEOJy8x4ot1c6rf6Kzelxqy31GZ+6vunnB01XxySlLljG nKgOxJLV8Qb0HRTMNhZNqOejR93rP3pryODWevJvGCthrkNvR2P1xPBlvkfvmDyxSxTH wJlGEMaTgD4KvDzqEGV1cq7HxVl6HOFnLM2W1f9zS4HlohudcR0q29xfWtlTGa7bPjpw Je0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TrDysAnyzIqn5Cn1iMOx1jHu5Zp3yUHwKX37t/G/0oo=; b=nU3K3FfvENJIKEtD5yCrNbaiuNwQbD91+pmL60KA3Kz6h6+pohF9PfK3yrhVifU8LA W7AAgVwMgBp/2MMqZE2vq5nMuZ0+6OjwO2bGoAmqXtrMc0PolQwXdlwORb6nvU4bIiMz kGp10xYT+YDmZbMtJoxuXQ2aJSFErjHLpoEkesjnyK9ipabcFdM8LKLglOrq22MpVpup WA1128OOgT0MVCWgCCVOBzIvo1Ugr4lOAuZwzFfbghSbMO01wBo2rGS4KzvMDjG+C5LW mX+yvpOX+g6n1ZpvDNMdLi0497Qxhr+BHq4ABwuAzK9tylffTogQW+4DWsaREJwOd0m5 hcSw== X-Gm-Message-State: AGi0PuZncimxjfZ58V9lpjl7wxFboiksifoxXxSDedQErzw2tXLPuw7D pJYaZWDaMi18vK1P2cZGgRpakmF1V15WTn3Modw= X-Received: by 2002:a65:6251:: with SMTP id q17mr11271737pgv.4.1589137550161; Sun, 10 May 2020 12:05:50 -0700 (PDT) MIME-Version: 1.0 References: <20200504114109.GE185537@smile.fi.intel.com> <20200504143638.GA4635@shinobu> <20200505145250.GA5979@shinobu> In-Reply-To: From: Andy Shevchenko Date: Sun, 10 May 2020 22:05:38 +0300 Message-ID: Subject: Re: [PATCH v5 0/4] Introduce the for_each_set_clump macro To: Syed Nayyar Waris Cc: William Breathitt Gray , Linus Walleij , Bartosz Golaszewski , Michal Simek , Andy Shevchenko , Andrew Morton , Arnd Bergmann , rrichter@marvell.com, Masahiro Yamada , "Zhang, Rui" , Daniel Lezcano , Amit Kucheria , Linux-Arch , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , linux-arm Mailing List , Linux PM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 9, 2020 at 7:36 PM Syed Nayyar Waris wrote: > On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray > wrote: > > On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote: > > > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray > > > wrote: > > > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote: > > > > > On Sun, May 03, 2020 at 04:38:36AM +0530, Syed Nayyar Waris wrote: ... > > > > > Looking into the last patches where we have examples I still do not see a > > > > > benefit of variadic clump sizes. power of 2 sizes would make sense (and be > > > > > optimized accordingly (64-bit, 32-bit). > > > > There is of course benefit in defining for_each_set_clump with clump > > > > sizes of powers of 2 (we can optimize for 32 and 64 bit sizes and avoid > > > > boundary checks that we know will not occur), but at the very least the > > > > variable size bitmap_set_value and bitmap_get_value provide significant > > > > benefit for the readability of the gpio-xilinx code: > > > > > > > > bitmap_set_value(old, state[0], 0, width[0]); > > > > bitmap_set_value(old, state[1], width[0], width[1]); > > > > ... > > > > state[0] = bitmap_get_value(new, 0, width[0]); > > > > state[1] = bitmap_get_value(new, width[0], width[1]); > > > > > > > > These lines are simple and clear to read: we know immediately what they > > > > do. But if we did not have bitmap_set_value/bitmap_get_value, we'd have > > > > to use several bitwise operations for each line; the obfuscation of the > > > > code would be an obvious hinderance here. > > > > > > Do I understand correctly that width[0] and width[1] may not be power > > > of two and it's actually the case? > > I'm under the impression that width[0] and width[1] are arbitrarily > > chosen by the user and could be any integer. I have never used this > > hardware so I'm hoping one of the gpio-xilinx or GPIO subsystem > > maintainers in this thread will respond with some guidance. > > > > If the values of width[0] and width[1] are restricted to powers of 2, > > then I agree that there is no need for generic bitmap_set_value and > > bitmap_get_value functions and we can instead use more optimized power > > of 2 versions. > Regarding the question that whether width[0] and width[1] can have any > value or they are restricted to power-of-2. > > Referring to the document (This xilinx GPIO IP was mentioned in the > gpio-xilinx.c file): > https://www.xilinx.com/support/documentation/ip_documentation/axi_gpio/v2_0/pg144-axi-gpio.pdf > > On page 8, we can see that the GPIO widths for the 2 channels can have > values different from power-of-2.For example: 5, 15 etc. > > So, I think we should keep the 'for_each_set_clump', > 'bitmap_get_value' and 'bitmap_set_value' as completely generic. > > I am proceeding further for my next patchset submission keeping above > findings in mind. If you guys think something else or would like to > add something, let me know. Thank you for investigation. So, if Xilinx is okay with the change, I have no objections. -- With Best Regards, Andy Shevchenko