linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Chris Brandt <Chris.Brandt@renesas.com>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
	"magnus.damm@gmail.com" <magnus.damm@gmail.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH 0/3] Renesas RZ PFC and GPIO driver
Date: Tue, 10 Jan 2017 00:49:30 +0200	[thread overview]
Message-ID: <1923903.Gi7z59W6W3@avalon> (raw)
In-Reply-To: <SG2PR06MB1165EE67EA2969815758A3038A640@SG2PR06MB1165.apcprd06.prod.outlook.com>

Hi Chris,

On Monday 09 Jan 2017 21:08:49 Chris Brandt wrote:
> On Monday, January 09, 2017, Laurent Pinchart wrote:
> > Pin control on the Renesas RZ chips is performed per pin instead of per
> > function (but unfortunately with the various bits of configuration split
> > across a bunch of registers, otherwise we could have used pinctrl-single).
> 
> I will say this...'spoilier alert'...you're not going to see this particular
> PFC HW much anymore in the RZA series.
> 
> It will still be a 'per pin control' like the existing RZ/A1, but the bits
> will not be spread out over a bunch of registers. So something like
> pinctrl-single should work.

Both the existing RZ/A model and the pinctrl model are in my opinion 
improvements over the RZ/G and R-Car models. I don't care much about whether 
pinctrl-single can be used, but we really need hardware architectures that 
don't require those huge data tables.

> No idea about the future of RZG series.

I'll cross my fingers.

> > This gives us an opportunity to move away from the sh-pfc awful (but more
> > or less needed for the R-Car family) architecture and implement something
> > much, much cleaner without all those obscure data tables and macros, with
> > per-pin configuration. Shouldn't we rejoice and embrace that opportunity ?
> 
> Honestly, that driver structure confuses the heck out of me. I guess you
> have to understand the restrictions of the R-Car PFC HW to really
> appreciate it.

No, you can't appreciate it, no matter what :-)

> Of course I like the idea of a simple PFC for Renesas SoCs, of course the
> existing RZ/A1 would be (hopefully) the worst case scenario.
> 
> I assume to make a one-size-fits-all per-pin driver, instead of filling out
> structures and enums, you'd have to have callback functions that basically
> you pass "set pin X to function #3"...which basically brings you back to
> what the core of the pinctrl system does now any (if I understand it
> correctly).

It's more complex than that. Both the pin-based and group-based models have 
their pros and cons, and the pinctrl API is some kind of mix that allows both 
options.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2017-01-09 22:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 19:31 [PATCH 0/3] Renesas RZ PFC and GPIO driver Jacopo Mondi
2017-01-09 19:31 ` [PATCH 1/3] pinctrl: sh-pfc: Add r7s72100 PFC driver Jacopo Mondi
2017-01-10 14:59   ` Geert Uytterhoeven
2017-01-09 19:31 ` [PATCH 2/3] gpio: gpio-rz: GPIO driver for Renesas RZ series Jacopo Mondi
2017-01-11 14:55   ` Linus Walleij
2017-01-12 10:50     ` jacopo mondi
2017-01-12 14:39       ` Chris Brandt
2017-01-12 19:13         ` jacopo mondi
2017-01-12 19:45           ` Chris Brandt
2017-01-09 19:31 ` [PATCH 3/3] arm: dts: r7s72100: Add peripherals nodes Jacopo Mondi
2017-01-10 15:07   ` Geert Uytterhoeven
2017-01-10 19:58     ` Laurent Pinchart
2017-01-10 21:13       ` Geert Uytterhoeven
2017-01-11 10:33       ` Simon Horman
2017-01-11 10:55         ` Laurent Pinchart
2017-01-11 10:59           ` Simon Horman
2017-01-11  9:17     ` jacopo mondi
2017-01-11 10:56   ` Laurent Pinchart
2017-01-09 19:51 ` [PATCH 0/3] Renesas RZ PFC and GPIO driver Laurent Pinchart
2017-01-09 21:08   ` Chris Brandt
2017-01-09 22:49     ` Laurent Pinchart [this message]
2017-01-09 23:53       ` Chris Brandt
2017-01-10  1:28         ` Laurent Pinchart
2017-01-10  3:12           ` Chris Brandt
2017-01-10 22:32           ` jacopo mondi
2017-01-11  0:46             ` Chris Brandt
2017-01-11 10:35               ` Simon Horman
2017-01-11 11:22             ` Laurent Pinchart
2017-01-11 15:15               ` jacopo mondi
2017-01-11 16:31                 ` Laurent Pinchart
2017-01-11 17:51                   ` jacopo mondi
2017-01-11 20:17                     ` Chris Brandt

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=1923903.Gi7z59W6W3@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=Chris.Brandt@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=jacopo+renesas@jmondi.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    /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).