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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 135B7C4338F for ; Tue, 3 Aug 2021 04:07:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC80061029 for ; Tue, 3 Aug 2021 04:07:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229753AbhHCEHl (ORCPT ); Tue, 3 Aug 2021 00:07:41 -0400 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]:50127 "EHLO wnew4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbhHCEHl (ORCPT ); Tue, 3 Aug 2021 00:07:41 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id E90DD2B0114E; Tue, 3 Aug 2021 00:07:29 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute2.internal (MEProxy); Tue, 03 Aug 2021 00:07:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=Ppnjgn9uT3nmuKcO7tOFj+ln9O4wmRR NvfgdBYB7dI8=; b=OKHYuR8QZZlGqTrvGubS+4e0MQo1R70rVcET9ytidu7sxph yJt4i/gOXrrca9QRlpLIr4NrWiEI+dNx6aWV9jbF+t1pifDlnWZWYwFWzq08FP6W JFnZJs+QcTR339vXltq9ATJN9WIS1nsQSOp+/2CVnsTDqxX14GwcVRVtjyw0y+7a MUZyOiTBN6/MpcHwhtwT4T8D14ZU3McUGXMZWwvr9A929IDxtdoUcu5aFh3A/B9E DD1EqRncPBaRp+nm9eevBS3dkRBzH2z0RcMm1rXrSaq7cEum+BYVbs2778qA9WWb CxNXl+f2uix6CeRXubuWw6FoDVLukJAbSkw47Qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ppnjgn 9uT3nmuKcO7tOFj+ln9O4wmRRNvfgdBYB7dI8=; b=eaIYKV3Y5GoVbgReKh+RM2 JGBu+L4Afj8EUiBJI3cDyRe3Jryb23kYKJMZRIJGkEfYaGy1jhvCaSaJKdwRAjps nC6lYM4h37UnmrhFIZJk67D1AtRO4xDJcmwbQcUZw98bbv6tSBap2Jhw9oZc3ndD jG843fceNArsjNPKqsa89HzJ6gujxDdjLYPRP7AH1RDlGBjH5FqbWvyLl9PaK/qx oa3tPvSvToJc/T+uj5LO+NKzgnvi22EKyGxMIKuhS+sA6OqGd/QtzXSIFYNbsNsY DCri3zyPwqWOw26Nl434ybU6EeX3LB+PgEWBj4jgmryZugkwrhvglX3/VipwmYDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieefgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnughr vgifucflvghffhgvrhihfdcuoegrnhgurhgvfiesrghjrdhiugdrrghuqeenucggtffrrg htthgvrhhnpeehhfefkefgkeduveehffehieehudejfeejveejfedugfefuedtuedvhefh veeuffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvfiesrghjrdhiugdrrghu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EEF55AC0DD0; Tue, 3 Aug 2021 00:07:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-548-g3a0b1fef7b-fm-20210802.001-g3a0b1fef Mime-Version: 1.0 Message-Id: <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> In-Reply-To: References: <20210723075858.376378-1-andrew@aj.id.au> <6cc64039-f82a-4c1e-ad2c-16fad7aa3178@www.fastmail.com> Date: Tue, 03 Aug 2021 13:37:07 +0930 From: "Andrew Jeffery" To: "Andy Shevchenko" Cc: "linux-leds@vger.kernel.org" , "linux-gpio@vger.kernel.org" , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , "Rob Herring" , "Joel Stanley" , "Pavel Machek" , "Linus Walleij" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/6] leds: Fix pca955x GPIO pin mappings Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote: > On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery wrote: > > On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > > > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery wrote: > > > > However, userspace would never have > > > > got the results it expected with the existing driver implementation, so > > > > I guess you could argue that no such (useful) userspace exists. Given > > > > that, we could adopt the strategy of always defining a gpiochip > > > > covering the whole pin space, and parts of the devicetree binding just > > > > become redundant. > > > > > > I'm lost now. GPIO has its own userspace ABI, how does it work right > > > now in application to this chip? > > > > As above, it "works" if the GPIOs specified in the devicetree are > > contiguous from line 0. It's broken if they're not. > > So, "it never works" means there is no bug. Now, what we need is to > keep the same enumeration scheme, but if you wish to be used half/half > (or any other ratio), the driver should do like the above mentioned > PWM, i.e. register entire space and depending on the requestor either > proceed with a line or mark it as BUSY. > > Ideally, looking into what the chip can do, this should be indeed > converted to some like pin control + PWM + LED + GPIO drivers. Then > the function in pin mux configuration can show what exactly is enabled > on the certain line(s). So just to clarify, you want both solutions here? 1. A gpiochip that covers the entire pin space 2. A pinmux implementation that manages pin allocation to the different drivers In that case we can largely leave this series as is? We only need to adjust how we configure the gpiochip by dropping the pin-mapping implementation? I don't have a need to implement a PWM driver for it right now but that would make sense to do at some point. Andrew 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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 E752EC432BE for ; Tue, 3 Aug 2021 04:09:21 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AE45161037 for ; Tue, 3 Aug 2021 04:09:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AE45161037 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=i/veAGshEeM+u09JW+NIoTkHu/u7p/hA1+7r1XMVb24=; b=IWMlARYfvXvy38 Fx/97G/EM4Iqxh/PYGsudupgHBlM3o5AVQwfJXptUnO7I4ytI/FIbtBPHn5APCGg4FMgaZBX7kCS/ 8CGDBcS6DyiBa0Fn1CTA7zHaNbwb4L7WVzdMloy0Z5aauLZZVqGxGraTsLCLntf3DXuPgrq2X9xR4 pC3I/t4X7p9zeiKEBtCtpNpZwMpfoDJS6qmX5Imm7NT4CYBCcjAs4FM82sb2dlJRtFAtvWVI/+5w6 0lACMOOfBbZyhuuWfwR1PhNeuTDkQ+KWPtE1aHZFbYZ0xZFDtGEZ2dV2Cw3XVIp6dG7B2VcZnBYoF v+8jMusRnsPXojJ5R21A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAliM-000ycU-LE; Tue, 03 Aug 2021 04:07:38 +0000 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAliI-000ybO-Sx for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 04:07:36 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id E90DD2B0114E; Tue, 3 Aug 2021 00:07:29 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute2.internal (MEProxy); Tue, 03 Aug 2021 00:07:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=Ppnjgn9uT3nmuKcO7tOFj+ln9O4wmRR NvfgdBYB7dI8=; b=OKHYuR8QZZlGqTrvGubS+4e0MQo1R70rVcET9ytidu7sxph yJt4i/gOXrrca9QRlpLIr4NrWiEI+dNx6aWV9jbF+t1pifDlnWZWYwFWzq08FP6W JFnZJs+QcTR339vXltq9ATJN9WIS1nsQSOp+/2CVnsTDqxX14GwcVRVtjyw0y+7a MUZyOiTBN6/MpcHwhtwT4T8D14ZU3McUGXMZWwvr9A929IDxtdoUcu5aFh3A/B9E DD1EqRncPBaRp+nm9eevBS3dkRBzH2z0RcMm1rXrSaq7cEum+BYVbs2778qA9WWb CxNXl+f2uix6CeRXubuWw6FoDVLukJAbSkw47Qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Ppnjgn 9uT3nmuKcO7tOFj+ln9O4wmRRNvfgdBYB7dI8=; b=eaIYKV3Y5GoVbgReKh+RM2 JGBu+L4Afj8EUiBJI3cDyRe3Jryb23kYKJMZRIJGkEfYaGy1jhvCaSaJKdwRAjps nC6lYM4h37UnmrhFIZJk67D1AtRO4xDJcmwbQcUZw98bbv6tSBap2Jhw9oZc3ndD jG843fceNArsjNPKqsa89HzJ6gujxDdjLYPRP7AH1RDlGBjH5FqbWvyLl9PaK/qx oa3tPvSvToJc/T+uj5LO+NKzgnvi22EKyGxMIKuhS+sA6OqGd/QtzXSIFYNbsNsY DCri3zyPwqWOw26Nl434ybU6EeX3LB+PgEWBj4jgmryZugkwrhvglX3/VipwmYDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrieefgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnughr vgifucflvghffhgvrhihfdcuoegrnhgurhgvfiesrghjrdhiugdrrghuqeenucggtffrrg htthgvrhhnpeehhfefkefgkeduveehffehieehudejfeejveejfedugfefuedtuedvhefh veeuffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grnhgurhgvfiesrghjrdhiugdrrghu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EEF55AC0DD0; Tue, 3 Aug 2021 00:07:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-548-g3a0b1fef7b-fm-20210802.001-g3a0b1fef Mime-Version: 1.0 Message-Id: <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> In-Reply-To: References: <20210723075858.376378-1-andrew@aj.id.au> <6cc64039-f82a-4c1e-ad2c-16fad7aa3178@www.fastmail.com> Date: Tue, 03 Aug 2021 13:37:07 +0930 From: "Andrew Jeffery" To: "Andy Shevchenko" Cc: "linux-leds@vger.kernel.org" , "linux-gpio@vger.kernel.org" , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , "Rob Herring" , "Joel Stanley" , "Pavel Machek" , "Linus Walleij" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/6] leds: Fix pca955x GPIO pin mappings X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210802_210734_986872_8A662EEE X-CRM114-Status: GOOD ( 24.17 ) 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 Thu, 29 Jul 2021, at 17:10, Andy Shevchenko wrote: > On Thu, Jul 29, 2021 at 3:39 AM Andrew Jeffery wrote: > > On Wed, 28 Jul 2021, at 18:43, Andy Shevchenko wrote: > > > On Wed, Jul 28, 2021 at 8:43 AM Andrew Jeffery wrote: > > > > However, userspace would never have > > > > got the results it expected with the existing driver implementation, so > > > > I guess you could argue that no such (useful) userspace exists. Given > > > > that, we could adopt the strategy of always defining a gpiochip > > > > covering the whole pin space, and parts of the devicetree binding just > > > > become redundant. > > > > > > I'm lost now. GPIO has its own userspace ABI, how does it work right > > > now in application to this chip? > > > > As above, it "works" if the GPIOs specified in the devicetree are > > contiguous from line 0. It's broken if they're not. > > So, "it never works" means there is no bug. Now, what we need is to > keep the same enumeration scheme, but if you wish to be used half/half > (or any other ratio), the driver should do like the above mentioned > PWM, i.e. register entire space and depending on the requestor either > proceed with a line or mark it as BUSY. > > Ideally, looking into what the chip can do, this should be indeed > converted to some like pin control + PWM + LED + GPIO drivers. Then > the function in pin mux configuration can show what exactly is enabled > on the certain line(s). So just to clarify, you want both solutions here? 1. A gpiochip that covers the entire pin space 2. A pinmux implementation that manages pin allocation to the different drivers In that case we can largely leave this series as is? We only need to adjust how we configure the gpiochip by dropping the pin-mapping implementation? I don't have a need to implement a PWM driver for it right now but that would make sense to do at some point. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel