linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] pinctrl_gpio_get_direction & ingenic fixes
Date: Thu, 28 Jun 2018 21:11:06 +0200	[thread overview]
Message-ID: <1530213066.3755.0@smtp.crapouillou.net> (raw)
In-Reply-To: <CAHp75Vc3QTYKp6oS6kW6EezsBbiLf9E=NBErHMbpxRU9EXMxWg@mail.gmail.com>


Hi Andy,

Le mer. 27 juin 2018 à 19:18, Andy Shevchenko 
<andy.shevchenko@gmail.com> a écrit :
> On Wed, Jun 27, 2018 at 2:48 PM, Paul Cercueil <paul@crapouillou.net> 
> wrote:
>>  Hi Linus,
>> 
>>  Here's a set of (rather RFC) patches, to implement
>>  pinctrl_gpio_get_direction(). I did that, because my gpio-ingenic 
>> driver
>>  calls pinctrl_gpio_set_direction() within its gpio_chip's 
>> .set_direction
>>  callback, but there was no corresponding function to implement the
>>  .get_direction callback. If that's not the right way to do it, 
>> please
>>  advise.
>> 
>>  If not merging the whole series, patch [3/5] is a real fix that 
>> should
>>  go through.
>> 
>>  Note that it doesn't make checkpatch.pl happy, I wasn't sure 
>> whether I
>>  should try to comply to checkpatch.pl or match the coding style in 
>> the
>>  pinctrl subsystem, I chose the latter.
> 
> I dunno what Linus would going to say about this, but I would like to
> see a schematics for this piece of IP.

ftp://ftp.ingenic.com/SOC/JZ4780/JZ4780_pm.pdf

> 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.

If I follow that logic it's also a GPIO driver business to set the 
direction
of a GPIO, right? Truth is the pinctrl subsystem takes care of that. So 
why
have "set direction" and no "get direction"?

> 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.
> To ->get_direction() implementation it's pretty straight forward, just
> read necessary registers in the gpio-ingenic.c directly. No need to
> have pin control or pin muxing to be involved.

Sure, it'd be pretty straightforward to do it from the GPIO driver, but 
I'd
still like to hear Linus' point of view about this.

As for merging pinctrl-ingenic.c and gpio-ingenic.c... I wouldn't 
disagree more,
even if they share registers, they belong to different subsystems. 
Besides,
your platform might need the pinctrl driver but not the GPIO one, or 
you might
want to provide the GPIO driver as a loadable module, etc.

Regards,
-Paul


  reply	other threads:[~2018-06-28 19:11 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 [this message]
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

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=1530213066.3755.0@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).