From patchwork Mon Jun 26 08:45:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geert Uytterhoeven X-Patchwork-Id: 9808813 X-Patchwork-Delegate: geert@linux-m68k.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EA17D603F2 for ; Mon, 26 Jun 2017 08:45:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E928A208C2 for ; Mon, 26 Jun 2017 08:45:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D9B5E262FF; Mon, 26 Jun 2017 08:45:27 +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=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID 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 2B696208C2 for ; Mon, 26 Jun 2017 08:45:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751382AbdFZIp0 (ORCPT ); Mon, 26 Jun 2017 04:45:26 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:33919 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbdFZIpZ (ORCPT ); Mon, 26 Jun 2017 04:45:25 -0400 Received: by mail-it0-f67.google.com with SMTP id y134so12777369itc.1; Mon, 26 Jun 2017 01:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+Op/mxzK1aS1OzCRtRT4q6w/d79OsMwOZo0ofLYqjuE=; b=THFAeSCFEv3r/tKEPVFNN7PS7JqtgUhHvZM0t36KnRWZpfLXzxi5Bmnix3xwLTIRbz TIeperk0EuzZA8FuQ5yTIMEHe5bp6Yn+hLzfffjHB1W7ibWFc7BkGiZn76dqn3JjPJhI x7zvmC+VfKtCL5HwAiX9f3QaKwTITEDeVSbcwmicXNE3Ee/eyPvz3lH1PuvGl0GT7+5/ +BmX+A1FpVE/QaaWJaSv6Uc3BAJBD/h3RnMTD3HH1LLBI+tIWIAP0toYPqBNxZPE5jn8 CgsyOmgJdmYxhCSlGEna7PcjZLWVB7HtgE0ocYDqBUgPRhGqdc9EkisDmGI1J42KNunj i/nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+Op/mxzK1aS1OzCRtRT4q6w/d79OsMwOZo0ofLYqjuE=; b=oJJUw9bIMVGlqg4711oonv7hEkgM+Cvg6PetuyhkJX6OfaiBFJJw+cwA/lT9SCAO8s ysgnkUt5dr1t2SYTAFjMxet60Oc3QFRDDbaxhW+KzzCCdBNvkuxGaT/oev4ihL7Gr3G7 WEJ1SMSfNbf6BHhpu4P61Xtkde3o5k1BdTHuGo9YLLykJiKLHVMb4BlavMxnpNXzd0Ik ZhWJ6ItiSUFBS/1vLs+imFz31m/VqvgZ6Do4lR16uGQMqrfSofHqE2kt6SMmany+R8Yp QG0kEIGykZdwC2xVPVdPKq/zoOnWc7h7tst/aMLArY6Py4JFQVDxGYEeHp3Zp11HAfZ8 0tUw== X-Gm-Message-State: AKS2vOyCHspYgndQiYycA/Loq0vdY36NlYjvm96wLRjFzDcI5YCI8May IVrO78/diaAcfnFkh2+yBsbstqAHMK75DvU= X-Received: by 10.36.189.198 with SMTP id x189mr21664809ite.56.1498466723803; Mon, 26 Jun 2017 01:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.26.149 with HTTP; Mon, 26 Jun 2017 01:45:22 -0700 (PDT) In-Reply-To: <1498143276-7976-1-git-send-email-jacopo+renesas@jmondi.org> References: <1498143276-7976-1-git-send-email-jacopo+renesas@jmondi.org> From: Geert Uytterhoeven Date: Mon, 26 Jun 2017 10:45:22 +0200 X-Google-Sender-Auth: 4uZEUTrUUNo-LrRJRUV4ckwzqIM Message-ID: Subject: Re: [PATCH v6 00/8] Renesas RZ/A1 pin and gpio controller To: Linus Walleij Cc: Jacopo Mondi , Laurent Pinchart , Chris Brandt , Rob Herring , Mark Rutland , Russell King , Dong Aisheng , Linux-Renesas , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Linus, On Thu, Jun 22, 2017 at 4:54 PM, Jacopo Mondi wrote: > this is 6th round of RZ/A1 pin controller patch series. > > Where did we stop: discussion from pin controller driver shifted toward two > new generic pin configuration properties I added to the previous series > (bi-directional and output-enable). > > After a really long discussion, we decided to go for handling internally all > bi-directional use cases, making the generic property not a requirement for the > series. Interestingly, we recently found out the number of pins actually > requiring this flag is less (~half) than what reported by the processor manual, > so we could have handled these internally from day one :( > > We also now manage internally pins requiring IO direction specified in software > even when configured in alternate function mode (SWIO mode). Most of them are > handled by the driver, some of them have to come from DTS as the user can freely > select if they have to be inputs or outputs. For those pins, and after another > discussion involving NXP developers, we decided to use input-enable and > output-enable properties. I have just sent a patch to add output-enable to the > generic pin configuration properties, but it is currently under discussion. > > However, none of the pins currently configured by mainline DTS require those > properties to be specified, so I have dropped in this driver any dependency on > output-enable property, and I'm using instead the already in place > PIN_CONFIG_OUTPUT one. Once output-enable will eventually be accepted, we can > update the driver to make use of it, but since there are no use cases for that > at the moment, it makes not too much sense holding this series back for that. > > The total memory occupation we were so worried about of bi-directional and swio > pin tables is now around 100 bytes, because of how the number of pins actually > needing those flags has reduced and because of how we have arranged the > tables using bitfield structures (credits to Geert here). > > Having cleared out dependencies on new pin configuration properties and having > made configuration flags a driver specific issue, I hope this version can be > accepted and land in forthcoming pull request for Renesas PFC updates from > Geert, pending some feedback from the linux-gpio community. If this is OK for you, I'd like to include the first 3 patches (plus a small fix I received offline from Chris Brandt[*]) in my final pull request of sh-pfc for v4.13 (which I have been postponing in anticipation of this driver). After v4.13-rc1, Simon can queue up the DTS patches in his tree for v4.14. Thanks! [*] } > v1 -> v2: > - change pin configuration flags as suggested by Chris > - gpio set direction function fixed as suggested by Chris > - add some more example on pin configuration flag usage to dt-binding doc > - fix gpio-controller names to remove unit address as suggested by Geert > - some comments chopped here and there to make the driver less verbose > > v2 -> v3: > - fix grammar and syntax in comment and documentation > - fix code style (reverse xmas tree ordering in variable declaration) > - use irqsave/irqrestore in spinlock lock/unlock > - use devm_ version of kasprintf (memory returned was not properly free) > - use bitops.h operation ffs and fls to make sure a single bit is set in pmx > mask > - Add Geert's reviewed-by to DTS patches > > v3 -> v4: > - use "pinmux" property in pmx sub-nodes in place of "renesas,pins" > - use pinconf standard properties to set pin mux additional flags > - add "bi-directional" and "output-enable" to pinconf generic properties > - perform pmx function parsing at dt_node_to_map() time > - change DT bindings to use GENERIC_PINCONF > - change DT bindings to allow sub-nodes to have "pinmux" property specified > - several renames (register names, DT parse functions, set_mux() function) > > v4 -> v5: > - use pinctrl_enable() function in pin controller registration function > - update bindings documentation to incorporate Geert's comments > - add generic properties unpack macros > > v5 -> v6: > - add tables in driver to manage bi-directional and swio flags > - drop dependecies on new generic pin configuration properties > > Jacopo Mondi (8): > pinctrl: Renesas RZ/A1 pin and gpio controller > dt-bindings: pinctrl: Add RZ/A1 bindings doc > arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header > arm: dts: r7s72100: Add pin controller node > arm: dts: genmai: Add SCIF2 pin group > arm: dts: genmai: Add RIIC2 pin group > arm: dts: genmai: Add user led device nodes > arm: dts: genmai: Add ethernet pin group > > .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 218 ++++ > arch/arm/boot/dts/r7s72100-genmai.dts | 69 ++ > arch/arm/boot/dts/r7s72100.dtsi | 78 ++ > drivers/pinctrl/Kconfig | 11 + > drivers/pinctrl/Makefile | 1 + > drivers/pinctrl/pinctrl-rza1.c | 1309 ++++++++++++++++++++ > include/dt-bindings/pinctrl/r7s72100-pinctrl.h | 16 + > 7 files changed, 1702 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt > create mode 100644 drivers/pinctrl/pinctrl-rza1.c > create mode 100644 include/dt-bindings/pinctrl/r7s72100-pinctrl.h Gr{oetje,eeting}s, Geert --- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds --- a/drivers/pinctrl/pinctrl-rza1.c +++ b/drivers/pinctrl/pinctrl-rza1.c @@ -617,11 +617,13 @@ static int rza1_pin_mux_single(struct rza1_pinctrl *rza1_pctl, * to I/O direction specified by pin configuration -after- PMC has been * set to one. */ - if (!(mux_flags & (MUX_FLAGS_SWIO_INPUT | MUX_FLAGS_SWIO_OUTPUT))) + if (mux_flags & (MUX_FLAGS_SWIO_INPUT | MUX_FLAGS_SWIO_OUTPUT)) + rza1_set_bit(port, RZA1_PM_REG, pin, + mux_flags & MUX_FLAGS_SWIO_INPUT); + else rza1_set_bit(port, RZA1_PIPC_REG, pin, 1); rza1_set_bit(port, RZA1_PMC_REG, pin, 1); - rza1_set_bit(port, RZA1_PM_REG, pin, mux_flags & MUX_FLAGS_SWIO_INPUT); return 0;