On Tue, Dec 7, 2010 at 9:13 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> On Tue, Dec 7, 2010 at 4:52 AM, zhangfei gao <zhangfei.gao@xxxxxxxxx> wrote:
>> In marvell platfrom, we handle gpio related behavior via rfkill,
>> 1. platfrom transfer gpio pin via platfrom data, so different platform
>> could have different gpio
>> 2. rfkill block/unblock wifi/bt etc, to pull up/down gpio.
>> 3. using rfkill to handle power saving mode
>
> SDIO core is designed to have full control over the card's power, and
> manipulates it upon boot (/card insertion), system suspend/resume
> (unless told not to), and when enabled, upon relevant runtime pm
> changes (driver loading/unloading/pm_runtime_* requests).
>
> If you require an external intervention to power on/off your card, how
> is this all going to work ?
>
> that's both cumbersome and error prone:
> 1. This external intervention might not always be there when you need it
> 2. This external intervention can possibly happen when you _don't_ need it
>
> In addition, it sounds like something you better off not having to
> maintain.. A solution that would just work within the MMC core is IMHO
> much better.
>
Thanks for suggestion, do you mean
Not use rfkill totally, which already integrated into bluetooth,
/net/bluetooth/hci_core.c
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?
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?
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
