* 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
* Re: [PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen @ 2010-07-06 13:47 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: <4C33228D.8000908@nokia.com>
Hi Roger,
On Tue, Jul 6, 2010 at 3:33 PM, Roger Quadros <roger.quadros@nokia.com> wrote:
>> +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?
Not really, this gpio does not supply power to the chip. It's only a
digital indication that instructs the chip to go into on or off mode.
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Roger Quadros @ 2010-07-06 14:30 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
In-Reply-To: <AANLkTin5W52fPzWToRrAzm56SLZI-taSuI16rCEhLWqH@mail.gmail.com>
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
> 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 the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
the SDIO/MMC core should tackle it, just like it deals with supply for slots
with removable cards.
see mmc_regulator_set_ocr()
mmc_power_up()
mmc_set_ios()
in drivers/mmc/core/core.c
and omap_hsmmc_set_ios()
in drivers/mmc/host/omap_hsmmc.c
>
>> 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.
OK, this is how I see it.
- Treat the non-removable card as non-removable. So no need to do card detect
emulation.
- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator & supply. Even though you mention that it is
not actually a supply, it fits well in the fixed supply framework.
- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).
- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.
- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.
Does this address all issues?
regards,
-roger
^ permalink raw reply
* RE: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Madhusudhan @ 2010-07-06 15:34 UTC (permalink / raw)
To: 'Ohad Ben-Cohen', 'Nicolas Pitre'
Cc: linux-wireless, linux-mmc, linux-omap, linux-arm-kernel, linux,
'Luciano Coelho', 'Andrew Morton',
'San Mehat', 'Pandita, Vikram'
In-Reply-To: <AANLkTinE5LygUWJsJSEE2miZF1GK58LTr8zErkuu_7yM@mail.gmail.com>
> -----Original Message-----
> From: Ohad Ben-Cohen [mailto:ohad@wizery.com]
> Sent: Tuesday, July 06, 2010 6:48 AM
> To: Nicolas Pitre
> 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; Luciano Coelho;
> Andrew Morton; San Mehat; Pandita, Vikram
> Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
>
> 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).
The card detect is supported through T2 GPIO interrupts only for MMC1 and
MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is
hardwired.
Regards,
Madhu
^ permalink raw reply
* Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Grazvydas Ignotas @ 2010-07-06 15:49 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-5-git-send-email-ohad@wizery.com>
On Tue, Jul 6, 2010 at 3:37 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> From: Ohad Ben-Cohen <ohadb@ti.com>
>
> Add support to set/get mmc_host private embedded
> data.
>
> This is needed to allow software to dynamically
> create (and remove) SDIO functions which represents
> embedded SDIO devices.
>
> Typically, it will be used to set the context of
> a driver that is creating a new SDIO function
> (and would then expect to be able to get that context
> back upon creation of the new sdio func).
>
> Signed-off-by: Ohad Ben-Cohen <ohadb@ti.com>
> ---
> drivers/mmc/core/Kconfig | 8 ++++++++
> include/linux/mmc/host.h | 16 ++++++++++++++++
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index bb22ffd..ab27eb3 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
>
> This option sets a default which can be overridden by the
> module parameter "removable=0" or "removable=1".
> +
> +config MMC_EMBEDDED_SDIO
> + boolean "MMC embedded SDIO device support"
> + help
> + If you say Y here, support will be added for embedded SDIO
> + devices (e.g. hardwired embedded WLAN SDIO devices).
> + Such devices require software support for emulating
> + card detect events.
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index f65913c..9a48486 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -209,6 +209,10 @@ struct mmc_host {
> struct led_trigger *led; /* activity led */
> #endif
>
> +#ifdef CONFIG_MMC_EMBEDDED_SDIO
> + void *embedded_data;
> +#endif
> +
Hm, do we really need a Kconfig option just for a single pointer? It
only saves sizeof(void *) bytes per host, but adds rather confusing
config option for users and some ifdef complexity.
^ permalink raw reply
* Re: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen @ 2010-07-06 15:54 UTC (permalink / raw)
To: Grazvydas Ignotas
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: <AANLkTilfjBIbylUDKlTGiEC_U6pJnkC6HoENOzK2eFFq@mail.gmail.com>
On Tue, Jul 6, 2010 at 6:49 PM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> Hm, do we really need a Kconfig option just for a single pointer? It
> only saves sizeof(void *) bytes per host, but adds rather confusing
> config option for users and some ifdef complexity.
No strong feelings about it, I can remove that if preferred.
>
^ permalink raw reply
* Re: ath: Fix uninitialized variable warnings [v2]
From: Pavel Roskin @ 2010-07-06 16:35 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-wireless, ath9k-devel, linville
In-Reply-To: <4C331BB9.5010005@redhat.com>
On Tue, 2010-07-06 at 08:04 -0400, Prarit Bhargava wrote:
> New patch with updated description.
Your patch doesn't apply anymore.
> Fix 'make CONFIG_DEBUG_SECTION_MISMATCH=y' warning:
I tried to reproduce the warning, but could not. I guess my gcc is old
(4.4.1) or you used more options that enable warnings.
> 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.
That alone is the best reason. I'll resend the updated patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] ath9k: remove unneeded calculation of minimal calibration power
From: Pavel Roskin @ 2010-07-06 16:51 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: Prarit Bhargava
Remove tMinCalPower from ath9k_hw_set_def_power_cal_table(), as it's
never used. Remove corresponding arguments of the functions calculating
that value.
Original patch by Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 7 ++-----
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 ----
drivers/net/wireless/ath/ath9k/eeprom_def.c | 7 ++-----
3 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_4k.c b/drivers/net/wireless/ath/ath9k/eeprom_4k.c
index e25a2ab..00cc3db 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)
{
@@ -308,8 +308,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++) {
@@ -399,7 +397,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;
@@ -452,7 +449,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 39a4105..cb388d2 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -223,7 +223,6 @@ static void ath9k_hw_get_ar9287_gain_boundaries_pdadcs(struct ath_hw *ah,
struct cal_data_per_freq_ar9287 *pRawDataSet,
u8 *bChans, u16 availPiers,
u16 tPdGainOverlap,
- int16_t *pMinCalPower,
u16 *pPdGainBoundaries,
u8 *pPDADCValues,
u16 numXpdGains)
@@ -303,7 +302,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++) {
@@ -458,7 +456,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, regval;
@@ -530,7 +527,6 @@ static void ath9k_hw_set_ar9287_power_cal_table(struct ath_hw *ah,
pRawDataset,
pCalBChans, numPiers,
pdGainOverlap_t2,
- &tMinCalPower,
gainBoundaries,
pdadcValues,
numXpdGain);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 77b1433..57d86d4 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)
{
@@ -675,8 +675,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++) {
@@ -838,7 +836,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;
@@ -923,7 +921,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: [PATCH 05/15] omap: hsmmc: add virtual card detect support
From: Nicolas Pitre @ 2010-07-06 17:00 UTC (permalink / raw)
To: Madhusudhan
Cc: 'Ohad Ben-Cohen', linux-wireless, linux-mmc, linux-omap,
linux-arm-kernel, linux, 'Luciano Coelho',
'Andrew Morton', 'San Mehat',
'Pandita, Vikram'
In-Reply-To: <822D79B5C25543B1A6F148B39E061459@am.dhcp.ti.com>
On Tue, 6 Jul 2010, Madhusudhan wrote:
>
>
> > -----Original Message-----
> > From: Ohad Ben-Cohen [mailto:ohad@wizery.com]
> > Sent: Tuesday, July 06, 2010 6:48 AM
> > To: Nicolas Pitre
> > 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; Luciano Coelho;
> > Andrew Morton; San Mehat; Pandita, Vikram
> > Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support
> >
> > 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).
>
> The card detect is supported through T2 GPIO interrupts only for MMC1 and
> MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is
> hardwired.
Many existing implementations simply have no (or a broken) card
detection signal. In that case, either the host controller passes the
MMC_CAP_NEEDS_POLL flag to the core so that the bus is probed on a
regular interval for card presence. Or, like in this case where the
"card" is always hardwired on the board, you simply rely on the initial
probe which is always performed at least once when the host controller
driver is registered.
Now the issue of having the card powered off when not in use is a valid
one, whether or not it is actually hardwired on the board or
hot insertable/removable. This fake insertion thing is not the best way
to go about it.
It would be way more useful, generic, and less hackish to simply improve
the generic code so to power down the card when it is 1) not claimed by
any function driver, and 2) provide an API to let a function driver
signify to the core and host controller that it is not interested by the
hardware at the moment (if the network interface is not up for example)
and therefore the core could again power down the card. This would work
in all cases with no need for exceptions for so called "enbedded
controllers".
Nicolas
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Nicolas Pitre @ 2010-07-06 17:42 UTC (permalink / raw)
To: Roger Quadros
Cc: ext Ohad Ben-Cohen, 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: <4C333E0D.2070601@nokia.com>
On Tue, 6 Jul 2010, Roger Quadros wrote:
> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
> > 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 the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
> the SDIO/MMC core should tackle it, just like it deals with supply for slots
> with removable cards.
Exact.
> > You need card detect events in order to trigger card& sdio function
> > initialization and removals.
Why would you trigger function initialization and removal? Just to turn
off power? That's a bit like pulling off the battery from your laptop
when you want to suspend it. There is a better way to go about things.
> > Please share any alternative approach you may be thinking on.
>
> OK, this is how I see it.
>
> - Treat the non-removable card as non-removable. So no need to do card detect
> emulation.
>
> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
> framework to define this regulator & supply. Even though you mention that it
> is not actually a supply, it fits well in the fixed supply framework.
>
> - When the host controller is enumerated, the mmc core will power up the slot,
> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>
> - if interface is not in use, the function driver must release the sdio host,
> and this should eventually disable the vmmc supply.
>
> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
> sdio host. this will cause the vmmc supply to be enabled, for as long as the
> interface is up.
>
> Does this address all issues?
This is mostly all good, except that claiming/releasing the SDIO host is
about access to the bus. It must be claimed right before doing any IO,
and released right after that, even when the card is expected to remain
powered. This is not the proper place to hook power control.
Another function pair would be needed instead, which would do almost
like the suspend/resume code is already doing. Something like:
/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same "no power" state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);
/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);
That's it. When the network interface is down and the hardware is not
needed, you call sdio_release_power(). When the request to activate the
network interface is received, you call sdio_claim_power() and configure
the hardware appropriately. If sdio_claim_power() returns an error,
then you just return an error to the network request, and eventually the
driver's remove method will be called if this is indeed because the card
was removed.
In the core SDIO code, this is almost identical to a suspend/resume
request, except that the request comes from the function driver instead
of the core MMC code.
Nicolas
^ permalink raw reply
* Compat-wireless release for 2010-07-06 is baked
From: Compat-wireless cronjob account @ 2010-07-06 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
39a2e97..5aff268 history -> origin/history
+ 2880928...03c604f master -> origin/master (forced update)
123f94f..815c416 stable -> origin/stable
* [new tag] next-20100706 -> next-20100706
* [new tag] v2.6.35-rc4 -> v2.6.35-rc4
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
494471 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
From: Adrian Hunter @ 2010-07-06 19:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Quadros Roger (Nokia-MS/Helsinki), Ohad Ben-Cohen,
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: <alpine.LFD.2.00.1007061316010.6020@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 6 Jul 2010, Roger Quadros wrote:
>
>> On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
>>> 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 the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
>> the SDIO/MMC core should tackle it, just like it deals with supply for slots
>> with removable cards.
>
> Exact.
>
>>> You need card detect events in order to trigger card& sdio function
>>> initialization and removals.
>
> Why would you trigger function initialization and removal? Just to turn
> off power? That's a bit like pulling off the battery from your laptop
> when you want to suspend it. There is a better way to go about things.
>
>>> Please share any alternative approach you may be thinking on.
>> OK, this is how I see it.
>>
>> - Treat the non-removable card as non-removable. So no need to do card detect
>> emulation.
>>
>> - Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
>> framework to define this regulator & supply. Even though you mention that it
>> is not actually a supply, it fits well in the fixed supply framework.
>>
>> - When the host controller is enumerated, the mmc core will power up the slot,
>> find the sdio card, and probe the function driver (i.e. wl1271_sdio).
>>
>> - if interface is not in use, the function driver must release the sdio host,
>> and this should eventually disable the vmmc supply.
>>
>> - Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
>> sdio host. this will cause the vmmc supply to be enabled, for as long as the
>> interface is up.
>>
>> Does this address all issues?
>
> This is mostly all good, except that claiming/releasing the SDIO host is
> about access to the bus. It must be claimed right before doing any IO,
> and released right after that, even when the card is expected to remain
> powered. This is not the proper place to hook power control.
>
> Another function pair would be needed instead, which would do almost
> like the suspend/resume code is already doing. Something like:
>
> /*
> * Indicate to the core SDIO layer that we're not requiring that the
> * function remain powered. If all functions for the card are in the
> * same "no power" state, then the host controller can remove power from
> * the card. Note: the function driver must preserve hardware states if
> * necessary.
> */
> int sdio_release_power(struct sdio_func *func);
>
> /*
> * Indicate to the core SDIO layer that we want power back for this
> * SDIO function. The power may or may not actually have been removed
> * since last call to sdio_release_power(), so the function driver must
> * not assume any preserved state at the hardware level and re-perform
> * all the necessary hardware config. This function returns 0 when
> * power is actually restored, or some error code if this cannot be
> * achieved. One error reason might be that the card is no longer
> * available on the bus (was removed while powered down and card
> * detection didn't trigger yet).
> */
> int sdio_claim_power(struct sdio_func *func);
>
> That's it. When the network interface is down and the hardware is not
> needed, you call sdio_release_power(). When the request to activate the
> network interface is received, you call sdio_claim_power() and configure
> the hardware appropriately. If sdio_claim_power() returns an error,
> then you just return an error to the network request, and eventually the
> driver's remove method will be called if this is indeed because the card
> was removed.
>
> In the core SDIO code, this is almost identical to a suspend/resume
> request, except that the request comes from the function driver instead
> of the core MMC code.
For eMMC in omap_hsmmc, this is all done via claim_host / release_host
which call ->enable() / ->disable() methods. omap_hsmmc makes use of
mmc_power_restore_host() which calls host->bus_ops->power_restore()
which is not implemented for SDIO, but for MMC and SD it reinitializes
the card.
Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and
implement host->bus_ops->power_restore() for SDIO, then the power will
go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc
so that it doesn't wait 9 seconds for the SDIO case
>
>
> Nicolas
> --
> 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
>
^ permalink raw reply
* [PATCH] compat-wireless: update 07-change-default-rate-alg.patch
From: Pavel Roskin @ 2010-07-06 20:24 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
---
patches/07-change-default-rate-alg.patch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/patches/07-change-default-rate-alg.patch b/patches/07-change-default-rate-alg.patch
index f0ccbce..858e1bc 100644
--- a/patches/07-change-default-rate-alg.patch
+++ b/patches/07-change-default-rate-alg.patch
@@ -29,6 +29,6 @@ at compilation time.
- ops = ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);
+ if (!ops && strlen(CONFIG_COMPAT_MAC80211_RC_DEFAULT))
+ ops = ieee80211_try_rate_control_ops_get(CONFIG_COMPAT_MAC80211_RC_DEFAULT);
- kparam_unblock_sysfs_write(ieee80211_default_rc_algo);
return ops;
+ }
^ permalink raw reply related
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