On Mon, 10 May 2021 at 11:27, Arend van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
>
>
>
> On 5/10/2021 11:14 AM, Ulf Hansson wrote:
> > On Mon, 10 May 2021 at 09:37, Arend Van Spriel
> > <arend.vanspriel@xxxxxxxxxxxx> wrote:
> >>
> >> + Uffe
> >>
> >> On 5/10/2021 12:42 AM, Linus Walleij wrote:
> >>> This grabs the reset GPIO and holds it de-asserted, if available.
> >>> Asserting this signal will make the SDIO card re-enumerate.
> >>
> >> looks ok to me, but could this also be done through SDIO power sequence
> >> stuff?
> >
> > Yes, it certainly looks like that to me. It should be the mmc
> > host/core that manages the power on/off thingy for the SDIO card.
>
> Thanks, Uffe
>
> This is not directly power on/off, but a separate "reset" GPIO. However,
> checking in pwrseq_simple.c I see:
>
> struct mmc_pwrseq_simple {
> struct mmc_pwrseq pwrseq;
> bool clk_enabled;
> u32 post_power_on_delay_ms;
> u32 power_off_delay_us;
> struct clk *ext_clk;
> struct gpio_descs *reset_gpios;
> };
>
> So the term 'reset_gpios' is also used in pwrseq context.
I think this boils down to that to allow the mmc core to detect and
initialize the SDIO card, it needs to manage potential reset pins as
well.
In cases when the SDIO func driver may need to execute a reset, the
mmc core provides two APIs, mmc_hw|sw_reset().
Does this make sense to you?
Kind regards
Uffe
