From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753786Ab2BCSN4 (ORCPT ); Fri, 3 Feb 2012 13:13:56 -0500 Received: from mail-gy0-f174.google.com ([209.85.160.174]:35616 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964Ab2BCSNz convert rfc822-to-8bit (ORCPT ); Fri, 3 Feb 2012 13:13:55 -0500 MIME-Version: 1.0 In-Reply-To: <20120203173205.GB1426@atomide.com> References: <74CDBE0F657A3D45AFBB94109FB122FF1780DAB4CE@HQMAIL01.nvidia.com> <20120201143530.GA2203@S2101-09.ap.freescale.net> <74CDBE0F657A3D45AFBB94109FB122FF178E124AC5@HQMAIL01.nvidia.com> <20120203173205.GB1426@atomide.com> Date: Sat, 4 Feb 2012 02:13:54 +0800 Message-ID: Subject: Re: Pinmux bindings proposal V2 From: Dong Aisheng To: Tony Lindgren Cc: Stephen Warren , Shawn Guo , Dong Aisheng-B29396 , "Linus Walleij (linus.walleij@linaro.org)" , "Sascha Hauer (s.hauer@pengutronix.de)" , "rob.herring@calxeda.com" , "kernel@pengutronix.de" , "cjb@laptop.org" , "Simon Glass (sjg@chromium.org)" , Thomas Abraham , "Grant Likely (grant.likely@secretlab.ca)" , "devicetree-discuss@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 4, 2012 at 1:32 AM, Tony Lindgren wrote: > * Dong Aisheng [120202 11:36]: >> >> Actually i think i'd rather do not use config property, then i could >> be more compact: >> (anyway it's another issue and is flexible to be controlled by #pinmux-cells) >> pinctrl_usdhc4: pinconfig-usdhc4 { >>         /* 0: pin 1: group */ >>         mux-entity = <0>; >>         func-name = "usdhc4func"; >>         grp-name = "usdhc4grp"; > > The func-name and grp-name should be optional here. > This mux entry is already the group, and can be used as > the group name. For the case i discussed here, the mux entry is PIN. (the mux-entity value is 0). we introduce this value here for treating all pins is one group. When do map parsing, only one pinmux map will be created. So we need a grp-name. And we also need a func-name here for construct pinmux map. > And the function name can be generated > dynamically in most cases. I'm currently using np->full_name > of the driver claiming these pins as the function name. > Why i did not use np->name as function name is because the np->name can be different while actually these nodes may represent the same function but just different pins, so the function name should be same. >>         mux = >>                 >>                 >>                 >>                 >>                 >>                 >>                 >>                 >>                 >>                 ; >> }; > > For listing basic pins this format works fine for me. It seems > to have low overhead for parsing. And the width of the array > can be driver specific. > > Looks like it's the binding for altenative states that's still a > bit open.. > Yes, it does not have states support. > So how about let's first standardize on the mux format above? > I'm afraid it may be hard for us to standardize the mux format for a standard binding in pinctrl core due to hw difference. I'm think the new way which i sent in this thread after the mail you replied. You can refer to them to see if it's reasonable for you too. Regards Dong Aisheng