wl1271: sdio: is fine-grained runtime_pm possible?

wl1271: sdio: is fine-grained runtime_pm possible?

[Chao Xu]

Hi,

The patch "SDIO Runtime PM Support" implements the pm for wl12xx
driver this way: the power for sdio is on whenever the WLAN interface
is on, and the power is down only when the interface is down.
Is it possible to do pm in a more fine-grained way, such as only
turning on the power when reading/writing through sdio? An example is
the mmc_blk_issue_rq() in drivers/mmc/card/block.c, where the host is
released when there are no more requests. And in turn the host driver,
such as omap_hsmmc.c, calls pm_runtime_put_autosuspend().
Is there any fundamental argument against doing fine-grained runtime
pm for sdio? Or is it just too much trouble for too little power
saved?
Thank you!
-- 
Regards,
Chao Xu

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Chris Ball]

Hi,

On Tue, Jan 14 2014, Chao Xu wrote:
> The patch "SDIO Runtime PM Support" implements the pm for wl12xx
> driver this way: the power for sdio is on whenever the WLAN interface
> is on, and the power is down only when the interface is down.
> Is it possible to do pm in a more fine-grained way, such as only
> turning on the power when reading/writing through sdio? An example is
> the mmc_blk_issue_rq() in drivers/mmc/card/block.c, where the host is
> released when there are no more requests. And in turn the host driver,
> such as omap_hsmmc.c, calls pm_runtime_put_autosuspend().
> Is there any fundamental argument against doing fine-grained runtime
> pm for sdio? Or is it just too much trouble for too little power
> saved?
> Thank you!

I feel like I must be missing something, but:

Network devices generate interrupts when you have new network activity
to process, and to generate an interrupt they need to be turned on.

How would you avoid having the WLAN device be unpowered while someone
is trying to talk to you?

- Chris.
-- 
Chris Ball   <chris@printf.net>   <http://printf.net/>

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Chao Xu]

Hi Chris,

Thank you for your comments!

I'm only familiar with OMAP4 chip. I can't speak for other devices.
AFAIK, if configured properly, even after pm_runtiem_put() is called,
sdio on OMAP4 can generate wake-up events when interrupts occur, so
that CPU _will_ receive the interrupts. So everything should work as
long as the driver calls pm_runtime_get() before handling the IRQ,
which involves reading/writing registers.

I'm not an expert about WLAN devices. But my understanding is wl1271
merely uses sdio as the way to talk to cpu. So turning off sdio
doesn't mean turning off the entire WLAN device, am I right? What I'm
suggesting here is turning off sdio when it's not used, not the entire
WLAN device.

Thanks again.

On Mon, Jan 13, 2014 at 9:27 PM, Chris Ball <chris@printf.net> wrote:
> Hi,
>
> On Tue, Jan 14 2014, Chao Xu wrote:
>> The patch "SDIO Runtime PM Support" implements the pm for wl12xx
>> driver this way: the power for sdio is on whenever the WLAN interface
>> is on, and the power is down only when the interface is down.
>> Is it possible to do pm in a more fine-grained way, such as only
>> turning on the power when reading/writing through sdio? An example is
>> the mmc_blk_issue_rq() in drivers/mmc/card/block.c, where the host is
>> released when there are no more requests. And in turn the host driver,
>> such as omap_hsmmc.c, calls pm_runtime_put_autosuspend().
>> Is there any fundamental argument against doing fine-grained runtime
>> pm for sdio? Or is it just too much trouble for too little power
>> saved?
>> Thank you!
>
> I feel like I must be missing something, but:
>
> Network devices generate interrupts when you have new network activity
> to process, and to generate an interrupt they need to be turned on.
>
> How would you avoid having the WLAN device be unpowered while someone
> is trying to talk to you?
>
> - Chris.
> --
> Chris Ball   <chris@printf.net>   <http://printf.net/>



-- 
Regards,
Chao Xu

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Ulf Hansson]

