linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jacopo mondi <jacopo@jmondi.org>
To: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Simon Horman <horms@verge.net.au>,
	linux-gpio@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] Renesas R9A06G032 PINCTRL Driver
Date: Mon, 3 Sep 2018 12:33:58 +0200	[thread overview]
Message-ID: <20180903103358.GC20333@w540> (raw)
In-Reply-To: <1535634775-19365-1-git-send-email-phil.edworthy@renesas.com>

[-- Attachment #1: Type: text/plain, Size: 4704 bytes --]

Hi Phil,

On Thu, Aug 30, 2018 at 02:12:52PM +0100, Phil Edworthy wrote:
> This implements the pinctrl driver for the RZ/N1 family of devices, including
> the R9A06G032 (RZ/N1D) device.
>
> One area that is likely to be contentious is the use of 'virtual pins' for the
> MDIO pinmuxing. The driver uses two pins (170 and 171) that don't exist on the
> device to configure the MDIO source within the RZ/N1 devices. On these devices,
> there are two Ethernet MACs, a 5-Port Switch, numerous industrial Ethernet
> peripherals, any of which can be the MDIO source. Configuring the MDIO source
> could be done without the virtual pins, e.g. by extending the functions to
> cover all MDIO variants (a total of 32 additional functions), but this would
> allow users to misconfigure individual MDIO pins, rather than assign all MDIO
> pins to a MDIO source. The choice of how to implement this will affect the
> DT bindings.
>
> This series was originally written by Michel Pollet whilst at Renesas, and I
> have taken over this work.
>
> One point from Michel's v1 series:
> "Note, I used renesas,rzn1-pinmux node to specify the pinmux constants,
> and I also don't use some of the properties documented in
> pinctrl-bindings.txt on purpose, as they are too limited for my use
> (I need to be able to set, clear, ignore or reset level, pull up/down
> and function as the pinmux might be set by another OS/core running
> concurently)."
>

I start by saying that I don't know this HW pin controller well, so
I might be missing something, but as commented on the original series from
Micheal, I still don't see why you need a custom property here...

My understanding, looking at this comment and the header provided by
patch [1/3] (include/dt-bindings/pinctrl/rzn1-pinctrl.h) is that
basically need to control pull-up/down and the output driver strength.

Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt reports
a set of generic pin configuration properties to be applied to a pin
configuration (and multiplexing) pin controller child node that fully
express all (most?) of your needs.

Eg. a pin configuration with pull up applied, using examples from your
cover letter should be expressed as

Your example:
         &pinctrl {
                 pinsuart0: pinsuart0 {
                         renesas,rzn1-pinmux-ids = <
                                 RZN1_MUX(103, UART0_I)  /* UART0_TXD */
                                 RZN1_MUX_PUP(104, UART0_I)      /* UART0_RXD */
                         >;
                 };
         };

Using standard pinctroller bindings pin configuration properties:

         &pinctrl {
                 pinsuart0: uart0  {
                        pinsuart_tx0 {
                                pinmux = <103, UART0_I>;  /* UART0_TXD */
                        };

                        pinsuart_rx0 {
                                 pinmux = <104, UART0_I>; /* UART0_RXD */
                                 bias-pull-up;
                        };
                 };
         };

Is there anything I am missing? Maybe from the interaction with
"another OS/core running concurrently" you mentioned? In this case if
you only have to perform pin configuration (because muxing is handled
already) things are even simpler, just use the pin configuration
bindings, without involving muxing at all:

        &pinctrl {
                pinsuart_conf: uart0 {
                        pins = <103, 104>;
                        bias-pull-up;
                 };
         };

Thanks
  j

> Patch 0003 should really be applied after patch:
>  "ARM: dts: r9a06g032: Correct UART and add all other UARTs", see
>  https://www.spinics.net/lists/arm-kernel/msg673525.html
>
> Main changes:
> v2:
>  - Change to generic rzn1 family driver, instead of device specific.
>  - Review comments fixed.
>  - Fix error handling during probe
>
> Phil Edworthy (3):
>   dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation
>   pinctrl: renesas: Renesas RZ/N1 pinctrl driver
>   ARM: dts: r9a06g032: Add pinctrl node
>
>  .../bindings/pinctrl/renesas,rzn1-pinctrl.txt      |  97 +++
>  arch/arm/boot/dts/r9a06g032.dtsi                   |   8 +
>  drivers/pinctrl/Kconfig                            |  10 +
>  drivers/pinctrl/Makefile                           |   1 +
>  drivers/pinctrl/pinctrl-rzn1.c                     | 844 +++++++++++++++++++++
>  include/dt-bindings/pinctrl/rzn1-pinctrl.h         | 191 +++++
>  6 files changed, 1151 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.txt
>  create mode 100644 drivers/pinctrl/pinctrl-rzn1.c
>  create mode 100644 include/dt-bindings/pinctrl/rzn1-pinctrl.h
>
> --
> 2.7.4
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  parent reply	other threads:[~2018-09-03 10:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 13:12 [PATCH v2 0/3] Renesas R9A06G032 PINCTRL Driver Phil Edworthy
2018-08-30 13:12 ` [PATCH v2 1/3] dt-bindings: pinctrl: renesas,rzn1-pinctrl: documentation Phil Edworthy
2018-08-30 13:12 ` [PATCH v2 2/3] pinctrl: renesas: Renesas RZ/N1 pinctrl driver Phil Edworthy
2018-08-30 13:12 ` [PATCH v2 3/3] ARM: dts: r9a06g032: Add pinctrl node Phil Edworthy
2018-08-31  0:50   ` kbuild test robot
2018-08-31  8:13     ` Phil Edworthy
2018-09-06  9:36       ` Simon Horman
2018-09-03 10:33 ` jacopo mondi [this message]
2018-09-03 11:03   ` [PATCH v2 0/3] Renesas R9A06G032 PINCTRL Driver Phil Edworthy
2018-09-03 11:25     ` jacopo mondi
2018-09-10  7:45       ` Linus Walleij
2018-09-05  9:36     ` Geert Uytterhoeven
2018-09-05  9:58       ` Phil Edworthy
2018-09-10  7:48         ` Linus Walleij
2018-09-10  9:42           ` Geert Uytterhoeven
2018-09-10  9:54             ` Phil Edworthy
2018-09-10  9:58               ` Geert Uytterhoeven
2018-09-10  9:46           ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180903103358.GC20333@w540 \
    --to=jacopo@jmondi.org \
    --cc=geert@linux-m68k.org \
    --cc=horms@verge.net.au \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=phil.edworthy@renesas.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).