On Tue, Mar 31, 2009 at 10:18 AM, Nick Kossifidis wrote:
> 2009/3/31 Fabio Rossi :
>> When the EEPROM contains weird values for the power levels we have to
>> fix the interpolation process.
>>
>> Signed-off-by: Fabio Rossi
> Acked-by: Nick Kossifidis
Can this be rebased on top of the ath5k/ath
2009/3/31 Fabio Rossi :
> When the EEPROM contains weird values for the power levels we have to
> fix the interpolation process.
>
> Signed-off-by: Fabio Rossi
> ---
> diff --git a/drivers/net/wireless/ath5k/phy.c
> b/drivers/net/wireless/ath5k/phy.c
> index 9e2faae..0e3e0e0 100644
> --- a/driver
On Tuesday 31 March 2009, Nick Kossifidis wrote:
> 2009/3/31 Fabio Rossi :
> > On Tuesday 31 March 2009, Nick Kossifidis wrote:
> >> > 2009/3/30 Fabio Rossi :
> >> > I have discovered the problem. Inside ath5k_hx_txpower() it's called
> >> > ath5k_setup_channel_powertable() where the gain curves of
2009/3/31 Fabio Rossi :
> On Tuesday 31 March 2009, Nick Kossifidis wrote:
>
>> > 2009/3/30 Fabio Rossi :
>> > I have discovered the problem. Inside ath5k_hx_txpower() it's called
>> > ath5k_setup_channel_powertable() where the gain curves of frequency
>> > piers are scanned (if I have understood c
On Tue, Mar 31, 2009 at 09:21:40AM +0530, Dhaval Giani wrote:
> Am not sure what the PID controller is, and google gave me a number of
> results, which did not make too much sense in the context.
CONFIG_MAC80211_RC_PID -- unfortunately I recall having to jump through
a few config hoops to enable i
When the EEPROM contains weird values for the power levels we have to
fix the interpolation process.
Signed-off-by: Fabio Rossi
---
diff --git a/drivers/net/wireless/ath5k/phy.c b/drivers/net/wireless/ath5k/phy.c
index 9e2faae..0e3e0e0 100644
--- a/drivers/net/wireless/ath5k/phy.c
+++ b/drivers/n
On Tuesday 31 March 2009, Nick Kossifidis wrote:
> > 2009/3/30 Fabio Rossi :
> > I have discovered the problem. Inside ath5k_hx_txpower() it's called
> > ath5k_setup_channel_powertable() where the gain curves of frequency
> > piers are scanned (if I have understood correctly) to extract the data
>
On Sun, Mar 29, 2009 at 11:14:01AM -0400, Bob Copeland wrote:
>
> No, thanks - the debug output will be plenty verbose already and should
> tell everything we need to know.
Frustratingly despite leaving the machine on for two nights, the slab
poison message has not reappeared while debugging was
2009/3/31 Nick Kossifidis :
> Anyway since we have such cards
> we just need to put a check there and where pwrL[0] == pwrL[1], we set
> tmp = stepL[0] or if pwrR[0] == pwrR[1], we set tmp = stepR[0]. Try
> this out and see how it goes...
>
(almost there :P) no need to do this, if we get pwrL[0] =
2009/3/31 Nick Kossifidis :
>
> It's weird that your EEPROM contains a value twice, both pwrL[0] and
> pwrL[1] are 4 so interpolation always returns 4 and tmp is always > 1
> so you have an endless loop.
(still sleeping) it doesn't return 4 (that's the pwr lvl) but the same
pcdac step :P
--
GP
2009/3/30 Fabio Rossi :
> On Sunday 29 March 2009, Nick Kossifidis wrote:
>
>> This patch introduces a function (and some helpers) to set 2 tables on
>> hardware, it doesn't mess with the rest of the driver. I've tested it
>> both on sta and ap scenarios with all the cards i have available and
>> i
11 matches
Mail list logo
