From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753982AbdLHOkx (ORCPT ); Fri, 8 Dec 2017 09:40:53 -0500 Received: from mail-it0-f42.google.com ([209.85.214.42]:45856 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753567AbdLHOku (ORCPT ); Fri, 8 Dec 2017 09:40:50 -0500 X-Google-Smtp-Source: AGs4zMb23c1VnE1U7uHQqP16UJdbG/I7NM9mKa8JiVe/ruH+OauT0bVGU7c4J8zlmKrx3Hd3aUd5GbrWN8ACWqOGXns= MIME-Version: 1.0 In-Reply-To: <20171208142923.2exqaateli2qmtzl@localhost.localdomain> References: <20170929101503.6769-1-ckeepax@opensource.cirrus.com> <20171208142923.2exqaateli2qmtzl@localhost.localdomain> From: Linus Walleij Date: Fri, 8 Dec 2017 15:40:49 +0100 Message-ID: Subject: Re: [PATCH 0/4] Add support for muxing individual pins To: Charles Keepax Cc: ext Tony Lindgren , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , patches@opensource.cirrus.com, Bjorn Andersson , Stephen Warren Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 8, 2017 at 3:29 PM, Charles Keepax wrote: > (...) I have finally > managed to get some time to look over the pinctrl-single stuff. > > Naively one could convert the pinctrl-single stuff over to use > the patches I proposed creating one large group for the driver > and then mux each pin individually from within that. However I > am not really sure it would make sense. From the implementation > so far the pinctrl-single stuff appears to target systems where > there isn't really a concept of groups. Each pin is just a > completely separate entry and you can only configure things one > pin at a time. In that case it almost makes more sense to model > each pin as an individual group such that it is clearly distinct > from the others. My thinking had been more along the lines of you > perhaps have a group that represents an I2S port but you can also > individually assign each of those pins as a GPIO when not in use > as the I2S port. So then I toss the qcom driver into the game instead :) If you look at drivers/pinctrl/qcom/* e.g. pinctrl-ipq4019.c or essentially any of the subdrivers, you find exactly this scenario. I am concerned that if we add infrastructure for this, it needs to have more than one user. Qualcomm does fit your description above I think. Yours, Linus Walleij