On Wed, Jul 28, 2010 at 10:50 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2010-07-28 7:24 PM, Luis R. Rodriguez wrote: >> On Tue, Jul 27, 2010 at 7:06 PM, Bruno Randolf <br1@xxxxxxxxxxx> wrote: >>> On Wed July 28 2010 01:47:34 Luis R. Rodriguez wrote: >>>> On Tue, Jul 27, 2010 at 9:39 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >>>> > On 2010-07-27 6:19 PM, Luis R. Rodriguez wrote: >>>> >>> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for >>>> >>> transmitting. + * Each bit represents one antenna, starting with >>>> >>> antenna 1 at the first + * bit. If the bitmap is zero (0), the TX >>>> >>> antenna follows RX diversity. >>>> >> >>>> >> What about for 802.11n? What if you want to disable TX? >>>> > >>>> > Disabling tx shouldn't be handled by the antenna setting, IMHO. >>>> > >>>> >>> + * If multiple antennas are selected all selected antennas have to >>>> >>> be used + * for transmitting (801.11n multiple TX chains). >>>> >> >>>> >> I rather call this TX / RX chainmask then. >>>> > >>>> > Well, for legacy hardware, these aren't really chains, as there is only >>>> > one rx and one tx path, just with switching onto multiple antennas. >>>> > >>>> >>> + * Drivers may reject configurations they cannot support. >>>> >>> + * >>>> >>> + * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for >>>> >>> receiving. + * Each bit represents one antenna, starting with >>>> >>> antenna 1 at the first + * bit. If multiple antennas are selected >>>> >>> in the bitmap, 802.11n devices + * should use multiple RX chains >>>> >>> on these antennas, while non-802.11n + * drivers should use >>>> >>> antenna diversity between these antennas. >>>> >> >>>> >> What about TX beamforming, and STBC? >>>> > >>>> > Disabling one antenna/chain on a two-chain device would naturally >>>> > disable TxBF and STBC as well, since it limits the number of available >>>> > chains. The driver should simply act as if the disabled chains didn't >>>> > exist. >>>> >>>> That would work. >>>> >>>> >> Unless 802.11n is completely dealt with I really prefer this patch to >>>> >> only address legacy. Otherwise I see sloppyness and inconsistencies on >>>> >> supporting this feature throughout different drivers. I'd like to >>>> >> avoid that at all costs on nl80211. What you are trying to address is >>>> >> legacy antenna setup, not 802.11n RX/TX chainmask dynamic settings so >>>> >> I'd really try to avoid it unless you really want to address all >>>> >> aspects of chain configuration for 802.11n and even then what I'm >>>> >> leading on to say is I think you'll see if you try to address both it >>>> >> just gets messy. >>>> > >>>> > I think 802.11n is already completely dealt with if you treat this as >>>> > the chainmask on 11n devices. >>>> >>>> Its fine by me if the above cases are also embedded into the >>>> documentation, just don't want these questions lingering. I can't >>>> think of other 802.11n special cases. >>> >>> thanks felix :) >>> >>> luis, could you tell me what exactly you would want to include in the >>> documentation? >> >> Sure, but after some though I'm sticking to my preference for an API >> for this, legacy and 802.11n chainmask / antenna selection should be >> dealt with separately. > > As I pointed out in an earlier discussion, they *cannot* really be > treated separately if you're running in AP mode, dealing with both > legacy and 11n clients. In AP mode you'd use the 11n mode stuff not the legacy stuff, so not sure how this matters. >> Reason is I just reviewed the IEEE 802.11 sections 19.19 for TX >> beamforming but also happened to stumble upon section 19.20 Antenna >> selection. This Antenna Selection section indicates you can support >> more antennas than chains and you can use and that the antenna you use >> for your chains can vary over time. You select which antenna to use >> based on training/sounding tests on each antenna. Antenna selection as >> per 19.19 supports up to 8 antennas and up to 4 RF chains. Section >> 19.20.2 deals with how a STA can initiate antenna selection training >> with another STA. Now granted we don't have code for this and I don't >> think this is all done explicitly in hardware so one can argue we can >> deal with this when/if we do add support for this but this just >> highlights how different "antenna selection" or knobs to tune antennas >> is even from a standard perspective than legacy. For STBC and TX >> beamforming requirements I would like to see mac80211 actually have >> code which disables STBC and later TX beamforming (once we have code >> for it) if we enable only one chain, I don't see why drivers should >> deal with this. > > This is easy to handle, it can work like this: > We treat the setting not as a raw chainmask, but actually as an antenna > mask. The chainmask gets calculated from that. If we disable all > antennas belonging to a particular chain, we disable the entire chain. Fair enough. Would cfg80211 deal with this logic then? That would be my preference. But then, do we even expose enough hardware capabilities for cfg80211 to make this decision already? > For AR9285 we will already deviate from treating this as a chainmask, > because it has one chain with rx diversity. Good point but the single stream 802.11n case just needs to be documented as well, it'll be like that for other single stream 802.11n devices, if there are others, not sure if Atheros has the only ones in the market or what. > Please accept this API If you really need some knobs without detailed review and discussion shoot for debugfs, otherwise I will take my time reviewing carefully all the details because once its API then.. well its set in stone and we have to deal with it. I realize I'm being a real big fucking pain in the ass with this but.. I believe these discussions have also been helpful. > I'm sure the API can be used to handle everything related to 802.11n > antenna/chain selection properly. :) Sure, but who deals with the 11n stuff? Right now this patches just pass two variables, TX and RX antenna mask, and has no special case handling for the different 802.11n cases, nor does it document who should handle that. * STBC (11n 9.6.0.c, 9.7g, etc) * TX Beamforming (11n 19.19) * Antenna selection (11n 19.20) IMHO we should be thinking about this if we want to define an API that *all* 802.11 drivers can use if the API will be used for 802.11n as well. 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
