linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Simon <horms@verge.net.au>, Magnus <magnus.damm@gmail.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH 2/2][RFC] pinctrl: sh-pfc: r8a7795: add SCIFx support
Date: Mon, 31 Aug 2015 10:53:06 +0000	[thread overview]
Message-ID: <1833045.8SRSLSWJG0@avalon> (raw)
In-Reply-To: <87fv304965.wl%kuninori.morimoto.gx@renesas.com>

Hi Morimoto-san,

On Monday 31 August 2015 00:06:21 Kuninori Morimoto wrote:
> Hi Laurent
> 
> >> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >> 
> >> This patch adds SCIF0/1/2/3/4/5
> >> 
> >> This patch is including Geert's SCIF support patch
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > 
> > I won't have time to review this in details. If you and Geert have double-
> > checked the data I'll trust you that they're correct.
> 
> Thanks. One question
> 
> In very pseudo code, PFC driver needs...
>  1) FN list
>  2) MARK list
>  3) register <-> FN mapping
>  4) pin <-> FN mapping
>  5) DT interface <-> pin mapping
> 
> Previous version had
>  - almost all (not all) 1),  2) list
>  - some 3), 4), 5) mapping
> 
>  -> it needs missing list, and new mapping for new feature
> 
> This version is
>  - [1/2]: frame only, minimum list, minimum mapping
>  - [2/2]: SCIF necessary list/mapping
> 
>  -> it needs all necessary FN/MARK list, and necessary mapping for new
> feature
> 
> Good point of new version is it picks up necessary list/mapping/setting.
> Bad  point of new version is it is very PITA to create/check pin.
> 
> which style do you like ?
>  1) It has all 1) 2) 3) in initial patch
>     we will add 4) 5) for new feature
> 
>  2) It has minimum list/mapping only in initial patch
>     we will add necessary 1) 2) 3) 4) 5) for new feature
> 
> I don't know which one is good style, but it is good timing to decide it,
> since it can be base style.

The first option is easier in the sense that we'll need to go through the pain 
of creating all the FN and MARK lists as register to FN mappings only once. 
The downside is that there's no chance anyone will review it given how big the 
patch is. If we go for the second option there's a higher chance that the 
lists and mappings will be reviewed, but I'm wondering whether it's really 
worth it, given the drawback that anyone wanting to add support for a new IP 
core will need to go dive in the PFC driver and understand all the internals. 
I would thus prefer the first option from a pure selfish way if I don't have 
to create the initial PFC patch :-) Please feel free to disagree.

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2015-08-31 10:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28  9:31 [PATCH 0/2][RFC] pinctrl: sh-pfc: r8a7795 support Kuninori Morimoto
2015-08-28  9:32 ` [PATCH 1/2][RFC] pinctrl: sh-pfc: Initial R8A7795 PFC support Kuninori Morimoto
2015-08-28 19:23   ` Laurent Pinchart
2015-08-31  6:53     ` Kuninori Morimoto
2015-08-31 10:00       ` Laurent Pinchart
2015-08-28  9:33 ` [PATCH 2/2][RFC] pinctrl: sh-pfc: r8a7795: add SCIFx support Kuninori Morimoto
2015-08-28 19:24   ` Laurent Pinchart
2015-08-31  0:06     ` Kuninori Morimoto
2015-08-31  8:59       ` Kuninori Morimoto
2015-08-31 10:53       ` Laurent Pinchart [this message]
2015-09-01  0:04         ` Kuninori Morimoto
2015-08-29  5:13   ` Magnus Damm
2015-08-31  0:04     ` Kuninori Morimoto
2015-08-31  4:46       ` Magnus Damm
2015-08-31  4:50 ` [PATCH 0/2][RFC] pinctrl: sh-pfc: r8a7795 support Magnus Damm
2015-08-31  5:58   ` Kuninori Morimoto

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=1833045.8SRSLSWJG0@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=horms@verge.net.au \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-sh@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).