linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] pinctrl_gpio_get_direction & ingenic fixes
Date: Thu, 12 Jul 2018 01:22:12 +0200	[thread overview]
Message-ID: <1531351332.2021.2@smtp.crapouillou.net> (raw)
In-Reply-To: <CACRpkdav3FV7hc20Fj=n=DaNzvSaA2uLuj8QgHwwcevDkn_6_Q@mail.gmail.com>

Hi Linus,


Le lun. 9 juil. 2018 à 14:09, Linus Walleij <linus.walleij@linaro.org> 
a écrit :
> Hi folks,
> 
> On Wed, Jun 27, 2018 at 7:18 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> 
>>  Even if GPIO and pin muxing has only one set of buffers to indicate
>>  input or output (same registers in use) it's a GPIO driver business 
>> to
>>  get direction from GPIO part of IP.
>> 
>>  Looking into the existing code I would rather say that
>>  pinctrl-ingenic.c should incorporate gpio-ingenic.c as they are
>>  (partially) sharing same registers.
> 
> Usually we only split the functionality into two drivers if the two 
> features
> pin control and GPIO are explicitly in different hardware blocks,
> and typically not sharing the same memory range.
> 
> If these registers are intermingled and the hardware actually
> just one piece of silicon, I would suggest to try to merge the
> two drivers into a combined pin control and GPIO driver
> inside drivers/pinctrl/pinctrl-ingenic.c.
> 
> We have a few drivers like that already, good textbook
> examples of how to do this include
> drivers/pinctrl/pinctrl-sx150x.c where the two blocks are
> handled in one driver using both APIs.
> 
> Paul could you have a look at if we can simply merge these
> two into one big driver? It is much more natural to write
> into the same set of registers when we do that.

Well I wish you had told me that when I submitted the ingenic 
pinctrl/gpio
patchset :)

I won't have much time before 4.19-rc1, but I can have a look after 
that.

> If you still prefer to proceed with the GPIO/pinctrl as separate
> drivers we need to look into this patch set, which I am
> a bit ambivalent about, because it makes sense but at the
> same time I want to keep GPIO and pin control business
> separate because separation of concerns is just nice.

Well I can still implement the get_direction() function in the GPIO
driver by reading the registers instead of calling into pinctrl.

I just thought it felt illogic as set_direction() does that.

> Yours,
> Linus Walleij

Thanks,
-Paul


      reply	other threads:[~2018-07-11 23:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27 11:48 [PATCH 0/5] pinctrl_gpio_get_direction & ingenic fixes Paul Cercueil
2018-06-27 11:49 ` [PATCH 1/5] pinctrl: Add core function pinmux_gpio_get_direction Paul Cercueil
2018-06-27 11:49 ` [PATCH 2/5] pinctrl: Add API function pinctrl_gpio_get_direction Paul Cercueil
2018-06-27 14:07   ` kbuild test robot
2018-06-27 15:24   ` kbuild test robot
2018-06-27 11:49 ` [PATCH 3/5] pinctrl: ingenic: Fix inverted direction for < JZ4770 Paul Cercueil
2018-07-09 11:58   ` Linus Walleij
2018-06-27 11:49 ` [PATCH 4/5] pinctrl: ingenic: Implement pinmux callback .gpio_get_direction Paul Cercueil
2018-06-27 11:49 ` [PATCH 5/5] GPIO: ingenic: Implement .get_direction Paul Cercueil
2018-06-27 17:18 ` [PATCH 0/5] pinctrl_gpio_get_direction & ingenic fixes Andy Shevchenko
2018-06-28 19:11   ` Paul Cercueil
2018-06-29 15:29     ` Andy Shevchenko
2018-07-09 12:18     ` Linus Walleij
2018-07-09 12:09   ` Linus Walleij
2018-07-11 23:22     ` Paul Cercueil [this message]

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=1531351332.2021.2@smtp.crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=andy.shevchenko@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).