[rt2x00-users] [RFC] Limit txpower by eeprom values
Ivo Van Doorn
ivdoorn at gmail.com
Thu Jul 1 19:46:54 AEST 2010
On Sun, Jun 20, 2010 at 12:50 PM, Helmut Schaa
<helmut.schaa at googlemail.com> wrote:
> Am Samstag 19 Juni 2010 schrieb Ivo van Doorn:
>> > Hmm, I've just noticed that the txpower handling in rt2x00 is somewhat
>> > weird.
>> This is not rt2800 specific. In each Ralink device the txpower is close
>> to magical. ;)
> Unfortunately, yes ...
>> > rt2800 reports its txpower per channel values to mac80211 in the
>> > channel array, and when switching to that channel mac80211 will pass
>> > this value (if not overwritten by crda due to regulatory stuff) again
>> > to us.
>> > Hence, we end up reading EEPROM_TXPOWER_* and using these values for
>> > limiting txpower in TX_PWR_CFG* which should be used in conjunction with
>> > the BYRATE values.
>> But how do these values relate to each other?
>> I mean is the value in EEPTOM_TXPOWER that much different from the BYRATE value?
> Since I don't know the meaning of all the registers ;) I can only speculate (and
> I only reviewed the txpower handling in rt2800):
> The EEPROM_TXPOWER values are typically programmed into some rf registers and
> seem to be not manipulted at all when changing the txpower values. However,
> the rt2x00 code base provides mac80211 with the tx_power1 value for each
> channel as maximum tx power. So, mac80211 won't ever give us a value larger
> then tx_power1. Btw. it seems as if this value can be between 0 and 31.
> The BYRATE are programmed into the according registers and are indeed changed
> when setting a different txpower in the legacy drivers (in addition to BBP_R1).
> The values can be between 0 and 15 (one halfbyte).
> (btw. it _seems_ to me as if the BYRATE values are indeed dBm values, I found
> some comments in the legacy drivers about them).
>> > I'd vote for not using the txpower callback for now and just initializing
>> > the txpower by rate values with the calibration values from the eeprom
>> > and using txpower1..2 as they are used already when switching the channel.
>> > This should ensure us to always run with 100% tx power for now but as long
>> > as we don't know exactly how the different txpower values are to be used
>> > this should give us the best results.
>> With your patch, is there a performance gain? What would actually be the
>> problem be with just applying the patch?
> Yes and no ;)
> With the patch we at least ensure that we don't set values larger then
> the BYRATE values from the eeprom -> That's good, and gave me a 10-15% gain
> in throughput with my Intel STA (because otherwise the rt3052 board used
> a too high txpower).
> But on the other hand, when tx_power1 is smaller then all the BYRATE values
> mac80211 calls our txpower_config with this value and we will reduce the
> BYRATE values to tx_power1, hence reducing the txpower to something <100%
> and thus most likely reducing the wireless cards range.
> However, we still want mac80211 to tell us the maximum allowed txpower based
> on the current regulatory domain I guess.
> So, yeah, since the patch will ensure that we always run with BYRATE txpower
> values < 100% and we would have used values >100% before it makes sense to
> apply it even if it might limit txpower to <100% under certain circumstances.
> Gertjan, would this reworked patch be ok for you? Any objections?
> Ivo, I'll give it another try first and resend it as patch instead of RFC, ok?
I have kept this patch in the experimental branch, can be be moved to
the master branch,
or are you still looking for an alternative?
More information about the users