All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.