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 03:28:20 +0200	[thread overview]
Message-ID: <2671694.94z5NEauGX@avalon> (raw)
In-Reply-To: <SG2PR06MB1165EBCB06C5D473CBAC2F218A640@SG2PR06MB1165.apcprd06.prod.outlook.com>

Hi Chris,

On Monday 09 Jan 2017 23:53:39 Chris Brandt wrote:
> On Monday, January 09, 2017, Laurent Pinchart wrote:
> > 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.
> 
> I can definitely agree to that.
> 
> > 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.
> 
> Here is my general question: Which of these 2 approaches are better?
> 
> A) In the DT, the user ask "enable Ethernet please" and magic happens in
>    the pfc driver.
> 
> B) In the DT, the user looks up the correct pin/function assignments in
>    the SoC Hardware Manual and manually spells out what they need.
> 
> R-Car looks more like A. I've been using a driver that looks more like B.
> 
> For most drivers (USB, MMC, SDHI, etc..,), I'm happy when 'magic happens'
> and I don't really have to open a HW manual at all.
> But, for something like setting up the PFC when someone gets a shiny new
> board, making people actually open a HW manual seems acceptable to me.

>From a user point of view, option A looks better to me. However, it has two 
drawbacks:

- Through deciding what pin groups we make available we create a DT ABI that 
will make it difficult to fix mistakes in case the groups are not fine-grained 
enough.

- The data tables in C code are large, and we end up compiling many of them in 
multi-platform kernel, significantly increasing the kernel size.

I would thus favour option B.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2017-01-10  1:28 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
2017-01-09 23:53       ` Chris Brandt
2017-01-10  1:28         ` Laurent Pinchart [this message]
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=2671694.94z5NEauGX@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.