On 14 January 2014 05:46, Chao Xu <caesarxuchao@gmail.com> wrote:
> Hi Chris,
>
> Thank you for your comments!
>
> I'm only familiar with OMAP4 chip. I can't speak for other devices.
> AFAIK, if configured properly, even after pm_runtiem_put() is called,
> sdio on OMAP4 can generate wake-up events when interrupts occur, so
> that CPU _will_ receive the interrupts. So everything should work as
> long as the driver calls pm_runtime_get() before handling the IRQ,
> which involves reading/writing registers.

So, then it would be interesting to understand how the WLAN chip is
being powered? Can you tell us?

I would guess you have three entities of where runtime PM can be
interesting in these scenarios.

1. The sdio core layer uses runtime PM to let SDIO func drivers decide
whether the WLAN chip shall be powered or not.
mmc_sdio_runtime_suspend() and mmc_sdio_runtime_resume() are doing the
actual work for cutting and restoring the power.

2. The mmc host driver. Depending on hardware design; but very likely
you are able to handle runtime PM separate from the sdio core. The
important part is how you implement SDIO irqs. Since once your host
driver has put it's device into runtime suspend state, you can not
trust the controller to fetch the SDIO irqs. Some has solved this by
re-routing SDIO irq line (DAT1) to a GPIO irq while entering
runtime_suspend state, some have a complete separate line for SDIO irq
so the mmc controller don't need to bother about SDIO irqs at all.

For omap_hsmmc, I think runtime PM could be decoupled from the
host_ops->enable|disable, and instead use an autosuspend timeout,
similar how mmci is doing. Additionally, omap_hsmmc could likely do
clock gating in it ->runtime_suspend and ungating in it's
->runtime_resume, to save more power when inactive.

3. If the WLAN chip supports some kind of low power mode, those shall
be handled from the SDIO func driver. Depending on what mode it
supports it might be feasible to use runtime PM.


Maybe I missed some parts, that is outside my knowledge of existing
hardware designs.

Kind regards
Ulf Hansson

>
> I'm not an expert about WLAN devices. But my understanding is wl1271
> merely uses sdio as the way to talk to cpu. So turning off sdio
> doesn't mean turning off the entire WLAN device, am I right? What I'm
> suggesting here is turning off sdio when it's not used, not the entire
> WLAN device.
>
> Thanks again.
>
> On Mon, Jan 13, 2014 at 9:27 PM, Chris Ball <chris@printf.net> wrote:
>> Hi,
>>
>> On Tue, Jan 14 2014, Chao Xu wrote:
>>> The patch "SDIO Runtime PM Support" implements the pm for wl12xx
>>> driver this way: the power for sdio is on whenever the WLAN interface
>>> is on, and the power is down only when the interface is down.
>>> Is it possible to do pm in a more fine-grained way, such as only
>>> turning on the power when reading/writing through sdio? An example is
>>> the mmc_blk_issue_rq() in drivers/mmc/card/block.c, where the host is
>>> released when there are no more requests. And in turn the host driver,
>>> such as omap_hsmmc.c, calls pm_runtime_put_autosuspend().
>>> Is there any fundamental argument against doing fine-grained runtime
>>> pm for sdio? Or is it just too much trouble for too little power
>>> saved?
>>> Thank you!
>>
>> I feel like I must be missing something, but:
>>
>> Network devices generate interrupts when you have new network activity
>> to process, and to generate an interrupt they need to be turned on.
>>
>> How would you avoid having the WLAN device be unpowered while someone
>> is trying to talk to you?
>>
>> - Chris.
>> --
>> Chris Ball   <chris@printf.net>   <http://printf.net/>
>
>
>
> --
> Regards,
> Chao Xu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Chao Xu]

Thank you, Ulf. See below.

On Tue, Jan 14, 2014 at 2:36 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 14 January 2014 05:46, Chao Xu <caesarxuchao@gmail.com> wrote:
>> Hi Chris,
>>
>> Thank you for your comments!
>>
>> I'm only familiar with OMAP4 chip. I can't speak for other devices.
>> AFAIK, if configured properly, even after pm_runtiem_put() is called,
>> sdio on OMAP4 can generate wake-up events when interrupts occur, so
>> that CPU _will_ receive the interrupts. So everything should work as
>> long as the driver calls pm_runtime_get() before handling the IRQ,
>> which involves reading/writing registers.
>
> So, then it would be interesting to understand how the WLAN chip is
> being powered? Can you tell us?
>
I check the Pandaboard datasheet (Figure13. PandaBoard WLAN/Bluetooth
Interface Block Diagram). On the WLAN chip there is a WLAN_EN pin,
which is connected to a gpio. As long as that gpio pin is high, the
WLAN chip is powered on. So IMHO, powering up the WLAN chip is a
separate issue from powering up the sdio.
> I would guess you have three entities of where runtime PM can be
> interesting in these scenarios.
>
> 1. The sdio core layer uses runtime PM to let SDIO func drivers decide
> whether the WLAN chip shall be powered or not.
> mmc_sdio_runtime_suspend() and mmc_sdio_runtime_resume() are doing the
> actual work for cutting and restoring the power.
>
> 2. The mmc host driver. Depending on hardware design; but very likely
> you are able to handle runtime PM separate from the sdio core. The
> important part is how you implement SDIO irqs. Since once your host
> driver has put it's device into runtime suspend state, you can not
> trust the controller to fetch the SDIO irqs. Some has solved this by
> re-routing SDIO irq line (DAT1) to a GPIO irq while entering
> runtime_suspend state, some have a complete separate line for SDIO irq
> so the mmc controller don't need to bother about SDIO irqs at all.
>
OMAP4's spec also mentions that one should use GPIO to monitor the
state of DAT1 pin if the power domain is off. So my takeaway is that
through various tricks, SDIO irqs can be fetched when it's in runtime
suspend state. And thus we can enable fine-grain runtime PM in mmc
host driver, at least for omap_hsmmc.
> For omap_hsmmc, I think runtime PM could be decoupled from the
> host_ops->enable|disable, and instead use an autosuspend timeout,
> similar how mmci is doing. Additionally, omap_hsmmc could likely do
> clock gating in it ->runtime_suspend and ungating in it's
> ->runtime_resume, to save more power when inactive.
I take a quick look at mmci.c. Its runtime PM is what I think
fine-grain. But I get confused. Why doesn't mmci worry about missing
irq when it's powered off? Does it have a seperate sdio irq line as
you mentioned above?
> 3. If the WLAN chip supports some kind of low power mode, those shall
> be handled from the SDIO func driver. Depending on what mode it
> supports it might be feasible to use runtime PM.
>
Per Figure13 in Pandaboard datasheet, wl1271 uses GPIO53 as the
WLAN_IRQ. So it doesn't use sdio to interrupt cpu. So I think when
running on Pandaboard, the func driver can safely disable the sdio
when it's not reading/writing through sdio.
>
> Maybe I missed some parts, that is outside my knowledge of existing
> hardware designs.
>
> Kind regards
> Ulf Hansson
>
>>
>> I'm not an expert about WLAN devices. But my understanding is wl1271
>> merely uses sdio as the way to talk to cpu. So turning off sdio
>> doesn't mean turning off the entire WLAN device, am I right? What I'm
>> suggesting here is turning off sdio when it's not used, not the entire
>> WLAN device.
>>
>> Thanks again.
>>
>> On Mon, Jan 13, 2014 at 9:27 PM, Chris Ball <chris@printf.net> wrote:
>>> Hi,
>>>
>>> On Tue, Jan 14 2014, Chao Xu wrote:
>>>> The patch "SDIO Runtime PM Support" implements the pm for wl12xx
>>>> driver this way: the power for sdio is on whenever the WLAN interface
>>>> is on, and the power is down only when the interface is down.
>>>> Is it possible to do pm in a more fine-grained way, such as only
>>>> turning on the power when reading/writing through sdio? An example is
>>>> the mmc_blk_issue_rq() in drivers/mmc/card/block.c, where the host is
>>>> released when there are no more requests. And in turn the host driver,
>>>> such as omap_hsmmc.c, calls pm_runtime_put_autosuspend().
>>>> Is there any fundamental argument against doing fine-grained runtime
>>>> pm for sdio? Or is it just too much trouble for too little power
>>>> saved?
>>>> Thank you!
>>>
>>> I feel like I must be missing something, but:
>>>
>>> Network devices generate interrupts when you have new network activity
>>> to process, and to generate an interrupt they need to be turned on.
>>>
>>> How would you avoid having the WLAN device be unpowered while someone
>>> is trying to talk to you?
>>>
>>> - Chris.
>>> --
>>> Chris Ball   <chris@printf.net>   <http://printf.net/>
>>
>>
>>
>> --
>> Regards,
>> Chao Xu
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Regards,
Chao Xu

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Ulf Hansson]

