[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:
> Hi,
> 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 mailing list