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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 3A59BC43214 for ; Tue, 3 Aug 2021 10:34:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 211DA61053 for ; Tue, 3 Aug 2021 10:34:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234904AbhHCKeu (ORCPT ); Tue, 3 Aug 2021 06:34:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235458AbhHCKef (ORCPT ); Tue, 3 Aug 2021 06:34:35 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2AC7C06179A; Tue, 3 Aug 2021 03:34:14 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id t3so21046581plg.9; Tue, 03 Aug 2021 03:34:14 -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=gUlOdJ9XQT6Y1TLMVY7TvS0f9TdTpUJkbcu/euswTpI=; b=OVGAJCGQgKOfrQtMQ+7oLZn99a1NlqUPMTDYPgr7T9jc92sQG/9KI8DH0WfHC+/HiE saufWO4B0WzYKSYqksSWu5YnTe0LBW0kDJG9cc9cXJ55JMOlW9mgc4HxYDnFNTlQbkNi dBCm1uqNi8kfufYnmAyNtGBKzB9qBGA+SXDKn2X/Ls7CFl3F4qAgWj1dHnIg9DuDIKu1 XEiufcn580Usz96z7gH9cW2vzLamg9tdNJBtiaW53Y6zaR9eHIu57raRdPDmSznS52Z+ NMe474lh61Fc5mMDSo8gM3x4Ba348w+2PlOZdMX8DqlG0DGtqigoyUobasMWjUkAuD/D qWAQ== 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=gUlOdJ9XQT6Y1TLMVY7TvS0f9TdTpUJkbcu/euswTpI=; b=HOvztEg2mw+FYBdNU/Rb2N3bSx5Icvr9Gk1iFiMtbok4SWNWYRuGSOnDa1solXHOVC YMLQxNqDuOLdGr3TaOnND01pqFZqYsdXqjuoTPNao3FZh0Ai7WBfSaBaiNq9jCk6zz41 e9KqLnMQ8D8EsZl/tBLFhXyoXjb+JWWv27xcsEd6xWFpsZOMfttzfHfwgUG/XSrkAjgL 3BrL+0h35v0PoMKFptIbEQkUgcYbtd3dQVYVl2lmUc+gtfklA63WVPzZbcDs9M874lWD +LSS++Ke7g/ZvRYb3e0raUKtMu2IS5JhPquBbJBUnI1MBEvWEcn0yGBUHrhog0ol2kWA 2jJg== X-Gm-Message-State: AOAM532GSaCFeK8MnzsFRGI/IjTfSS4qSDCJczChZG69Sx35Ty5MNRNF 5Z10abpSLjTpNGhj5rOjR4TcSwQQUHu6Ihtf7ly3tSlN50YfGw== X-Google-Smtp-Source: ABdhPJy8/GLzJXE0Sbq4RzvQ2nMWzsr/B9cP3HzwsDbrXs4gyEVrA0uvccH3J3UGBLIYJ9viNfcDuohGBOr5NXxaViI= X-Received: by 2002:a17:902:b713:b029:12b:b249:693f with SMTP id d19-20020a170902b713b029012bb249693fmr1633411pls.17.1627986854331; Tue, 03 Aug 2021 03:34:14 -0700 (PDT) MIME-Version: 1.0 References: <20210723075858.376378-1-andrew@aj.id.au> <6cc64039-f82a-4c1e-ad2c-16fad7aa3178@www.fastmail.com> <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> In-Reply-To: <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> From: Andy Shevchenko Date: Tue, 3 Aug 2021 13:33:38 +0300 Message-ID: Subject: Re: [RFC PATCH 0/6] leds: Fix pca955x GPIO pin mappings To: Andrew Jeffery 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" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Tue, Aug 3, 2021 at 7:07 AM Andrew Jeffery wrote: > 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? Nope. It's far from what I think of. Re-reading again your cover letter it points out that pin mux per se does not exist in the hardware. In this case things become a bit too complicated, but we still may manage to handle them. Before I was thinking about this hierarchy 1. pinmux driver (which is actually the main driver here) 2. LED driver (using regmap API) 3. GPIO driver (via gpio-regmap) 4. PWM driver. Now what we need here is some kind of "virtual" pinmux. Do I understand correctly? To be clear: I do not like putting everything into one driver when the logical parts may be separated. -- With Best Regards, Andy Shevchenko 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=-0.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 B64D2C4338F for ; Tue, 3 Aug 2021 10:37:54 +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 81E7A600D4 for ; Tue, 3 Aug 2021 10:37:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 81E7A600D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fHPJtfB8B7QS20qqtFe6QMQwPEiM7q5a3tCFgorXggU=; b=YnQzoU44lDjVjj AeY13O4d5JShSswLtJ3yAQEhboZ8Jx1aC5squ6XMRp4GhqCzDPJHwePzcAaZQfTHyI1boChsl2lVx KIaKyWHjSU3dQTjHxjvW+wPQQ1xRb6wL5AipAaFv1K8d7IDaI26vhGQcv9RmETsNTwR/7PrK+aFKP AygM8IXZAjkgtarTqhzmAULefDwBqy5Vv04RPTDEbK0pkBYAlwIcMlZV31QUgY91JOMYxkrAyBF0H 1jOt9ZGnVF/qktCedOcMlsxXFyfAl4+QLuVgNcCcg464pg9W7pHylfC1N/unH8HOrMHhtrzdDv+Tq p++MK9pPIGvX0H8S7CEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mArlk-0024T0-Um; Tue, 03 Aug 2021 10:35:33 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mArkV-0023vr-J9 for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 10:34:17 +0000 Received: by mail-pl1-x62d.google.com with SMTP id e21so23148994pla.5 for ; Tue, 03 Aug 2021 03:34:14 -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=gUlOdJ9XQT6Y1TLMVY7TvS0f9TdTpUJkbcu/euswTpI=; b=OVGAJCGQgKOfrQtMQ+7oLZn99a1NlqUPMTDYPgr7T9jc92sQG/9KI8DH0WfHC+/HiE saufWO4B0WzYKSYqksSWu5YnTe0LBW0kDJG9cc9cXJ55JMOlW9mgc4HxYDnFNTlQbkNi dBCm1uqNi8kfufYnmAyNtGBKzB9qBGA+SXDKn2X/Ls7CFl3F4qAgWj1dHnIg9DuDIKu1 XEiufcn580Usz96z7gH9cW2vzLamg9tdNJBtiaW53Y6zaR9eHIu57raRdPDmSznS52Z+ NMe474lh61Fc5mMDSo8gM3x4Ba348w+2PlOZdMX8DqlG0DGtqigoyUobasMWjUkAuD/D qWAQ== 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=gUlOdJ9XQT6Y1TLMVY7TvS0f9TdTpUJkbcu/euswTpI=; b=W5TiGmfNfEn4gZC+hTa836YyaByT0CSJKE5dzA618E/E8+09cxB6LPxNOG0OzRhn9Z 1nG93YpJNwLTrPYxGkYojcCdPTkHcJgBkg9i78U7jSmD0rn0u+nnFYzX2SEOepKbj6Gr BSeQdZo0mUnGA19EvtHh+aD8Pe8ishYLxIle4upqj9JdKnoEnbCLzc/qayIJ6MwpF2Cx +xene6N35+ZWY/9TUZleTz4OGqru11X61pCVzMghktWpDPjRKOUTXR69KZHAwO9b/Ayb MPJBJj9/XNuudWaGdSCQUF8+p+6IhTn1xaQYgUPF8cBYFdJCC9WsRyoGFsVstMK4tB+z 9JoQ== X-Gm-Message-State: AOAM530GmaI+rXe/x6OUl8aqS5SMNFXBxQA+4lvIX9d490U/H1wxG/Ae 8h+Gf8RacYPhC1t45+sd0wWgp6gL8AI/RI7yZM4= X-Google-Smtp-Source: ABdhPJy8/GLzJXE0Sbq4RzvQ2nMWzsr/B9cP3HzwsDbrXs4gyEVrA0uvccH3J3UGBLIYJ9viNfcDuohGBOr5NXxaViI= X-Received: by 2002:a17:902:b713:b029:12b:b249:693f with SMTP id d19-20020a170902b713b029012bb249693fmr1633411pls.17.1627986854331; Tue, 03 Aug 2021 03:34:14 -0700 (PDT) MIME-Version: 1.0 References: <20210723075858.376378-1-andrew@aj.id.au> <6cc64039-f82a-4c1e-ad2c-16fad7aa3178@www.fastmail.com> <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> In-Reply-To: <50aaf381-8cda-4656-9222-f23fda75d3bc@www.fastmail.com> From: Andy Shevchenko Date: Tue, 3 Aug 2021 13:33:38 +0300 Message-ID: Subject: Re: [RFC PATCH 0/6] leds: Fix pca955x GPIO pin mappings To: Andrew Jeffery 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" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210803_033415_688293_28EE029C X-CRM114-Status: GOOD ( 31.47 ) 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 Tue, Aug 3, 2021 at 7:07 AM Andrew Jeffery wrote: > 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? Nope. It's far from what I think of. Re-reading again your cover letter it points out that pin mux per se does not exist in the hardware. In this case things become a bit too complicated, but we still may manage to handle them. Before I was thinking about this hierarchy 1. pinmux driver (which is actually the main driver here) 2. LED driver (using regmap API) 3. GPIO driver (via gpio-regmap) 4. PWM driver. Now what we need here is some kind of "virtual" pinmux. Do I understand correctly? To be clear: I do not like putting everything into one driver when the logical parts may be separated. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel