On Wed, Dec 8, 2010 at 1:13 PM, zhangfei gao <zhangfei.gao@xxxxxxxxx> wrote:
> Thanks for suggestion, do you mean
> Not use rfkill totally
If you want rfkill functionality, you can still provide it of course,
but don't give it direct access to the hardware.
You should provide rfkill functionality from within your wlan driver,
and then when ->set_block() is called, you probably want to take down
the wlan interface. Essentially pm_runtime_put_sync should be called,
which will tell SDIO core to power down the chip.
>, which already integrated into bluetooth,
> /net/bluetooth/hci_core.c
Yes, and take a look what it does there - it closes the device - and
doesn't fiddle with gpios directly.
> Instead, SDIO core introduce new regulator domain "gpio" for example
> corresponding to gpio handling, like "vmcc" corresponding to real
> voltage control.
> SDIO core call regulator_get/regulator_enable/regulator_disalbe("gpio"),
> to pull up and pull down gpio?
You should make sure that mmc_power_off/mmc_power_up will do whatever
needed to power off/on your card.
These functions will call into your host controller (via mmc_set_ios)
and eventually that should trigger your regulator appropriately.
>
> For how to open/close wifi, we used to use rfkill block/unblock wifi,
> which in fact to pull up/down the reset and power pin.
> Then how to open/close wifi in this method, using suspend & resume?
To power on/off your card, your driver will just need to call the
pm_runtime_get/put_* API (see wl1271_sdio_set_power() for reference).
>
> Thanks
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
