From patchwork Wed Apr 24 15:19:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Gonzalez X-Patchwork-Id: 10915049 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 57D40161F for ; Wed, 24 Apr 2019 15:19:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 45D402873C for ; Wed, 24 Apr 2019 15:19:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 39A282884B; Wed, 24 Apr 2019 15:19:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,FREEMAIL_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C94AC2873C for ; Wed, 24 Apr 2019 15:19:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725941AbfDXPTa (ORCPT ); Wed, 24 Apr 2019 11:19:30 -0400 Received: from ns.iliad.fr ([212.27.33.1]:37034 "EHLO ns.iliad.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730659AbfDXPT3 (ORCPT ); Wed, 24 Apr 2019 11:19:29 -0400 Received: from ns.iliad.fr (localhost [127.0.0.1]) by ns.iliad.fr (Postfix) with ESMTP id BB4A620846; Wed, 24 Apr 2019 17:19:27 +0200 (CEST) Received: from [192.168.108.49] (freebox.vlq16.iliad.fr [213.36.7.13]) by ns.iliad.fr (Postfix) with ESMTP id A356A2064B; Wed, 24 Apr 2019 17:19:27 +0200 (CEST) To: gpio , MSM Cc: Linus Walleij , Bjorn Andersson , Wolfram Sang , Jeffrey Hugo From: Marc Gonzalez Subject: Pinctrl DT for msm8998 Message-ID: <7b8c15a8-8a17-e16e-8974-4a0c3a202daa@free.fr> Date: Wed, 24 Apr 2019 17:19:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP ; ns.iliad.fr ; Wed Apr 24 17:19:27 2019 +0200 (CEST) Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, linusw wrote: > Some drivers prefer to handle individual pins by name, such as msm. > Some drivers, especially those with hardware tailored to handle pin > muxing groupwise, prefer to handle them by function group name. In > the case of msm, every group consists of one pin and these groups are > all named "gpioNN". What the pin control subsystem does is assign > functions to 1 or several groups of pins. In the msm case as there is > just one pin in every group, this becomes a bit confusing, it is easy > to mix up what is a pin and what is a group. The pin multiplexing is > done on groups while the pin configuration is done on individual > pins. As to why there is one-to-one pin to group name mapping in the > msm driver you need to ask bamse, for the pin control subsystem this > is just some string. I suppose there was a good reason to set it up > this way on msm. I think the msm may be set up this way because the > pins can be configured in so many ways that it is hard to come up > with natural groups that map to physical use cases (these are often > enumerable on other platforms). In many systems the driver authors > are restricted to how groups can be activated with functions, see eg > pinctrl-gemini.c, in many other cases the driver author tries to > half-guess the groups based on use cases that makes sense. bamse wrote: > You don't have to specify pinconf/pinmux in different subnodes > anymore, that changed a few years back. For the blsp you typically > want subnodes for each pin though, because they have different > configuration...but you don't need to split e.g gpio88 in a mux and > conf. Or per your production example, you don't need any subnodes at > all...just put the properties in i2c_5_{active,sleep} directly. And > as each gpioXX is configurable we need to define how we want each one > to be configured...and we need to list all the configureables in the > driver. In the qcom platform you can mux i2c on gpio87 at the same > time as running gpio88 as gpio. Not that it would make sense in this > case, but there are other such cases where we need the control of > each configurable item. Note that the two nodes are identical. Do I still need both then? &blsp1_i2c5 { status = "ok"; clock-frequency = <100000>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&i2c5_default>; pinctrl-1 = <&i2c5_sleep>; }; Couldn't I just change the above to: &blsp1_i2c5 { status = "ok"; clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&i2c5_default>; }; Regards. diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi index 6db70acd38ee..bc1a1a4081da 100644 --- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi @@ -75,4 +75,18 @@ drive-strength = <2>; /* 2 mA */ }; }; + + i2c5_default: i2c5_default { + pins = "gpio87", "gpio88"; + function = "blsp_i2c5"; + drive-strength = <2>; + bias-disable; + }; + + i2c5_sleep: i2c5_sleep { + pins = "gpio87", "gpio88"; + function = "blsp_i2c5"; + drive-strength = <2>; + bias-disable; + }; };