On Fri, Feb 4, 2011 at 11:42 AM, Mark Mentovai <mark@xxxxxxxxxxxx> wrote: > Luis R. Rodriguez wrote: >> On Sun, Jan 30, 2011 at 9:01 AM, Mark Mentovai <mark@xxxxxxxxxxxx> wrote: >>> Your patch also doesnât work properly for me using the ath9k driver. >>> With your patch, I wind up with an artificial power limit of 20dBm >>> across the board, although the hardware limit is actually 25dBm on the >>> AR9223 Iâm testing with. This stems from the fact that ath9k doesnât >>> know how to properly compute the hardware limit. >>> ath9k_init_txpower_limits is implemented on top of >>> ath9k_hw_set_txpowerlimit, which uses a channelâs current max_power >>> value as a basis for its computation. This means that it will either >>> use the hard-coded initial value of 20dBm from CHAN2G and CHAN5G in >>> drivers/net/wireless/ath/ath9k/init.c, or it will use world regulatory >>> domain values (also 20dBm) set by ath_regd_init_wiphy calling >>> wiphy_apply_custom_regulatory. >> >> The real limit on ath9k comes from analyzing the CTLs from the EEPROM, >> and using that as a max when a CTL is present. The value from cfg80211 >> is simply a local regulatory one, the CTLs take this one step further >> and are calibration specific to help optimize performance on every >> frequency range. > > Of course. My point was merely that the CTL-based calculations that > ath9k does in ath9k_init_txpower_limits when it tries to set a better > .max_power donât even come out correctly, because theyâre based on the > initial values or on regdomain values. Theyâre not actually the > hardwareâs limits. Iâm not even positive that thereâs a single right > âhardware transmit power limit per channelâÂvalue, unless you were to > examine all of the possible rates and perhaps antenna configurations > and other parameters. ath9k_init_txpower_limits doesnât do this. > Thatâs why I saw the patch restricting transmit power to be 20dBm even > though the CTL data would allow higher power. Well the final real power programmed is computed dynamically because as you mentioned there are things to consider other than regulatory / device limits to get a right power we need to use. > In other words, I think babcbc295fee766ca710235e431686fef744d9a6 was wrong. I'll need some time to review this again... > Felix Fietkau wrote: >> What I'm observing is that with the first regdomain setting it sets >> orig_power to something that exceeds the tx power value that the >> hardware is capable of using. > > But orig_mpwr is only supposed to be the maximum transmit power for > the channel in the driverâs requested regulatory domain. Itâs not > supposed to have anything to do with the hardware. Mark is correct, the device limit is also used as part of the dynamic computation for what power you want to use, the upper boundary is this hardware limit. > If you can come up with a good way to compute the hardware maximum per > channel (overcoming ath9k_init_txpower_limitsâs current faults), then > I think this can be accommodated with another field, but I donât think > orig_mpwr should be overloaded. Maybe renamed to better reflect its > purpose, though. I do wonder if the patch above introduced a regression I overlooked.. >> Because of that, the tx power setting reported to the user is wrong. > > I donât think that a good way for a driver to reflect the transmit > power it has actually put into effect (after taking the effects of CTL > limits) back to user space currently exists. What do you mean here, sorry I could not follow. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
