[rt2x00-users] [RFC] Limit txpower by eeprom values

Gertjan van Wingerde gwingerde at gmail.com
Fri Jul 2 08:54:24 AEST 2010


On Thu, Jul 1, 2010 at 2:50 PM, Helmut Schaa
<helmut.schaa at googlemail.com> wrote:
> Am Donnerstag 01 Juli 2010 schrieb Ivo Van Doorn:
>> 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?
>
> Fine with me. Not sure if Gertjan has any objections.
>
> And it needs a proper changelog ;)
>

Just go ahead with it. If I find a way to make things easier
understandable I will simply provide a follow-up patch.

I can't work on this until 2 weeks from now.

---
Gertjan.




More information about the users mailing list