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

Helmut Schaa helmut.schaa at googlemail.com
Thu Jul 1 22:50:24 AEST 2010


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 ;)

Helmut




More information about the users mailing list