From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752685AbdLHRWy (ORCPT ); Fri, 8 Dec 2017 12:22:54 -0500 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:48506 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752645AbdLHRWs (ORCPT ); Fri, 8 Dec 2017 12:22:48 -0500 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Date: Fri, 8 Dec 2017 17:22:44 +0000 From: Charles Keepax To: Linus Walleij CC: ext Tony Lindgren , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , , "Bjorn Andersson" , Stephen Warren Subject: Re: [PATCH 0/4] Add support for muxing individual pins Message-ID: <20171208172244.tbqybyrcubvrnwmm@localhost.localdomain> References: <20170929101503.6769-1-ckeepax@opensource.cirrus.com> <20171208142923.2exqaateli2qmtzl@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080238 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 08, 2017 at 03:40:49PM +0100, Linus Walleij wrote: > 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. > Yeah I could certainly have a hunt through for other users that would make good candidates to update. The QC driver certainly looks like it would be capable of muxing individual pins, although it looks like it might not let you mux an individual GPIO at the moment, need to dig into that more. I guess maybe a bigger question is do we think this is a problem worth solving or should really just be adding a group for each pin I want to be able to mux? Thanks, Charles