* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Nicolas Pitre @ 2010-07-06 1:45 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, Andrew Morton,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-6-git-send-email-ohad@wizery.com>
On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Add support for software emulation of card detect
> events.
>
> This is required for specific controllers
> that are hard wired with embedded SDIO devices
> (such as TI's wl1271 WLAN device).
Why?
Many instances of hardwired SDIO based WLAN devices do exist already,
and they don't need extra card detect events to be generated. The core
MMC code already triggers a probe for cards whenever a new host
controller is registered.
> Board-specific configuration is required to
> enable this software card detect control.
Could you elaborate please?
Nicolas
^ permalink raw reply
* Re: [ath9k] ath9k: Expose virtual wiphy indexes to debugfs.
From: Vasanthakumar Thiagarajan @ 2010-07-06 4:59 UTC (permalink / raw)
To: greearb@gmail.com; +Cc: linux-wireless@vger.kernel.org, Ben Greear
In-Reply-To: <1278359545-29013-1-git-send-email-greearb@candelatech.com>
On Tue, Jul 06, 2010 at 01:22:25AM +0530, greearb@gmail.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> It is very difficult to map phyX devices to real/virtual
> entities because the phyX devices change on module
> reload. This patch makes it slightly easier to
> associate virtual phy devices with phyX entities.
>
It does not make much sense to give an index while creating a new
virtual wiphy interface. This is unncessary, only wiphy name
matters.
Vasanth
^ permalink raw reply
* Re: [ath9k] ath9k: Expose virtual wiphy indexes to debugfs.
From: Ben Greear @ 2010-07-06 5:15 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: greearb@gmail.com, linux-wireless@vger.kernel.org
In-Reply-To: <20100706045945.GF5053@vasanth-laptop>
On 07/05/2010 09:59 PM, Vasanthakumar Thiagarajan wrote:
> On Tue, Jul 06, 2010 at 01:22:25AM +0530, greearb@gmail.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> It is very difficult to map phyX devices to real/virtual
>> entities because the phyX devices change on module
>> reload. This patch makes it slightly easier to
>> associate virtual phy devices with phyX entities.
>>
>
> It does not make much sense to give an index while creating a new
> virtual wiphy interface. This is unncessary, only wiphy name
> matters.
Will the underlying code allow you to specify a phy name though? It
seems to me that once a phyX is used, you cannot have a new phy
with that name again, even if the old one has been unloaded:
modprobe ath9k
rmmod ath9k
modprobe ath9k, and the now it's using phy1 instead of phy0,
and you cannot even rename the phy1 to phy0 with 'iw'.
It would be great if phy names were reusable like network
device names, but I'm guessing that must be difficult or
it would already be like that.
For virtual PHYs at least, the parent phy and index is a unique
identifier, so it sort of helps work around the phy naming
issues.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k] ath9k: Expose virtual wiphy indexes to debugfs.
From: Vasanthakumar Thiagarajan @ 2010-07-06 6:18 UTC (permalink / raw)
To: Ben Greear
Cc: Vasanth Thiagarajan, greearb@gmail.com,
linux-wireless@vger.kernel.org
In-Reply-To: <4C32BBF4.9090907@candelatech.com>
On Tue, Jul 06, 2010 at 10:45:32AM +0530, Ben Greear wrote:
> On 07/05/2010 09:59 PM, Vasanthakumar Thiagarajan wrote:
> > On Tue, Jul 06, 2010 at 01:22:25AM +0530, greearb@gmail.com wrote:
> >> From: Ben Greear<greearb@candelatech.com>
> >>
> >> It is very difficult to map phyX devices to real/virtual
> >> entities because the phyX devices change on module
> >> reload. This patch makes it slightly easier to
> >> associate virtual phy devices with phyX entities.
> >>
> >
> > It does not make much sense to give an index while creating a new
> > virtual wiphy interface. This is unncessary, only wiphy name
> > matters.
>
> Will the underlying code allow you to specify a phy name though? It
> seems to me that once a phyX is used, you cannot have a new phy
> with that name again, even if the old one has been unloaded
Driver has nothing to do with assigning phy names. This is done in
cfg80211.
Vasanth
^ permalink raw reply
* Re: [PATCH 02/15] wireless: wl1271: remove SDIO IDs from driver
From: Luciano Coelho @ 2010-07-06 7:04 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
akpm@linux-foundation.org, San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-3-git-send-email-ohad@wizery.com>
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Remove SDIO IDs from the driver code since now it is
> included in linux/mmc/sdio_ids.h.
>
> Signed-off-by: Ohad Ben-Cohen <ohadb@ti.com>
> ---
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 10/15] wireless: wl1271: support return value for the set power func
From: Luciano Coelho @ 2010-07-06 7:11 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
akpm@linux-foundation.org, San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-11-git-send-email-ohad@wizery.com>
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Make it possible for the set power method to indicate a
> success/failure return value. This is needed to support
> more complex power on/off operations such as bringing up
> (and down) sdio functions.
>
> Signed-off-by: Ohad Ben-Cohen <ohadb@ti.com>
> ---
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 08/15] wireless: wl1271: make wl12xx.h common to both spi and sdio
From: Luciano Coelho @ 2010-07-06 7:08 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
akpm@linux-foundation.org, San Mehat, Ohad Ben-Cohen, kalle.valo
In-Reply-To: <1278376666-3509-9-git-send-email-ohad@wizery.com>
On Tue, 2010-07-06 at 02:37 +0200, ext Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Move wl12xx.h outside of the spi-specific location,
> so it can be shared with both spi and sdio solutions.
>
> Signed-off-by: Ohad Ben-Cohen <ohadb@ti.com>
> ---
> drivers/net/wireless/wl12xx/wl1251_sdio.c | 2 +-
> drivers/net/wireless/wl12xx/wl1251_spi.c | 2 +-
> drivers/net/wireless/wl12xx/wl1271_spi.c | 2 +-
> include/linux/spi/wl12xx.h | 34
> -----------------------------
> include/linux/wl12xx.h | 34
> +++++++++++++++++++++++++++++
> 5 files changed, 37 insertions(+), 37 deletions(-)
> delete mode 100644 include/linux/spi/wl12xx.h
> create mode 100644 include/linux/wl12xx.h
For the wl1271 part:
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
For the wl12xx.h and wl1251 parts, this needs to be acked by Kalle Valo.
--
Cheers,
Luca.
^ permalink raw reply
* Re: ath9k doesn't clean up virtual wifis on rmmod, and crashes.
From: Rajkumar Manoharan @ 2010-07-06 8:36 UTC (permalink / raw)
To: Ben Greear; +Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org
In-Reply-To: <4C322B26.7080701@candelatech.com>
On Tue, Jul 06, 2010 at 12:27:42AM +0530, Ben Greear wrote:
> I ran the same test on wireless-testing, and it still crashes.
>
> It appears that the patch you sent is already in wireless-testing,
> so I did not apply it.
>
> [root@atom ~]# uname -a
> Linux atom 2.6.35-rc3-wl+ #1 SMP Mon Jul 5 11:36:08 PDT 2010 i686 i686 i386 GNU/Linux
> [root@atom ~]# echo add > /debug/ath9k/phy0/wiphy
> Jul 5 11:54:59 atom kernel: phy1: Selected rate control algorithm 'ath9k_rate_control'
> [root@atom ~]# rmmod ath9k
> BUG: unable to handle kernel NULL pointer dereference at 000000a4
> IP: [<f8d455d6>] ath9k_hw_intrpend+0x6/0x49 [ath9k_hw]
> *pde = 00000000
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:05:00.0/net/wlan1/flags
> Modules linked in: xt_CT iptable_raw ipt_addrtype xt_DSCP xt_dscp xt_string xt_owner xt_NFQUEUE xt_mul]
>
> Pid: 5817, comm: rmmod Not tainted 2.6.35-rc3-wl+ #1 To be filled by O.E.M./To Be Filled By O.E.M.
> EIP: 0060:[<f8d455d6>] EFLAGS: 00010046 CPU: 0
> EIP is at ath9k_hw_intrpend+0x6/0x49 [ath9k_hw]
> EAX: 00000000 EBX: 00000000 ECX: c08de3bc EDX: f705ec78
> ESI: f705ec78 EDI: 00000010 EBP: f4563e70 ESP: f4563e6c
> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process rmmod (pid: 5817, ti=f4562000 task=f4504550 task.ti=f4562000)
> Stack:
> 00000000 f4563e88 f8de3cb4 00000010 f6aab6c0 00000282 00000010 f4563ea8
> <0> c046d228 f705ec78 00000282 c08de3bc 00000010 c08de380 f705ec78 f4563ebc
> <0> c046d28f f705ec78 f7113000 f8f00000 f4563ed0 f8dea27f f7113000 f8def9a8
> Call Trace:
> [<f8de3cb4>] ? ath_isr+0x25/0x189 [ath9k]
> [<c046d228>] ? __free_irq+0x11e/0x15e
> [<c046d28f>] ? free_irq+0x27/0x3a
> [<f8dea27f>] ? ath_pci_remove+0x2f/0x54 [ath9k]
> [<c05816da>] ? pci_device_remove+0x19/0x39
> [<c06036d6>] ? __device_release_driver+0x59/0x9d
> [<c0603781>] ? driver_detach+0x67/0x85
> [<c0602c9d>] ? bus_remove_driver+0x69/0x85
> [<c0603b92>] ? driver_unregister+0x4b/0x52
> [<c05818a9>] ? pci_unregister_driver+0x2d/0x6e
> [<f8dea171>] ? ath_pci_exit+0xd/0xf [ath9k]
> [<f8dec664>] ? ath9k_exit+0x8/0x2f [ath9k]
> [<c0455232>] ? sys_delete_module+0x16f/0x1c0
> [<c07458dc>] ? do_page_fault+0x26a/0x2c5
> [<c074590a>] ? do_page_fault+0x298/0x2c5
> [<c0402fdc>] ? sysenter_do_call+0x12/0x28
> Code: 80 4b 06 10 31 c9 83 c4 68 89 c8 5b 5e 5f 5d c3 55 b9 0c 00 00 00 89 e5 53 8b 98 94 00 00 00 ff
> EIP: [<f8d455d6>] ath9k_hw_intrpend+0x6/0x49 [ath9k_hw] SS:ESP 0068:f4563e6c
> CR2: 00000000000000a4
> ---[ end trace 43bc6f57caff1689 ]---
> Killed
Can you please try this patch?
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index fe730cb..243c177 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -787,12 +787,12 @@ void ath9k_deinit_device(struct ath_softc *sc)
ieee80211_unregister_hw(aphy->hw);
ieee80211_free_hw(aphy->hw);
}
- kfree(sc->sec_wiphy);
ieee80211_unregister_hw(hw);
ath_rx_cleanup(sc);
ath_tx_cleanup(sc);
ath9k_deinit_softc(sc);
+ kfree(sc->sec_wiphy);
}
void ath_descdma_cleanup(struct ath_softc *sc,
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 4c0831f..a6b6af2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1264,6 +1264,7 @@ static void ath9k_stop(struct ieee80211_hw *hw)
struct ath_softc *sc = aphy->sc;
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
+ int i;
mutex_lock(&sc->mutex);
@@ -1276,11 +1277,15 @@ static void ath9k_stop(struct ieee80211_hw *hw)
cancel_work_sync(&sc->paprd_work);
cancel_work_sync(&sc->hw_check_work);
- if (!sc->num_sec_wiphy) {
+ for (i = 0; i < sc->num_sec_wiphy; i++) {
+ if (sc->sec_wiphy[i])
+ break;
+ }
+
+ if (i == sc->num_sec_wiphy) {
cancel_delayed_work_sync(&sc->wiphy_work);
cancel_work_sync(&sc->chan_work);
}
-
if (sc->sc_flags & SC_OP_INVALID) {
ath_print(common, ATH_DBG_ANY, "Device not present\n");
mutex_unlock(&sc->mutex);
---
Rajkumar
^ permalink raw reply related
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-06 8:53 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-12-git-send-email-ohad@wizery.com>
Hi,
On 07/06/2010 03:37 AM, ext Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen<ohadb@ti.com>
>
> Introduce a platform device support which is decoupled
> from the life cycle of the sdio function.
>
> The platform device objective is to deliver board-specific
> values (like irq, ref_clock, and software card-detect
> emulation control).
>
> The driver can then dynamically create (or destroy)
> the sdio function whenever the wlan interface is
> brought up (or down), as part of the power() operation.
Is this the right approach? Why should you emulate a card disconnect event when
the wlan interface is brought down?
Physically the card is never disconnected. So I don't see why we should fake it.
Could you please explain why you need to do this?
br,
-roger
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Ohad Ben-Cohen @ 2010-07-06 9:30 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <4C32EF19.1000604@nokia.com>
Hi Roger,
On Tue, Jul 6, 2010 at 11:53 AM, Roger Quadros <roger.quadros@nokia.com> wrote:
> Could you please explain why you need to do this?
To minimize power consumption when the wlan device is not in use, we
would like to keep the device powered off as long as the interface is
down, and only power it on when the user brings up the interface.
Whenever the chip is powered on, it must be initialized and
reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait
for that phase to successfully complete (essentially waiting for the
sdio_driver's probe function to be called).
To make sure this SDIO init step occurs correctly every time we toggle
the device's power back on, and to prevent potential races, we also
have to make sure that the sdio function is removed every time we
power off the chip (the driver waits for the sdio_driver's remove
function to be called).
That's why we let the mmc layer think that the card is removed:
physically it is still there, but for all practical purposes it is
really removed, because once you power off the chip, you must
reinitialize it again next time you power it on, as if the card was
really removed and re-inserted.
Thanks,
Ohad.
>
> br,
> -roger
>
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen @ 2010-07-06 10:22 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, Andrew Morton,
San Mehat, Pandita, Vikram
In-Reply-To: <alpine.LFD.2.00.1007052134460.6020@xanadu.home>
Hi Nicolas,
On Tue, Jul 6, 2010 at 4:45 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote:
>
>> From: Ohad Ben-Cohen <ohadb@ti.com>
>>
>> Add support for software emulation of card detect
>> events.
>>
>> This is required for specific controllers
>> that are hard wired with embedded SDIO devices
>> (such as TI's wl1271 WLAN device).
>
> Why?
>
> Many instances of hardwired SDIO based WLAN devices do exist already,
> and they don't need extra card detect events to be generated. The core
> MMC code already triggers a probe for cards whenever a new host
> controller is registered.
We prefer not to power up the chip as early as boot time; instead, we
would like to have it powered off until the wlan interface is brought
up, power it on when the interface is brought up,
and power it off again as soon as the interface is brought down again
(to minimize power consumption when the wlan is not in use).
For that we can't rely on the probing done when the controller is
registered, we want to have a mechanism to allow dynamic detection and
removal of the card.
Note: the wl1271 device does support standard card detection, but
AFAIK there's a limitation to use that with the specific omap
controller the device is hardwired to. I will try to get more info
about that, but probably Madhu can comment on that better.
>> Board-specific configuration is required to
>> enable this software card detect control.
>
> Could you elaborate please?
Please check out the last patch - that patch is doing that configuration.
In essence, this virtual card detect mechanism is enabled only for
specific controllers which we know there's an embedded sdio device
hardwired to. This knowledge is board-specific, and that's why we
enable this mechanism in the board files, per a specific mmc
controller.
Thanks,
Ohad.
>
>
> Nicolas
>
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-06 10:35 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <AANLkTintIz-N7MwwtqhVq2LR3Ln5JTNYSbJUBSSClcA-@mail.gmail.com>
Hi Ohad,
On 07/06/2010 12:30 PM, ext Ohad Ben-Cohen wrote:
> Hi Roger,
>
> On Tue, Jul 6, 2010 at 11:53 AM, Roger Quadros<roger.quadros@nokia.com> wrote:
>> Could you please explain why you need to do this?
>
> To minimize power consumption when the wlan device is not in use, we
> would like to keep the device powered off as long as the interface is
> down, and only power it on when the user brings up the interface.
>
Agreed.
> Whenever the chip is powered on, it must be initialized and
> reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait
> for that phase to successfully complete (essentially waiting for the
> sdio_driver's probe function to be called).
>
> To make sure this SDIO init step occurs correctly every time we toggle
> the device's power back on, and to prevent potential races, we also
> have to make sure that the sdio function is removed every time we
> power off the chip (the driver waits for the sdio_driver's remove
> function to be called).
>
> That's why we let the mmc layer think that the card is removed:
> physically it is still there, but for all practical purposes it is
> really removed, because once you power off the chip, you must
> reinitialize it again next time you power it on, as if the card was
> really removed and re-inserted.
>
My point is that shouldn't this be handled by SDIO core?
If there are no users for the SDIO function and the card, doesn't the SDIO core
power down the slot, and take care of re-initialization when it is powered up?
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Roger Quadros @ 2010-07-06 11:02 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: Nicolas Pitre, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), Andrew Morton, San Mehat,
Pandita, Vikram
In-Reply-To: <AANLkTim4E4LlFERmfYA1M0HLBOoRAsQuvdW6QBNu6pC0@mail.gmail.com>
On 07/06/2010 01:22 PM, ext Ohad Ben-Cohen wrote:
> Hi Nicolas,
>
> On Tue, Jul 6, 2010 at 4:45 AM, Nicolas Pitre<nico@fluxnic.net> wrote:
>> On Tue, 6 Jul 2010, Ohad Ben-Cohen wrote:
>>
>>> From: Ohad Ben-Cohen<ohadb@ti.com>
>>>
>>> Add support for software emulation of card detect
>>> events.
>>>
>>> This is required for specific controllers
>>> that are hard wired with embedded SDIO devices
>>> (such as TI's wl1271 WLAN device).
>>
>> Why?
>>
>> Many instances of hardwired SDIO based WLAN devices do exist already,
>> and they don't need extra card detect events to be generated. The core
>> MMC code already triggers a probe for cards whenever a new host
>> controller is registered.
>
> We prefer not to power up the chip as early as boot time; instead, we
Why? if the card is hard wired with no card detect then it should be powered up.
The function driver should power it down later if required. no?
> would like to have it powered off until the wlan interface is brought
> up, power it on when the interface is brought up,
If it was powered OFF then how did the wlan interface come into picture?
> and power it off again as soon as the interface is brought down again
> (to minimize power consumption when the wlan is not in use).
I agree, we some how need to power down the card when not in use in the right way.
^ permalink raw reply
* Re: [PATCH] wl1251: Use MODULE_ALIAS macro at correct postion for SPI bus
From: Luciano Coelho @ 2010-07-06 11:09 UTC (permalink / raw)
To: Palande Ameya (Nokia-MS/Helsinki)
Cc: linux-wireless@vger.kernel.org, kalle.valo@iki.fi,
Oikarinen Juuso (Nokia-MS/Tampere)
In-Reply-To: <1278339158-10414-1-git-send-email-ameya.palande@nokia.com>
On Mon, 2010-07-05 at 16:12 +0200, Palande Ameya (Nokia-MS/Helsinki)
wrote:
> Signed-off-by: Ameya Palande <ameya.palande@nokia.com>
> ---
For the wl1271 part:
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 06/15] omap zoom2: wlan board muxing
From: Tony Lindgren @ 2010-07-06 11:43 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, akpm,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-7-git-send-email-ohad@wizery.com>
* Ohad Ben-Cohen <ohad@wizery.com> [100706 03:37]:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Add board muxing to support the wlan wl1271 chip that is
> hardwired to mmc2 (third mmc controller) on the ZOOM2.
I'll pick this and following patch into omap for-next.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen @ 2010-07-06 11:48 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
Chikkature Rajashekar Madhusudhan, Luciano Coelho, Andrew Morton,
San Mehat, Pandita, Vikram
In-Reply-To: <AANLkTim4E4LlFERmfYA1M0HLBOoRAsQuvdW6QBNu6pC0@mail.gmail.com>
On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Note: the wl1271 device does support standard card detection, but
> AFAIK there's a limitation to use that with the specific omap
> controller the device is hardwired to. I will try to get more info
> about that, but probably Madhu can comment on that better.
Some correction and additional info:
The wl1271 device has an issue which makes the standard card detect
mechanism irrelevant: it is always up, even if the power enable gpio
input of the device is down (the power enable input does not supply
the power to the chip, it's just logical digital high/low input upon
which the device reacts). That's why we must use software control for
emulating card detect with that device.
In addition, as far as I could find out, the card detect mechanism on
the ZOOM is implemented by mechanical means, and thus is not relevant
for hardwired embedded SDIO devices (I'm not even sure card detect is
supported for the 3rd mmc controller).
^ permalink raw reply
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-07-06 11:55 UTC (permalink / raw)
To: Pazzo Da Legare; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimcFgxOmw4oOa28unhmSpTt0jNacFKXRXycKKA9@mail.gmail.com>
> Did you have any news about nvs file? I wrote an email to driver's
> mantaneir too,
Hi,
Still pushing to get access to the files it TI. I hope I will have something e\o the week.
Regards,
Shahar
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen @ 2010-07-06 12:02 UTC (permalink / raw)
To: Roger Quadros
Cc: Nicolas Pitre, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), Andrew Morton, San Mehat,
Pandita, Vikram
In-Reply-To: <4C330D37.4090104@nokia.com>
On Tue, Jul 6, 2010 at 2:02 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> On 07/06/2010 01:22 PM, ext Ohad Ben-Cohen wrote:
>> We prefer not to power up the chip as early as boot time; instead, we
>
> Why?
Let's say you boot your device but never use WLAN.
In this scenario, we prefer the wl1271 device to stay powered off to
minimize power consumption.
This way we will power on the wl1271 device only when the user
actually turns WLAN on.
> The function driver should power it down later if required. no?
Care to explain this ? I'm not sure I'm following: the sdio function
is added and the sdio driver is probed only after you power on the
wl1271 device and let the mmc layer initialize and configure it. Why
would you want to do that if WLAN is disabled (i.e. user didn't turn
wlan on) ?
> If it was powered OFF then how did the wlan interface come into picture?
As soon as you insmod wl1271 and wl1271_sdio, you will have a wlan
interface (which is still down). At this point the wl1271 device is
still powered off and not consuming power.
If the user chooses to enable wlan (i.e. ifconfig wlan0 up), the chip
is powered on, it is initialized and configured by the mmc layer, and
then it can be used for WLAN activities.
> I agree, we some how need to power down the card when not in use in the
> right way.
In this patchset proposal, as soon as the user disables wlan (i.e.
ifconfig wlan0 down), the wl1271 device is powered off, and the
corresponding sdio function is removed.
Thanks,
Ohad.
^ permalink raw reply
* Re: ath9k doesn't clean up virtual wifis on rmmod, and crashes.
From: Ben Greear @ 2010-07-06 12:05 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org
In-Reply-To: <20100706083621.GA11134@vmraj-laptop>
On 07/06/2010 01:36 AM, Rajkumar Manoharan wrote:
> On Tue, Jul 06, 2010 at 12:27:42AM +0530, Ben Greear wrote:
>> I ran the same test on wireless-testing, and it still crashes.
>>
>> It appears that the patch you sent is already in wireless-testing,
>> so I did not apply it.
> Can you please try this patch?
That patch appears to fix the problem. I was able to rmmod
ath9k after adding a virtual phy and no crashes. It used to
immediately crash every time.
I'll do some more testing later today if all goes according to plan.
Thanks!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ath: Fix uninitialized variable warnings [v2]
From: Prarit Bhargava @ 2010-07-06 12:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Pavel Roskin, ath9k-devel, linville
In-Reply-To: <1278165872.6710.1.camel@mj>
On 07/03/2010 10:04 AM, Pavel Roskin wrote:
> On Thu, 2010-07-01 at 12:09 -0400, Prarit Bhargava wrote:
>> Fix 'make CONFIG_DEBUG_SECTION_MISMATCH=y' warning:
>
> I don't think the warnings you are fixing have anything to do with
> CONFIG_DEBUG_SECTION_MISMATCH.
>
>> drivers/net/wireless/mwl8k.c: In function 'mwl8k_bss_info_changed_sta':
>> drivers/net/wireless/mwl8k.c:3404: warning: 'ap_legacy_rates' may be used uninitialized in this function
>
> The patch doesn't appear to touch mwl8k.c at all.
>
> Please fix the description.
New patch with updated description.
P.
Fix 'make CONFIG_DEBUG_SECTION_MISMATCH=y' warning:
drivers/net/wireless/ath/ath9k/eeprom_4k.c: In function 'ath9k_hw_get_4k_gain_boundaries_pdadcs.clone.1':
drivers/net/wireless/ath/ath9k/eeprom_4k.c:310: warning: 'minPwrT4' may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/eeprom_def.c: In function 'ath9k_hw_get_def_gain_boundaries_pdadcs.clone.0':
drivers/net/wireless/ath/ath9k/eeprom_def.c:677: warning: 'minPwrT4' may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/eeprom_9287.c: In function 'ath9k_hw_get_AR9287_gain_boundaries_pdadcs':
drivers/net/wireless/ath/ath9k/eeprom_9287.c:301: warning: 'minPwrT4' may be used uninitialized in this function
Pavel pointed out that tMinCalPower or pMinCalPower isn't used anywhere, so
the simplest way to fix these warnings is to get rid of the code.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index 41a77d1..393f8c5 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_4k.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
@@ -222,7 +222,7 @@ static void ath9k_hw_get_4k_gain_boundaries_pdadcs(struct ath_hw *ah,
struct ath9k_channel *chan,
struct cal_data_per_freq_4k *pRawDataSet,
u8 *bChans, u16 availPiers,
- u16 tPdGainOverlap, int16_t *pMinCalPower,
+ u16 tPdGainOverlap,
u16 *pPdGainBoundaries, u8 *pPDADCValues,
u16 numXpdGains)
{
@@ -307,8 +307,6 @@ static void ath9k_hw_get_4k_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
-
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -398,7 +396,6 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw *ah,
static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_EEP4K_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
- int16_t tMinCalPower;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR5416_EEP4K_NUM_PD_GAINS] = { 0, 0 };
u32 reg32, regOffset, regChainOffset;
@@ -451,7 +448,7 @@ static void ath9k_hw_set_4k_power_cal_table(struct ath_hw *ah,
ath9k_hw_get_4k_gain_boundaries_pdadcs(ah, chan,
pRawDataset, pCalBChans,
numPiers, pdGainOverlap_t2,
- &tMinCalPower, gainBoundaries,
+ gainBoundaries,
pdadcValues, numXpdGain);
ENABLE_REGWRITE_BUFFER(ah);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index b471db5..6d6b1c5 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -219,7 +219,7 @@ static void ath9k_hw_get_AR9287_gain_boundaries_pdadcs(struct ath_hw *ah,
struct ath9k_channel *chan,
struct cal_data_per_freq_ar9287 *pRawDataSet,
u8 *bChans, u16 availPiers,
- u16 tPdGainOverlap, int16_t *pMinCalPower,
+ u16 tPdGainOverlap,
u16 *pPdGainBoundaries, u8 *pPDADCValues,
u16 numXpdGains)
{
@@ -298,7 +298,6 @@ static void ath9k_hw_get_AR9287_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -448,7 +447,6 @@ static void ath9k_hw_set_AR9287_power_cal_table(struct ath_hw *ah,
u8 pdadcValues[AR9287_NUM_PDADC_VALUES];
u16 gainBoundaries[AR9287_PD_GAINS_IN_MASK];
u16 numPiers = 0, i, j;
- int16_t tMinCalPower;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR9287_NUM_PD_GAINS] = {0, 0, 0, 0};
u32 reg32, regOffset, regChainOffset;
@@ -514,7 +512,7 @@ static void ath9k_hw_set_AR9287_power_cal_table(struct ath_hw *ah,
ah, chan, pRawDataset,
pCalBChans, numPiers,
pdGainOverlap_t2,
- &tMinCalPower, gainBoundaries,
+ gainBoundaries,
pdadcValues, numXpdGain);
}
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 7e1ed78..6ff2742 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -593,7 +593,7 @@ static void ath9k_hw_get_def_gain_boundaries_pdadcs(struct ath_hw *ah,
struct ath9k_channel *chan,
struct cal_data_per_freq *pRawDataSet,
u8 *bChans, u16 availPiers,
- u16 tPdGainOverlap, int16_t *pMinCalPower,
+ u16 tPdGainOverlap,
u16 *pPdGainBoundaries, u8 *pPDADCValues,
u16 numXpdGains)
{
@@ -674,8 +674,6 @@ static void ath9k_hw_get_def_gain_boundaries_pdadcs(struct ath_hw *ah,
}
}
- *pMinCalPower = (int16_t)(minPwrT4[0] / 2);
-
k = 0;
for (i = 0; i < numXpdGains; i++) {
@@ -837,7 +835,7 @@ static void ath9k_hw_set_def_power_cal_table(struct ath_hw *ah,
static u8 pdadcValues[AR5416_NUM_PDADC_VALUES];
u16 gainBoundaries[AR5416_PD_GAINS_IN_MASK];
u16 numPiers, i, j;
- int16_t tMinCalPower, diff = 0;
+ int16_t diff = 0;
u16 numXpdGain, xpdMask;
u16 xpdGainValues[AR5416_NUM_PD_GAINS] = { 0, 0, 0, 0 };
u32 reg32, regOffset, regChainOffset;
@@ -922,7 +920,6 @@ static void ath9k_hw_set_def_power_cal_table(struct ath_hw *ah,
chan, pRawDataset,
pCalBChans, numPiers,
pdGainOverlap_t2,
- &tMinCalPower,
gainBoundaries,
pdadcValues,
numXpdGain);
^ permalink raw reply related
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-07-06 12:28 UTC (permalink / raw)
To: Pazzo Da Legare; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikWzx5SZUxZ9qg5Y9jY44YzZlDvs1kSwbFET76H@mail.gmail.com>
> I start from tiwlan.ini file for tiwlan driver to produce an nvs file.
> Could you please indicate values to use for the following parameters
> of struct wl1271_nvs_file: general_params.srf1[],
> general_params.srf2[], general_params.srf3[],
> dyn_radio_params_2[].params.degraded_low_to_normal_thr,
> dyn_radio_params_2[].params.normal_to_degraded_high_thr,
> dyn_radio_params_5[i].params.degraded_low_to_normal_thr,
> dyn_radio_params_5[i].params.normal_to_degraded_high_thr
Hi,
The tiwlan driver ini&NVS files has a different stature then the mac80211 NVS. The parameters you mentioned are RF parameters.
I believe it will be the best to get the NVS that mach to the mac80211 (that I am pushing to get).
Regards,
Shahar
^ permalink raw reply
* Re: [PATCH 14/15] omap: zoom: add WLAN device
From: Roger Quadros @ 2010-07-06 12:33 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat, Ohad Ben-Cohen
In-Reply-To: <1278376666-3509-15-git-send-email-ohad@wizery.com>
Hi Ohad,
On 07/06/2010 03:37 AM, ext Ohad Ben-Cohen wrote:
> From: Ohad Ben-Cohen<ohadb@ti.com>
>
> Add WLAN platform device and control
> functions (power and virtual card detect)
> in order to allow software to control the
> embedded SDIO WLAN device which resides on
> the ZOOM board (TI's wl1271 device).
>
> Based on Android's WLAN control functions by
> San Mehat<san@android.com>.
>
> Signed-off-by: Ohad Ben-Cohen<ohadb@ti.com>
> ---
> arch/arm/mach-omap2/board-zoom-wlan.c | 129 +++++++++++++++++++++++++
> arch/arm/mach-omap2/include/mach/board-zoom.h | 5 +
> 2 files changed, 134 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
>
> diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c b/arch/arm/mach-omap2/board-zoom-wlan.c
> new file mode 100644
> index 0000000..7ed5139
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-zoom-wlan.c
> @@ -0,0 +1,129 @@
> +/* mach-omap2/board-zoom-wlan.c
> + *
> + * Board support for wl1271 embedded SDIO device.
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include<linux/kernel.h>
> +#include<linux/init.h>
> +#include<linux/platform_device.h>
> +#include<linux/mmc/host.h>
> +#include<linux/mmc/sdio_ids.h>
> +#include<linux/err.h>
> +#include<linux/gpio.h>
> +#include<linux/wl12xx.h>
> +
> +#include "mux.h"
> +
> +#ifdef CONFIG_OMAP_ZOOM_WLAN
> +
> +/* these are zoom-specific board numbers */
> +#define OMAP_ZOOM_WLAN_PMENA_GPIO (101)
> +#define OMAP_ZOOM_WLAN_IRQ_GPIO (162)
> +
> +/* wl1271 virtual 'card detect' status */
> +static int omap_zoom_wlan_cd;
> +static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
> +static void (*wlan_set_data)(void *dev_id, void *priv);
> +static void *wlan_host_devid;
> +
> +int omap_zoom_wlan_register_embedded_control(void *dev_id,
> + void (*set_virtual_cd)(void *dev_id, int card_present),
> + void (*set_data)(void *dev_id, void *priv))
> +{
> + if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
> + return -EBUSY;
> +
> + wlan_set_virtual_cd = set_virtual_cd;
> + wlan_set_data = set_data;
> + wlan_host_devid = dev_id;
> +
> + return 0;
> +}
> +
> +int omap_zoom_wlan_get_virtual_cd(void)
> +{
> + return omap_zoom_wlan_cd;
> +}
> +
> +static void omap_zoom_wlan_set_embedded_data(void *priv)
> +{
> + if (wlan_set_data)
> + wlan_set_data(wlan_host_devid, priv);
> + else
> + pr_err("%s: host controller not registered yet\n", __func__);
> +}
> +
> +static void omap_zoom_wlan_set_carddetect(bool card_present)
> +{
> + omap_zoom_wlan_cd = card_present ? 1 : 0;
> +
> + pr_info("%s: %d\n", __func__, omap_zoom_wlan_cd);
> +
> + if (wlan_set_virtual_cd)
> + wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
> + else
> + pr_err("%s: host controller not registered yet\n", __func__);
> +}
> +
> +static void omap_zoom_wlan_power(bool enable)
> +{
> + int val = enable ? 1 : 0;
> +
> + pr_info("%s: set power %d\n", __func__, val);
> +
> + gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
> +}
Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply or
equivalent to supply voltage to the SDIO card?
If yes, then did you consider using the fixed regulator framework to define a
'vmmc' supply (based on OMAP_ZOOM_WLAN_PMENA_GPIO). Then the SDIO/MMC core
should take care of controlling this supply.
regards,
-roger
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Roger Quadros @ 2010-07-06 12:39 UTC (permalink / raw)
To: ext Ohad Ben-Cohen
Cc: Nicolas Pitre, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), Andrew Morton, San Mehat,
Pandita, Vikram
In-Reply-To: <AANLkTinE5LygUWJsJSEE2miZF1GK58LTr8zErkuu_7yM@mail.gmail.com>
Hi,
On 07/06/2010 02:48 PM, ext Ohad Ben-Cohen wrote:
> On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen<ohad@wizery.com> wrote:
>> Note: the wl1271 device does support standard card detection, but
>> AFAIK there's a limitation to use that with the specific omap
>> controller the device is hardwired to. I will try to get more info
>> about that, but probably Madhu can comment on that better.
>
>
> Some correction and additional info:
>
> The wl1271 device has an issue which makes the standard card detect
> mechanism irrelevant: it is always up, even if the power enable gpio
> input of the device is down (the power enable input does not supply
> the power to the chip, it's just logical digital high/low input upon
> which the device reacts). That's why we must use software control for
> emulating card detect with that device.
Just to clarify, is the wl1271 device always powered on the board?
And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this
supply internally?
and what do these do ?
set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
clear_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
regards,
-roger
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Ohad Ben-Cohen @ 2010-07-06 12:53 UTC (permalink / raw)
To: Roger Quadros
Cc: linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux@arm.linux.org.uk, Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), akpm@linux-foundation.org,
San Mehat
In-Reply-To: <4C3306F4.8060907@nokia.com>
Hi Roger,
On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> My point is that shouldn't this be handled by SDIO core?
Care to explain what you mean / give a code example ?
> If there are no users for the SDIO function and the card, doesn't the SDIO
> core power down the slot and take care of re-initialization when it is
> powered up?
You need card detect events in order to trigger card & sdio function
initialization and removals.
Please share any alternative approach you may be thinking on.
Thanks,
Ohad.
>
^ permalink raw reply
* Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Ohad Ben-Cohen @ 2010-07-06 13:44 UTC (permalink / raw)
To: Roger Quadros
Cc: Nicolas Pitre, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), Andrew Morton, San Mehat,
Pandita, Vikram
In-Reply-To: <4C3323EA.902@nokia.com>
On Tue, Jul 6, 2010 at 3:39 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
> Just to clarify, is the wl1271 device always powered on the board?
Yes.
> And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this
> supply internally?
Yes. It's a digital input that the chip does not draw current from
(well, only a very minimal one).
> and what do these do ?
>
> set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
>
> clear_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);
This is an internal driver bit that maintains the power state of the chip.
AFAICT, it does not "do" anything. The only place I can see it is
being used is in a debugfs entry.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox