Re: mwifiex card reset

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

 




On Fri, Jun 27, 2014 at 04:39:42PM +0200, Andreas Fenkart wrote:
> I have an mwifiex module(sd8787) behind omap_hsmmc(am33xx-soc)
> The module is non-removable wired fix to soc. Now the wifi module
> needs 2 clocks; one is a sleep clock the other used when not
> sleeping.
> While the sleep clock is fixed, @32 kHz, the system clock can be
> one out of several values, but can be be derived automatically
> from the sleep clock. But this requires the clock to be present
> when the wifi module comes out of reset.
> 
> Another problem is software reboot, at initial power on the wifi
> card will react to mmc discovery. After a software reset of the
> host it will not, because it has already been disvovered and
> didn't notice the host rebooted, unless we reset it as well.
> While this seems obvious, the problem is that the reset is needed
> before the card can be discovered. Which means we cannot move the
> reset logic into the mwifiex driver, since that driver has not
> yet been selected through vendor/product id.
> 

we had same problem with sd8787 and a different system design.  we
added reset-gpios property [1] and used it in sdhci-pxav3.c [2] as
sdhci_pxav3_toggle_reset_gpio()

1.

http://code.coreboot.org/p/openfirmware/source/tree/HEAD/cpu/arm/olpc/sdhci.fth#L104

2.

http://dev.laptop.org/git/olpc-kernel/tree/drivers/mmc/host/sdhci-pxav3.c?h=arm-3.5#n229

> the reset logic:
>         gpiod_set_value(card->gpiod_reset, 0);
>         clk_enable(card->sleep_clock);
>         udelay(1000);
>         gpiod_set_value(card->gpiod_reset, 1);
> 
> The idea so far was to extend the device-tree node of the
> mmc slot by some reset leafs;
> 
> &mmc {
>         ti,non-removable;
>         ..
>         peripheral-clocks = <&clk &clk2 ...>;
>         peripheral-reset-gpios = <&gpio0 1 1 &gpio1 2 3 ...>;
> }
> 
> in mmc_add_host, all clocks will be enabled and gpios be pulled
> low for 1 msec

we used 5ms.

> Is this a feasible solution?
> 
> 
> Another related issue, is the card reset in mwifiex driver:
> 
> static void sdio_card_reset_worker(struct work_struct *work)
> {
>         struct mmc_host *target = reset_host;
> 
>         pr_err("Resetting card...\n");
>         mmc_remove_host(target);
>         /* 20ms delay is based on experiment with sdhci controller */
>         mdelay(20);
>         mmc_add_host(target);
> }
> static DECLARE_WORK(card_reset_work, sdio_card_reset_worker);
> 
> There are obviously a lot of problems with this, e.g. custom debugfs
> entries created in the driver will be lost. But sometimes this
> code might avert disaster in case the command handlers between
> driver and firmware lost synchronization
> 
> How could this be done in a better way?

i'm interested as well.

-- 
James Cameron
http://quozl.linux.org.au/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux