* James Cameron [off-list ref] [140628 08:24]:

On Fri, Jun 27, 2014 at 04:39:42PM +0200, Andreas Fenkart wrote:

quoted

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

quoted

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.

quoted

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.

Wouldn't it be best to have the mwifiex properly handle the
reset GPIOs and idle status pins?

Those are not part of the SDIO spec AFAIK, and the mmc
controller should not need to care about those.

Also, at least omaps also have an issue where suspend won't
work with mwifiex loaded FYI.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html