linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hanks Chen <hanks.chen@mediatek.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mars Cheng <mars.cheng@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Rob Herring <robh@kernel.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Stephen Boyd <sboyd@kernel.org>, Sean Wang <sean.wang@kernel.org>,
	CC Hwang <cc.hwang@mediatek.com>,
	Loda Chou <loda.chou@mediatek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, <wsd_upstream@mediatek.com>,
	mtk01761 <wendell.lin@mediatek.com>,
	linux-clk <linux-clk@vger.kernel.org>
Subject: Re: [PATCH v2 05/11] pinctrl: mediatek: avoid virtual gpio trying to set reg
Date: Sun, 22 Dec 2019 21:52:04 +0800	[thread overview]
Message-ID: <1577022724.7468.20.camel@mtkswgap22> (raw)
In-Reply-To: <CACRpkdZa_sQgvWC3ic0NxrVi9gS1cNTsV-wa-SDpA0e5kutBRw@mail.gmail.com>

On Fri, 2019-08-23 at 10:57 +0200, Linus Walleij wrote:
> On Mon, Aug 19, 2019 at 11:22 AM Mars Cheng <mars.cheng@mediatek.com> wrote:
> 
> > for virtual gpios, they should not do reg setting and
> > should behave as expected for eint function.
> >
> > Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> 
> This does not explain what a "virtual GPIO" is in this
> context, so please elaborate. What is this? Why does
> it exist? What is it used for?
> 
> GPIO is "general purpose input/output" and it is a
> pretty rubbery category already as it is, so we need
> to define our terms pretty strictly.
> 
Virtual GPIO only used inside SOC and not being exported to outside SOC
in MTK platform. Some modules use virtual GPIO as eint (e.g. pmic or
usb).
In MTK platform, external interrupt (EINT) and GPIO is 1-1 mapping and
we can set GPIO as eint.
But some modules use specific eint which doesn't have real GPIO pin.
So we use virtual GPIO to map it.

> > +bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n)
> > +{
> > +       const struct mtk_pin_desc *desc;
> > +       bool virt_gpio = false;
> > +
> > +       if (gpio_n >= hw->soc->npins)
> > +               return virt_gpio;
> > +
> > +       desc = (const struct mtk_pin_desc *)&hw->soc->pins[gpio_n];
> > +
> > +       if (desc->funcs &&
> > +           desc->funcs[desc->eint.eint_m].name == 0)
> 
> NULL check is done like this:
> 
> if (desc->funcs && !desc->funcs[desc->eint.eint_m].name)
> 
> > +               virt_gpio = true;
> 

got it, will fix it in v3. Thanks for reviewing.

> So why is this GPIO "virtual" because it does not have
> a name in the funcs table?
> 
yes, it doesn't have real GPIO pin and name, so we set it as virtual GPIO.

> > @@ -278,6 +295,9 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned long eint_n)
> >         if (err)
> >                 return err;
> >
> > +       if (mtk_is_virt_gpio(hw, gpio_n))
> > +               return 0;
> 
> So does this mean we always succeed in setting a GPIO as eint
> if it is virtual? Why? Explanatory comment is needed.
> 
yes, we use virtual GPIO to map it.

> > @@ -693,6 +693,9 @@ static int mtk_gpio_get_direction(struct gpio_chip *chip, unsigned int gpio)
> >         const struct mtk_pin_desc *desc;
> >         int value, err;
> >
> > +       if (mtk_is_virt_gpio(hw, gpio))
> > +               return 1;
> 
> Why are "virtual GPIOs" always inputs?
> 
We set virtual GPIO as eint.
It mean virtual GPIO only used inside SOC and not being exported to
outside SOC.

> Yours,
> Linus Walleij

Sorry for the late reply.

I'm the new bsp contact of mtk phone project.
I will be taking over from Mars.

Thanks for reviewing.

  reply	other threads:[~2019-12-23  3:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19  9:21 [PATCHv2 00/11] Add basic SoC Support for Mediatek MT6779 SoC Mars Cheng
2019-08-19  9:21 ` [PATCH v2 01/11] dt-bindings: mediatek: add support for mt6779 reference board Mars Cheng
2019-08-23 15:50   ` Matthias Brugger
2019-08-19  9:21 ` [PATCH v2 02/11] dt-bindings: mtk-uart: add mt6779 uart bindings Mars Cheng
2019-08-23 15:47   ` Matthias Brugger
2019-08-19  9:21 ` [PATCH v2 03/11] dt-bindings: irq: mtk,sysirq: add support for mt6779 Mars Cheng
2019-08-23  8:51   ` Linus Walleij
2019-08-23 15:51     ` Matthias Brugger
2019-08-23 15:44   ` Matthias Brugger
2019-08-27 16:50   ` Rob Herring
2019-08-19  9:21 ` [PATCH v2 04/11] pinctrl: mediatek: update pinmux definitions " Mars Cheng
2019-08-23 15:53   ` Matthias Brugger
2020-01-02  4:04     ` Hanks Chen
2019-08-19  9:21 ` [PATCH v2 05/11] pinctrl: mediatek: avoid virtual gpio trying to set reg Mars Cheng
2019-08-23  8:57   ` Linus Walleij
2019-12-22 13:52     ` Hanks Chen [this message]
2020-01-07 10:20       ` Linus Walleij
2020-01-08 11:27         ` Hanks Chen
2019-08-19  9:21 ` [PATCH v2 06/11] pinctrl: mediatek: add pinctrl support for MT6779 SoC Mars Cheng
2019-08-22 18:12   ` Sean Wang
2019-08-23  8:59     ` Linus Walleij
2019-08-19  9:21 ` [PATCH v2 07/11] pinctrl: mediatek: add mt6779 eint support Mars Cheng
2019-08-22 18:13   ` Sean Wang
2019-08-19  9:21 ` [PATCH v2 08/11] dt-bindings: mediatek: bindings for MT6779 clk Mars Cheng
2019-08-27 16:52   ` Rob Herring
2019-09-10 14:53   ` Stephen Boyd
2019-08-19  9:21 ` [PATCH v2 09/11] clk: mediatek: Add dt-bindings for MT6779 clocks Mars Cheng
2019-08-27 16:53   ` Rob Herring
2019-09-10 14:53   ` Stephen Boyd
2019-08-19  9:21 ` [PATCH v2 10/11] clk: mediatek: Add MT6779 clock support Mars Cheng
2019-09-10 14:53   ` Stephen Boyd
2019-08-19  9:21 ` [PATCH v2 11/11] arm64: dts: add dts nodes for MT6779 Mars Cheng
2019-08-19  9:40   ` Marc Zyngier
2019-08-19 11:42     ` Mars Cheng
2019-08-19 12:07       ` Marc Zyngier
2019-08-22  0:46         ` Mars Cheng
2019-08-23 16:13   ` Matthias Brugger

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=1577022724.7468.20.camel@mtkswgap22 \
    --to=hanks.chen@mediatek.com \
    --cc=cc.hwang@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=loda.chou@mediatek.com \
    --cc=marc.zyngier@arm.com \
    --cc=mars.cheng@mediatek.com \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sean.wang@kernel.org \
    --cc=wendell.lin@mediatek.com \
    --cc=wsd_upstream@mediatek.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).