From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbdLHO3f (ORCPT ); Fri, 8 Dec 2017 09:29:35 -0500 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:34816 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753675AbdLHO33 (ORCPT ); Fri, 8 Dec 2017 09:29:29 -0500 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.cirrus.com Date: Fri, 8 Dec 2017 14:29:23 +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: <20171208142923.2exqaateli2qmtzl@localhost.localdomain> References: <20170929101503.6769-1-ckeepax@opensource.cirrus.com> 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=1011 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-1712080202 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 09, 2017 at 11:10:34PM +0200, Linus Walleij wrote: > On Fri, Sep 29, 2017 at 12:14 PM, Charles Keepax > wrote: > > This series add support for muxing individual pins within > > pin mux, rather than just whole groups. Mainly, I had two > > motivations here, one to avoid the need to add loads of groups > > containing individual pins and hardware that actually has some > > internal concept of groups of pins, and disambiguating that from > > individual pin muxing. I have marked it as RFC to just get > > peoples opinions at this stage, although it should be pretty well > > tested. Sorry about the amount of files touched in patch 2 it > > would be possible to drop it from the chain although it leaves > > the field rather inaccurately named. > > > > Also I have left all the existing code paths parsing all mux > > options as groups from DT, and added a new helper to unlock the > > pin based functionality this should ease the transition across. > There is currently a driver in the pin control subsystem that > handles individual pins and that is pinctrl-single.c. > > The driver is deployed for single pins muxed by a single > register, and if this infrastructure is to be deployed it must > be applied also in pinctrl-single. We cannot have several ways > of doing the same thing, that way lies madness. > > So you need Tony Lindgren's review and direction on this > patch series. Apologies for the delay on this one, I got some what snowed under with other tasks. Please let me know if you would rather I just resent the series to refresh everyones memory. But 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. Alternatively one could perhaps look at expanding the pinctrl-single stuff to have some notion of groups as well. So you could define sub groups of the pins that can be set as a block. Allowing users to configure either groups or individual pins. I guess my main question is what is the intention of the pinctrl-single code, is this something that should be seeing expansion to handle groups as well or is it firmly for the unrelated pins cases? Thanks, Charles