>> So, then it would be interesting to understand how the WLAN chip is
>> being powered? Can you tell us?
>>
> I check the Pandaboard datasheet (Figure13. PandaBoard WLAN/Bluetooth
> Interface Block Diagram). On the WLAN chip there is a WLAN_EN pin,
> which is connected to a gpio. As long as that gpio pin is high, the
> WLAN chip is powered on. So IMHO, powering up the WLAN chip is a
> separate issue from powering up the sdio.

No, I don't think so. Or, well it depends on what you mean with sdio. :-)

In this case, I think the WLAN_EN pin should be converted to a gpio
regulator. The regulator should then be handled from omap_hsmmc's
->set_ios callback.

This will then mean, once the SDIO func driver drops is runtime PM
reference the power will be cut to the WLAN chip. I guess this is
handled internally by the SDIO func driver as of today, right?

>> I would guess you have three entities of where runtime PM can be
>> interesting in these scenarios.
>>
>> 1. The sdio core layer uses runtime PM to let SDIO func drivers decide
>> whether the WLAN chip shall be powered or not.
>> mmc_sdio_runtime_suspend() and mmc_sdio_runtime_resume() are doing the
>> actual work for cutting and restoring the power.
>>
>> 2. The mmc host driver. Depending on hardware design; but very likely
>> you are able to handle runtime PM separate from the sdio core. The
>> important part is how you implement SDIO irqs. Since once your host
>> driver has put it's device into runtime suspend state, you can not
>> trust the controller to fetch the SDIO irqs. Some has solved this by
>> re-routing SDIO irq line (DAT1) to a GPIO irq while entering
>> runtime_suspend state, some have a complete separate line for SDIO irq
>> so the mmc controller don't need to bother about SDIO irqs at all.
>>
> OMAP4's spec also mentions that one should use GPIO to monitor the
> state of DAT1 pin if the power domain is off. So my takeaway is that
> through various tricks, SDIO irqs can be fetched when it's in runtime
> suspend state. And thus we can enable fine-grain runtime PM in mmc
> host driver, at least for omap_hsmmc.

Agree. Just to be clear, we have two separate devices being controlled
with runtime PM.

The sdio/mmc/sd controller device owned by omap_hsmmc, which resides
in a power domain.

The card device which represents the WLAN-chip/SDIO card, controlled
by the mmc core and the SDIO func driver.

>> For omap_hsmmc, I think runtime PM could be decoupled from the
>> host_ops->enable|disable, and instead use an autosuspend timeout,
>> similar how mmci is doing. Additionally, omap_hsmmc could likely do
>> clock gating in it ->runtime_suspend and ungating in it's
>> ->runtime_resume, to save more power when inactive.
> I take a quick look at mmci.c. Its runtime PM is what I think
> fine-grain. But I get confused. Why doesn't mmci worry about missing
> irq when it's powered off? Does it have a seperate sdio irq line as
> you mentioned above?

cw1200 is a WLAN chip connected on the ux500 boards, which uses mmci.
The cw1200 chip has in this case a separate SDIO irq line. Since this
is outside the SDIO spec, it makes more sense to handle this from the
SDIO func driver.

That is also why we never added SDIO irq support for mmci.

>> 3. If the WLAN chip supports some kind of low power mode, those shall
>> be handled from the SDIO func driver. Depending on what mode it
>> supports it might be feasible to use runtime PM.
>>
> Per Figure13 in Pandaboard datasheet, wl1271 uses GPIO53 as the
> WLAN_IRQ. So it doesn't use sdio to interrupt cpu. So I think when
> running on Pandaboard, the func driver can safely disable the sdio
> when it's not reading/writing through sdio.

