mbox series

[v13,0/3] mmc: mediatek: add support for SDIO async IRQ

Message ID 20220623090445.1401-1-axe.yang@mediatek.com
Headers show
Series mmc: mediatek: add support for SDIO async IRQ | expand

Message

Axe Yang June 23, 2022, 9:04 a.m. UTC
Changes in v13:
- remove state_dat1 related description in mtk-sd.yaml
- move device_init_wakeup() to probe stage
- remove redundancy SDC_CFG_SDIOIDE bit control in msdc_runtime_suspend()
- replace SDC_CFG_SDIOIDE control with __msdc_enable_sdio_irq() function to
  disable sdio irq when sdio_irq_claimed() return true in msdc_runtime_resume()
- restore to use pm_runtime_force_resume|suspend(), to avoid go out directly
  in force resume, bump up runtime PM usage counter before force suspend. 

Changes in v12:
- assign NULL to pins_eint directly instead of using kfree()

Changes in v11:
- remove '_irq' suffix in interrupts-names property
- fix yaml example build error
- refactor msdc_enable_sdio_irq(), free pins_eint if async irq is not supported

Changes in v10:
- add sample node for SDIO host which support wakeup interrupt in yaml
- skip MMC_PM_WAKE_SDIO_IRQ check before enable SDIO async interrupt
- add MMC_PM_KEEP_POWER check before SDIO eint pinstate parsing
- use dev_pm_set_dedicated_wake_irq_reverse() to correct irq control sequence
- set dedicated irq in msdc_enable_sdio_irq() rather than msdc_drv_probe()
- remove unnecessary wake irq control, rpm/dpm system shall manage that
- move wake irq/msdc irq control back to system suspend phase, use rpm_suspend
  and rpm_resume to ensure irq control sequence:
     disable msdc irq -> enable wake irq -> disable wake irq -> enable msdc irq
- simplify variables, check pins_eint to know whether wakeup settings are managed

Changes in v9:
- remove pinctrl "state_dat1"

Changes in v8:
- remove maxItems property under pinctrl-names property

Changes in v7:
- add device_init_wakeup() to register SDIO host as wakeup source

Changes in v6:
- abandon cap-sdio-async-irq flag, use wakeup-source flag instead
- extend interrupts and pinctrls in mediatek mmc host controller DT documents
- add mmc_card_enable_async_irq() to access enable_async_irq flag
- simplify wakeup irq implementation with dedicate wake up irq related interface

Changes in v5:
- resort variables to reversed xmas tree order
- restore old copyright year range and add current year back

Changes in v4:
- add MMC_CAP2_SDIO_ASYNC_IRQ judge before lookup eint pinctrl
- replace spin_lock_irqsave() variant with spin_lock() in eint irq handler

Changes in v3:
- correct abbreviations with capital letters in commit message
- replace copyright year with 2022 in mtk-sd.c
- remove unnessary pointer casting
- adjust variable order to reversed xmas tree
- remove a redundant blank line
- refine if statement, following standard pattern

Changes in v2:
- change flag name from 'cap-sdio-async-int' to 'cap-sdio-async-irq'
- change corresponding macro names from xxx_INT to xxx_IRQ
- resort new member in msdc_host structure
- refine function msdc_request_dat1_eint_irq()
- rename msdc_{suspend,resume} function names, add suffix '_noirq'
- add MMC_CAP2_NO_SDIO judgement before parse eint related pin setting

Axe Yang (3):
  dt-bindings: mmc: mtk-sd: extend interrupts and pinctrls properties
  mmc: core: Add support for SDIO wakeup interrupt
  mmc: mediatek: add support for SDIO eint wakup IRQ

 .../devicetree/bindings/mmc/mtk-sd.yaml       | 50 ++++++++++-
 drivers/mmc/core/sdio.c                       | 14 ++++
 drivers/mmc/host/mtk-sd.c                     | 84 +++++++++++++++++--
 include/linux/mmc/card.h                      |  8 +-
 include/linux/mmc/sdio.h                      |  5 ++
 5 files changed, 153 insertions(+), 8 deletions(-)

