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
next prev parent 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).