Does it mean that DAT1 can be re-routed to GPIO53 or does it mean that
the WLAN chip has a separate line for SDIO irqs?

I am not sure what you mean by disable sdio here? Could you elaborate?
Maybe use the word "device" instead?

KInd regards
Ulf Hansson

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Chao Xu]

Hi Ulf,
My apology for the late reply.

On Wed, Jan 15, 2014 at 4:46 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> No, I don't think so. Or, well it depends on what you mean with sdio. :-)
>
> In this case, I think the WLAN_EN pin should be converted to a gpio
> regulator. The regulator should then be handled from omap_hsmmc's
> ->set_ios callback.
I checked the codes and confirmed this. pm_runtime_get/put(&func->dev)
will end up at the ->set_ios callback. But I failed to find the codes
that convert the WLAN_EN pin to a gpio regulator. Could you provide
any hint?
> This will then mean, once the SDIO func driver drops is runtime PM
> reference the power will be cut to the WLAN chip. I guess this is
> handled internally by the SDIO func driver as of today, right?
>
Agree. I realized my words had been ambiguous. Hope I got it right this time:-)
As you mentioned, there are two devices. The sdio/mmc/sd sdio
controller device, which is abstracted as a "host" in codes. And the
WLAN card, which is abstracted as a "sdio func". Calling
pm_runtime_put(&func->dev) will power off the WLAN chip. But calling
pm_runtime_put(host->dev) will NOT power off the WLAN chip, am I
right?

>> OMAP4's spec also mentions that one should use GPIO to monitor the
>> state of DAT1 pin if the power domain is off. So my takeaway is that
>> through various tricks, SDIO irqs can be fetched when it's in runtime
>> suspend state. And thus we can enable fine-grain runtime PM in mmc
>> host driver, at least for omap_hsmmc.
>
> Agree. Just to be clear, we have two separate devices being controlled
> with runtime PM.
>
> The sdio/mmc/sd controller device owned by omap_hsmmc, which resides
> in a power domain.
>
So provided the SDIO irqs are handled properly, it's possible to
enable fine-grain runtime PM on sdio/mmc/sd controller device, e.g.,
pm_runtime_put(host->dev) when there is no communication between
WLAN-chip and SDIO controller device.
> The card device which represents the WLAN-chip/SDIO card, controlled
> by the mmc core and the SDIO func driver.
>
We shall NOT call pm_runtime_put(&func->dev) even if the WLAN-chip is
not tx/rx packets. Because otherwise the WLAN-chip will be powered off
and incoming packets will be lost.

>>> 3. If the WLAN chip supports some kind of low power mode, those shall
>>> be handled from the SDIO func driver. Depending on what mode it
>>> supports it might be feasible to use runtime PM.
>>>
>> Per Figure13 in Pandaboard datasheet, wl1271 uses GPIO53 as the
>> WLAN_IRQ. So it doesn't use sdio to interrupt cpu. So I think when
>> running on Pandaboard, the func driver can safely disable the sdio
>> when it's not reading/writing through sdio.
>
> Does it mean that DAT1 can be re-routed to GPIO53 or does it mean that
> the WLAN chip has a separate line for SDIO irqs?
I'm not sure. The Figure shows the SDIO_D1 pin of the WLAN-chip is
connected to the SDMMC5_DAT1 of OMAP. And there is a separate WLAN_IRQ
pin on WLAN-chip which connects to GPIO53. I guess this means it's a
separate line?
> I am not sure what you mean by disable sdio here? Could you elaborate?
> Maybe use the word "device" instead?
I mean the SDIO controller device:-)
>
> KInd regards
> Ulf Hansson

Regards,
Chao Xu

Re: wl1271: sdio: is fine-grained runtime_pm possible?

[Ulf Hansson]

On 18 January 2014 23:44, Chao Xu <caesarxuchao@gmail.com> wrote:
> Hi Ulf,
> My apology for the late reply.
>
> On Wed, Jan 15, 2014 at 4:46 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> No, I don't think so. Or, well it depends on what you mean with sdio. :-)
>>
>> In this case, I think the WLAN_EN pin should be converted to a gpio
>> regulator. The regulator should then be handled from omap_hsmmc's
>> ->set_ios callback.
> I checked the codes and confirmed this. pm_runtime_get/put(&func->dev)
> will end up at the ->set_ios callback. But I failed to find the codes
> that convert the WLAN_EN pin to a gpio regulator. Could you provide
> any hint?