Comments

Axe Yang July 22, 2022, 7:53 a.m. UTC | #1
On Thu, 2022-07-21 at 12:58 +0200, Ulf Hansson wrote:
> + Linus Walleij
> 
> On Tue, 19 Jul 2022 at 12:35, Axe Yang <axe.yang@mediatek.com> wrote:
> > 
> > On Mon, 2022-07-18 at 14:21 +0200, Ulf Hansson wrote:
> > > On Thu, 23 Jun 2022 at 11:05, Axe Yang <axe.yang@mediatek.com>
> > > wrote:
> > > > 
> > > > Add support for eint IRQ when MSDC is used as an SDIO host.
> > > > This
> > > > feature requires SDIO device support async IRQ function. With
> > > > this
> > > > feature, SDIO host can be awakened by SDIO card in suspend
> > > > state,
> > > > without additional pin.
> > > > 
> > > > MSDC driver will time-share the SDIO DAT1 pin. During suspend,
> > > > MSDC
> > > > turn off clock and switch SDIO DAT1 pin to GPIO mode. And
> > > > during
> > > > resume, switch GPIO function back to DAT1 mode then turn on
> > > > clock.
> > > > 
> > > > Some device tree property should be added or modified in MSDC
> > > > node
> > > > to support SDIO eint IRQ. Pinctrls "state_eint" is mandatory.
> > > > Since
> > > > this feature depends on asynchronous interrupts, "wakeup-
> > > > source",
> > > > "keep-power-in-suspend" and "cap-sdio-irq" flags are necessary,
> > > > and
> > > > the interrupts list should be extended(the interrupt named with
> > > > sdio_wakeup):
> > > >         &mmcX {
> > > >                 ...
> > > >                 interrupt-names = "msdc", "sdio_wakeup";
> > > >                 interrupts-extended = <...>,
> > > >                                       <&pio xxx
> > > > IRQ_TYPE_LEVEL_LOW>;
> > > >                 ...
> > > >                 pinctrl-names = "default", "state_uhs",
> > > > "state_eint";
> > > >                 ...
> > > >                 pinctrl-2 = <&mmc2_pins_eint>;
> > > >                 ...
> > > >                 cap-sdio-irq;
> > > >                 keep-power-in-suspend;
> > > >                 wakeup-source;
> > > >                 ...
> > > >         };
> > > > 
> > > > Co-developed-by: Yong Mao <yong.mao@mediatek.com>
> > > > Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> > > > Signed-off-by: Axe Yang <axe.yang@mediatek.com>
> > > 
> > > My apologies for the delay in reviewing this.
> > 
> > It is okay. Glad to receive your reply.
> > 
> > > 
> > > > ---
> > > >  drivers/mmc/host/mtk-sd.c | 84
> > > > ++++++++++++++++++++++++++++++++++++---
> > > >  1 file changed, 78 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-
> > > > sd.c
> > > > index 195dc897188b..f907b96cfd87 100644
> > > > --- a/drivers/mmc/host/mtk-sd.c
> > > > +++ b/drivers/mmc/host/mtk-sd.c
> > > > @@ -1,6 +1,6 @@
> > > >  // SPDX-License-Identifier: GPL-2.0-only
> > > >  /*
> > > > - * Copyright (c) 2014-2015 MediaTek Inc.
> > > > + * Copyright (c) 2014-2015, 2022 MediaTek Inc.
> > > >   * Author: Chaotian.Jing <chaotian.jing@mediatek.com>
> > > >   */
> > > > 
> > > > @@ -20,6 +20,7 @@
> > > >  #include <linux/platform_device.h>
> > > >  #include <linux/pm.h>
> > > >  #include <linux/pm_runtime.h>
> > > > +#include <linux/pm_wakeirq.h>
> > > >  #include <linux/regulator/consumer.h>
> > > >  #include <linux/slab.h>
> > > >  #include <linux/spinlock.h>
> > > > @@ -440,8 +441,10 @@ struct msdc_host {
> > > >         struct pinctrl *pinctrl;
> > > >         struct pinctrl_state *pins_default;
> > > >         struct pinctrl_state *pins_uhs;
> > > > +       struct pinctrl_state *pins_eint;
> > > >         struct delayed_work req_timeout;
> > > >         int irq;                /* host interrupt */
> > > > +       int eint_irq;           /* interrupt from sdio device
> > > > for
> > > > waking up system */
> > > >         struct reset_control *reset;
> > > > 
> > > >         struct clk *src_clk;    /* msdc source clock */
> > > > @@ -1520,17 +1523,46 @@ static void
> > > > __msdc_enable_sdio_irq(struct
> > > > msdc_host *host, int enb)
> > > > 
> > > >  static void msdc_enable_sdio_irq(struct mmc_host *mmc, int
> > > > enb)
> > > >  {
> > > > -       unsigned long flags;
> > > >         struct msdc_host *host = mmc_priv(mmc);
> > > > +       unsigned long flags;
> > > > +       int ret;
> > > > 
> > > >         spin_lock_irqsave(&host->lock, flags);
> > > >         __msdc_enable_sdio_irq(host, enb);
> > > >         spin_unlock_irqrestore(&host->lock, flags);
> > > > 
> > > > -       if (enb)
> > > > -               pm_runtime_get_noresume(host->dev);
> > > > -       else
> > > > -               pm_runtime_put_noidle(host->dev);
> > > > +       if (mmc_card_enable_async_irq(mmc->card) && host-
> > > > > pins_eint) {
> > > > 
> > > > +               if (enb) {
> > > > +                       /*
> > > > +                        * In
> > > > dev_pm_set_dedicated_wake_irq_reverse(), eint pin will be set
> > > > to
> > > > +                        * GPIO mode. We need to restore it to
> > > > SDIO
> > > > DAT1 mode after that.
> > > > +                        * Since the current pinstate is
> > > > pins_uhs,
> > > > to ensure pinctrl select take
> > > > +                        * affect successfully, we change the
> > > > pinstate to pins_eint firstly.
> > > > +                        */
> > > > +                       pinctrl_select_state(host->pinctrl,
> > > > host-
> > > > > pins_eint);
> > > 
> > > I am sorry, but I don't understand what goes on here. Why do you
> > > need
> > > to change the pinctrl setting to "pins_eint" here?
> > > 
> > > The bellow call to dev_pm_set_dedicated_wake_irq_reverse()
> > > doesn't
> > > change the pinctrl setting as the comment suggests above.
> > > 
> > 
> > Actually, the pinctrl setting is changed:
> > In dev_pm_set_dedicated_wake_irq_reverse() -> ... ->
> > request_threaded_irq() -> __setup_irq() -> irq_request_resources()
> > ->
> > mtk_eint_irq_request_resources()-> mtk_xt_set_gpio_as_eint(), the
> > SDIO
> > DAT1 pin will be force reset to GPIO mode:
> 
> Aha. That looks a bit weird, but I get the problem now.
> 
> I have looped in Linus (the pintctrl maintainer) to get his opinion
> on this.
> 
Okay.

> > 
> > 
https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c*L339__;Iw!!CTRNKA9wMg0ARbw!10fxyOdpvC-aCfRRWEGS5lXRPC6qJ0Z79tnrnTNbOu8VgamIxVATeM_wDz-obpEJ$
> >  
> > 
> > So, I have to call pinctrl_select_state() to restore SDIO DAT1 pin
> > mode(pins_uhs). But pinctrl_select_state() return directly because
> > MSDC
> > driver still wrongly thinks current DAT1 state is SDIO DAT1 mode:
> > 
> > 
https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/core.c*L1344__;Iw!!CTRNKA9wMg0ARbw!10fxyOdpvC-aCfRRWEGS5lXRPC6qJ0Z79tnrnTNbOu8VgamIxVATeM_wD2q7InpM$
> >  
> > , which means I have to call pinctrl_select_state() in pairs:
> > Change
> > pinctrl to another state(pins_eint), then change it back to
> > pins_uhs
> > mode.
> 
> I see. So a call to pinctrl_select_state("pins_uhs") would not take
> effect, unless we call pinctrl_select_state("pins_eint") first. That
> sounds like the internal state of the pinctrl isn't maintained
> properly.
> 
That is correct. The GPIO mode is modified in a very hidden way, by
pass pinctrl mechanism.

> Let's see what Linus thinks about this.
> 
> Note that, I am happy to pick the patch as is around this, but I am
> worried we might be doing something at the mmc driver level, which
> should really be managed at the pinctrl layer.
> 
Okay. I will release patch V14 after Linus replies.

> > 
> > 
> > > dev_pm_set_dedicated_wake_irq_reverse() will register the
> > > wakeirq,
> > > but
> > > more importantly, it should also leave the wakeirq disabled,
> > > right?
> > 
> > Yes. wakeirq will be registered, and disabled. But SDIO DAT1 pin
> > mode
> > will be changed too.
> > 
> > > 
> > > > +                       ret =
> > > > dev_pm_set_dedicated_wake_irq_reverse(host->dev, host-
> > > > >eint_irq);
> > > > +
> > > > +                       if (ret) {
> > > > +                               dev_err(host->dev, "Failed to
> > > > register SDIO wakeup irq!\n");
> > > > +                               host->pins_eint = NULL;
> > > > +                               pm_runtime_get_noresume(host-
> > > > >dev);
> > > > +                       } else {
> > > > +                               dev_dbg(host->dev, "SDIO eint
> > > > irq:
> > > > %d!\n", host->eint_irq);
> > > > +                       }
> > > > +
> > > > +                       pinctrl_select_state(host->pinctrl,
> > > > host-
> > > > > pins_uhs);
> > > 
> > > According to my comment above, I also don't understand why you
> > > need
> > > this. Why can't you just leave the pinctrl in the "pins_uhs"
> > > state?
> > > 
> > 
> > I have to call pinctrl_select_state() in pairs.
> > 
> > 
> > > > +               } else {
> > > > +                       dev_pm_clear_wake_irq(host->dev);
> > > > +               }
> > > > +       } else {
> > > > +               if (enb) {
> > > > +                       /* Ensure host->pins_eint is NULL */
> > > > +                       host->pins_eint = NULL;
> > > > +                       pm_runtime_get_noresume(host->dev);
> > > > +               } else {
> > > > +                       pm_runtime_put_noidle(host->dev);
> > > > +               }
> > > > +       }
> > > >  }
> 
> [...]
> 
> 
Regards,
Axe
Linus Walleij July 22, 2022, 11:21 a.m. UTC | #2
On Thu, Jun 23, 2022 at 11:10 AM Axe Yang <axe.yang@mediatek.com> wrote:

> MSDC driver will time-share the SDIO DAT1 pin. During suspend, MSDC
> turn off clock and switch SDIO DAT1 pin to GPIO mode. And during
> resume, switch GPIO function back to DAT1 mode then turn on clock.

So what I see is that you have what the electronics chip people call
an armed pad ring, such that an asynchronous event detector is connected
to the pin when it is in GPIO mode, and in this mode the system
can enter a lower sleep state (like powering off the MMC block
silicon...)

That seems fine, this is definitely how the chip people expected
it to work.

> +       if (mmc_card_enable_async_irq(mmc->card) && host->pins_eint) {
> +               if (enb) {
> +                       /*
> +                        * In dev_pm_set_dedicated_wake_irq_reverse(), eint pin will be set to
> +                        * GPIO mode. We need to restore it to SDIO DAT1 mode after that.
> +                        * Since the current pinstate is pins_uhs, to ensure pinctrl select take
> +                        * affect successfully, we change the pinstate to pins_eint firstly.
> +                        */
> +                       pinctrl_select_state(host->pinctrl, host->pins_eint);
> +                       ret = dev_pm_set_dedicated_wake_irq_reverse(host->dev, host->eint_irq);
> +
> +                       if (ret) {
> +                               dev_err(host->dev, "Failed to register SDIO wakeup irq!\n");
> +                               host->pins_eint = NULL;
> +                               pm_runtime_get_noresume(host->dev);
> +                       } else {
> +                               dev_dbg(host->dev, "SDIO eint irq: %d!\n", host->eint_irq);
> +                       }
> +
> +                       pinctrl_select_state(host->pinctrl, host->pins_uhs);
> +               } else {
> +                       dev_pm_clear_wake_irq(host->dev);
> +               }
> +       } else {
> +               if (enb) {
> +                       /* Ensure host->pins_eint is NULL */
> +                       host->pins_eint = NULL;
> +                       pm_runtime_get_noresume(host->dev);
> +               } else {
> +                       pm_runtime_put_noidle(host->dev);
> +               }
> +       }

This looks right.

> +       /* Support for SDIO eint irq ? */
> +       if ((mmc->pm_caps & MMC_PM_WAKE_SDIO_IRQ) && (mmc->pm_caps & MMC_PM_KEEP_POWER)) {
> +               host->eint_irq = platform_get_irq_byname(pdev, "sdio_wakeup");
> +               if (host->eint_irq > 0) {
> +                       host->pins_eint = pinctrl_lookup_state(host->pinctrl, "state_eint");

I guess one of the other patches adds this to the DT binding?

With that:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
Axe Yang July 26, 2022, 7:46 a.m. UTC | #3
On Mon, 2022-07-25 at 14:46 +0200, Linus Walleij wrote:
> On Mon, Jul 25, 2022 at 11:13 AM Axe Yang <axe.yang@mediatek.com>
> wrote:
> > On Fri, 2022-07-22 at 13:21 +0200, Linus Walleij wrote:
> > > On Thu, Jun 23, 2022 at 11:10 AM Axe Yang <axe.yang@mediatek.com>
> > > wrote:
> > SDIO DAT1 pin mode is changed to GPIO mode in
> > dev_pm_set_dedicated_wake_irq_reverse():
> > 
> > 
https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c*L339__;Iw!!CTRNKA9wMg0ARbw!zE3kmi37pZw4HiBNeRipWbi3gbAqrljLVQc5JVz-WP_NaIWTVhXshkakjFNh478e$
> >  
> > 
> > dev_pm_set_dedicated_wake_irq_reverse() -> ...
> > ->request_threaded_irq()
> > -> __setup_irq() -> irq_request_resources() ->
> > mtk_eint_irq_request_resources()-> mtk_xt_set_gpio_as_eint()
> 
> This doesn't seem to have much to do with pin control?
> No pin control functions are called on this execution path,
> no pin control state is changed, right?

That's right, no pin control state is changed.

> 
> If what you mean is that
> it happens to poke into the same hardware registers that is
> mainly a matter of concurrency in the driver, sometimes two
> abstractions happen to have to poke into the same hardware
> registers and then it is up to the driver to maintain state for
> the hardware, this is not a question for the framework.
> 
> How is Mediatek developers thinking about this thing in general?
> You are a few people who developed the driver so certainly
> you must have some design idea to why irq_request_resources()
> poke around in these registers? Does it even perform pin
> control behind the back of the pin control framework?

I see. It is sensible to reset pin function to GPIO mode when trying to
register the pin to eint mode, and the operation is out of pinctrl
framework.

Seems like maintain the pin state in driver is the only way to fix the
pin function conflict.

> 
> > To restore SDIO DAT1 pin to uhs mode. I have to call
> > pinctrl_select_state() twice(change pinctrl to another state, then
> > change back to uhs mode). Ulf worried we might be doing something
> > at
> > the mmc driver level, which should really be managed at the pinctrl
> > layer.
> > 
> > Do you have any comment or suggestion on this?
> 
> The pin control state transitions are really just finite automata.
> 
> Your pin control needs to be different when using wakeup from
> when being used for SDIO and this is perfectly fine, it's no
> different from the fact that the regulator and clock might need
> to be in different states, so I don't quite understand the
> question?

I see. At first I thought that pinctrl framework should be aware of
the hidden modification of pin function. But as you said, it is just
a finite automata. Driver should correct GPIO settings by itself if pin
state be changed outside pin control state mechanical.
Sorry for the noise, and thanks for your comment again.

> 
> 
Regards,
Axe