Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755981AbdC2KPS (ORCPT ); Wed, 29 Mar 2017 06:15:18 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:35291 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755818AbdC2KPN (ORCPT ); Wed, 29 Mar 2017 06:15:13 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490026491-21742-1-git-send-email-jacopo+renesas@jmondi.org> <1490026491-21742-3-git-send-email-jacopo+renesas@jmondi.org> <20170323160204.GL30223@w540> From: Linus Walleij Date: Wed, 29 Mar 2017 12:15:05 +0200 Message-ID: Subject: Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc To: Geert Uytterhoeven Cc: jacopo , Jacopo Mondi , Geert Uytterhoeven , Laurent Pinchart , Chris Brandt , Rob Herring , Mark Rutland , Russell King , Linux-Renesas , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1694 Lines: 53 On Wed, Mar 29, 2017 at 9:35 AM, Geert Uytterhoeven wrote: > Me: >> See for example: >> include/dt-bindings/pinctrl/mt65xx.h >> >> And how that is used in: >> arch/arm/boot/dts/mt2701-pinfunc.h >> arch/arm/boot/dts/mt2701-evb.dts >> >> The docs are here: >> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt > > All of the above pack the information for a pin into a single 32-bit integer. > Is that what you want us to use, too? > Currently we use two integers: 1) pin index, and 2) function/flags combo. I don't really know what you need, sorry. But some kind of figure, yes. I would say whatever makes sense. 16+16 bits makes sense in most combinatorial spaces does it not? If you split 32 bits in 16 bits for pin and 16 bits for function, do you have more than 2^16 pins or 2^16 functions? If you really do we may need to go for u64 but ... really? Is there a rational reason for that other than "we did it like this first"? I do not understand the notion of "flags" here. I hope that is not referring to pin config, because I expect that to use the standard pin config bindings outside of the pinmux value which should just define the pin+function combo: node { pinmux = ; GENERIC_PINCONFIG; }; Example from Mediatek: i2c1_pins_a: i2c1@0 { pins { pinmux = , ; bias-pull-up = <55>; }; }; So this allows for a combine pin+function number but pull ups, bias etc are not baked into the thing, they have to be added on separately with the generic bindings, which is nice and very readable. Yours, Linus Walleij