I am not sure this has been done yet, so if it hasn't, there is a good
reason to convert it.

>> This will then mean, once the SDIO func driver drops is runtime PM
>> reference the power will be cut to the WLAN chip. I guess this is
>> handled internally by the SDIO func driver as of today, right?
>>
> Agree. I realized my words had been ambiguous. Hope I got it right this time:-)
> As you mentioned, there are two devices. The sdio/mmc/sd sdio
> controller device, which is abstracted as a "host" in codes. And the
> WLAN card, which is abstracted as a "sdio func". Calling
> pm_runtime_put(&func->dev) will power off the WLAN chip. But calling
> pm_runtime_put(host->dev) will NOT power off the WLAN chip, am I
> right?

Actually in the SDIO case there are three struct devices.

1) The sdio card device, attached to the mmc bus.
2) The sdio func device, which has the sdio card device as parent, and
is attached to the sdio bus.
3) The host device.

1) and 2) are connected, since there are a parent/child relation chip.
If the sdio func device's runtime PM reference gets increased
(pm_runtime_get_sync), the runtime PM core will make sure it's parent
device will be runtime resumed as well. Typically the sdio func driver
will operate on 2), which means it can control whether the SDIO card
(WLAN chip) needs power or not.

3) is handled separate from the other, and should handle it's own
runtime PM resources.

>
>>> OMAP4's spec also mentions that one should use GPIO to monitor the
>>> state of DAT1 pin if the power domain is off. So my takeaway is that
>>> through various tricks, SDIO irqs can be fetched when it's in runtime
>>> suspend state. And thus we can enable fine-grain runtime PM in mmc
>>> host driver, at least for omap_hsmmc.
>>
>> Agree. Just to be clear, we have two separate devices being controlled
>> with runtime PM.
>>
>> The sdio/mmc/sd controller device owned by omap_hsmmc, which resides
>> in a power domain.
>>
> So provided the SDIO irqs are handled properly, it's possible to
> enable fine-grain runtime PM on sdio/mmc/sd controller device, e.g.,
> pm_runtime_put(host->dev) when there is no communication between
> WLAN-chip and SDIO controller device.
>> The card device which represents the WLAN-chip/SDIO card, controlled
>> by the mmc core and the SDIO func driver.
>>
> We shall NOT call pm_runtime_put(&func->dev) even if the WLAN-chip is
> not tx/rx packets. Because otherwise the WLAN-chip will be powered off
> and incoming packets will be lost.

Correct.

As stated earlier, you may also want the WLAN driver to put the WLAN
chip in some specific low power mode. Obviously it still need to keep
listen for irq for incoming packets as long as the wlan interface is
up.

>
>>>> 3. If the WLAN chip supports some kind of low power mode, those shall
>>>> be handled from the SDIO func driver. Depending on what mode it
>>>> supports it might be feasible to use runtime PM.
>>>>
>>> Per Figure13 in Pandaboard datasheet, wl1271 uses GPIO53 as the
>>> WLAN_IRQ. So it doesn't use sdio to interrupt cpu. So I think when
>>> running on Pandaboard, the func driver can safely disable the sdio
>>> when it's not reading/writing through sdio.
>>
>> Does it mean that DAT1 can be re-routed to GPIO53 or does it mean that
>> the WLAN chip has a separate line for SDIO irqs?
> I'm not sure. The Figure shows the SDIO_D1 pin of the WLAN-chip is
> connected to the SDMMC5_DAT1 of OMAP. And there is a separate WLAN_IRQ
> pin on WLAN-chip which connects to GPIO53. I guess this means it's a
> separate line?
>> I am not sure what you mean by disable sdio here? Could you elaborate?
>> Maybe use the word "device" instead?
> I mean the SDIO controller device:-)
>>
>> KInd regards
>> Ulf Hansson
>
> Regards,
> Chao Xu