Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>
To: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	Chris Paterson <chris.paterson2@renesas.com>,
	linux-renesas-soc@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH 00/11] pinctrl: sh-pfc: Convert to new non-GPIO helper macros
Date: Wed, 15 May 2019 15:38:25 +0200
Message-ID: <20190515133825.GB31788@bigcity.dyn.berto.se> (raw)
In-Reply-To: <20190513152857.13122-1-geert+renesas@glider.be>

Hi Geert,

Thanks for your work.

On 2019-05-13 17:28:46 +0200, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> On many Renesas ARM SoCs, there exist pins that are not associated with
> a GPIO port, but still need configuration (e.g. drive strength or
> pull-up).  While pins with GPIO functionality are indexed by their
> GPIO number, no such number exists for non-GPIO pins.  Hence for the
> latter, the pin control driver uses numbers outside the GPIO number
> space, derived from the row and column numbers of the physical pins.
> 
> For R-Car H3 (and later M3-W and M3-N), the choice was made to use the
> SiP (System-in-Package, i.e. SoC + RAM + HyperFlash in a BGA package)
> physical pin numbers, as the SiP was what was mounted on the
> Salvator-X(S) and ULCB development boards available at that time.
> 
> In hindsight, it would have been better to settle on the SoC physical
> pin numbers, though: the pin control driver for R-Car M3-W was reused
> for the RZ/G2M SoC, which is only available as an SoC, not SiP, thus
> making it hard to match the driver with the documentation.
> 
> But even for SoCs there can be confusion: several SoCs are available in
> multiple packages, with the same or different number of pins, leading to
> different pin numberings.
> 
> As this numbering is used only internal to the driver, and pin control
> configuration from DT refers to these pins by signal name, not pin
> number (usually, see exceptions below[*]), I started wondering if we
> could get rid of the SoC/SiP pin numbers instead.  As the actual numbers
> don't matter, all that is needed for the driver is a unique number for
> each pin.
> 
> Hence this patch series converts the affected drivers to use new macros
> that allow to describe pins without GPIO functionality, and refer to
> them by auto-generated symbolic enum values, similar in spirit to the
> existing scheme for handling pins with GPIO functionality.
> 
> This series consists of three parts:
>   - Patch 1 introduces new macros to describe and handle pins without
>     GPIO functionality,
>   - Patches 2-10 convert the pin control drivers for the individual SoCs
>     to use the new macros,
>   - Patch 11 removes the now unused old macros.
> 
> There should be no functional changes induced by this patch series,
> which has been tested on Salvator-X(S) (with R-Car H3 ES1.0 and ES2.0,
> M3-W, and M3-N), Ebisu (R-Car E3), and KZM-A9-GT (SH-Mobile AG5).
> 
> [*] The user-visible names of pins without GPIO functionality are based
>     on pin numbers (e.g. "B25") instead of signal names ("CLKOUT") on
>     EMMA Mobile EV2, R-Car M1A, R-Car H2, and SH-Mobile AG5.
>     I didn't change these to preserve DT backwards compatibility.
> 
> The "name" parameters of the PIN_NOGP_CFG() and PIN_NOGP() macros could
> be removed, if these macros would generate the names from the "pin"
> parameters.  However, that would:
>   1. Require replacing the "#" suffices in pin names for active-low
>      signals by "_N",
>      R-Car H3/M3-W/M3-N use a "#" suffix, R-Car E3 use a "_N" suffix.
>   2. Replace the names based on pin numbers on older SoCs by signal
>      names.
> Both changes could affect DT backwards compatibility.  None of these are
> currently used in (upstream) DTS files, though.
> Do you think it would be worthwhile to make this consistent?
> 
> Thanks for your comments!

I really like how this is used, much better then SH_PFC_PIN_NAMED 
approach!

I have not reviewed all renames of PIN_NUMBER() to their more 
descriptive names, but did spot checks to make sure it made sens. I 
trust you for the rest ;-) For the whole series,

Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

I tested this on
- r8a7795
- r8a7796
- r8a77965

Feel free to add to those patches,

Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>

> 
> Geert Uytterhoeven (11):
>   pinctrl: sh-pfc: Add new non-GPIO helper macros
>   pinctrl: sh-pfc: emev2: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a7778: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a7790: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a7795-es1: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a7795: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a7796: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a77965: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: r8a77990: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: sh73a0: Use new macros for non-GPIO pins
>   pinctrl: sh-pfc: Remove obsolete SH_PFC_PIN_NAMED*() macros
> 
>  drivers/pinctrl/sh-pfc/pfc-emev2.c       |  70 +++--
>  drivers/pinctrl/sh-pfc/pfc-r8a7778.c     |  29 +-
>  drivers/pinctrl/sh-pfc/pfc-r8a7790.c     |  34 ++-
>  drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 333 +++++++++++------------
>  drivers/pinctrl/sh-pfc/pfc-r8a7795.c     | 313 +++++++++++----------
>  drivers/pinctrl/sh-pfc/pfc-r8a7796.c     | 307 ++++++++++-----------
>  drivers/pinctrl/sh-pfc/pfc-r8a77965.c    | 307 ++++++++++-----------
>  drivers/pinctrl/sh-pfc/pfc-r8a77990.c    |  87 +++---
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c      |  19 +-
>  drivers/pinctrl/sh-pfc/sh_pfc.h          |  72 +++--
>  10 files changed, 797 insertions(+), 774 deletions(-)
> 
> -- 
> 2.17.1
> 
> 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

-- 
Regards,
Niklas Söderlund

  parent reply index

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 15:28 Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 01/11] pinctrl: sh-pfc: Add " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 02/11] pinctrl: sh-pfc: emev2: Use new macros for non-GPIO pins Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 03/11] pinctrl: sh-pfc: r8a7778: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 04/11] pinctrl: sh-pfc: r8a7790: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 05/11] pinctrl: sh-pfc: r8a7795-es1: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 06/11] pinctrl: sh-pfc: r8a7795: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 07/11] pinctrl: sh-pfc: r8a7796: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 08/11] pinctrl: sh-pfc: r8a77965: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 09/11] pinctrl: sh-pfc: r8a77990: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 10/11] pinctrl: sh-pfc: sh73a0: " Geert Uytterhoeven
2019-05-13 15:28 ` [PATCH 11/11] pinctrl: sh-pfc: Remove obsolete SH_PFC_PIN_NAMED*() macros Geert Uytterhoeven
2019-05-15 12:35 ` [PATCH 00/11] pinctrl: sh-pfc: Convert to new non-GPIO helper macros Geert Uytterhoeven
2019-05-15 13:38 ` Niklas Söderlund [this message]
2019-06-04  9:20 ` Geert Uytterhoeven

Reply instructions:

You may reply publically 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=20190515133825.GB31788@bigcity.dyn.berto.se \
    --to=niklas.soderlund@ragnatech.se \
    --cc=chris.paterson2@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-renesas-soc@vger.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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org
	public-inbox-index linux-renesas-soc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git