Search Linux Wireless

Re: [PATCH] brcmfmac: Obtain reset GPIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/11/2021 10:48 AM, Ulf Hansson wrote:
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?

It does to me.

Regards,
Arend



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux