On Tue, Sep 20, 2011 at 9:36 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxx> wrote: > On Tue, Sep 20, 2011 at 7:49 AM, Kalle Valo <kvalo@xxxxxxxxxx> wrote: >> Ohad Ben-Cohen <ohad@xxxxxxxxxx> writes: >> >>> On Tue, Sep 20, 2011 at 11:34 AM, Kalle Valo <kvalo@xxxxxxxxxx> wrote: >>>> IIRC Juuso added ieee80211_enable/disable_dyn_ps() to make it possible >>>> use BT COEX with wl12xx. >>> >>> A lot has happened since then :) The wl12xx firmware today is vastly >>> different and much improved. >> >> Yeah, quite a turn. That's good :) >> >>>> Now you are saying that you actually want the opposite? >>> >>> Yes. The firmware is now capable of doing coex without enforcing PSM. >>> This leads to a much better WLAN TP while BT is on. >> >> So we can remove the enable/disable dynps interface soon? > > Eliad, can you elaborate a little on the behaviour before that > required the enable/disable dyn ps? You say now the firmware is > capable of doing BT coex *without* enforcing PSM, can you elaborate on > that? > As Ohad noted, we'll probably shift to IEEE80211_HW_SUPPORTS_DYNAMIC_PS soon, so this patch is redundant. anyway, just for the record - the fw supports 2 (mutually exclusive) coex events: 1. "soft gemini sense" event - the fw indicates coex activity is about to start. since psm is needed in order to let the BT control the antenna, and psm is controlled from the host, we disable dyn_ps, so we won't get out of psm after sending a packet. 2. "auto mode" event - the fw enters a period, in which it might (and might not) start coex (i.e. the coex activity is transparent to the driver during this period). during this period, the fw enters and exits psm independently. there are sub-periods in which there are not bt activity (e.g. silence during a2dp?). that's why we don't want to disable dyn_ps - it will badly hurt throughput. that's what i remember from what i've been told a few months ago. i also found it weird back then, but it did increase the throughput. > From what I read so far it seems the firmware needs to be fixed so > that it can handle atomically going in and out of PSM when dealing > with BT Coex, one option that comes to mind is dropping the frames it > has and pending if it is doing BT coex work, which introduces the > extra delay you mentioned. The drop would likely also help with rate > control on the other end adjusting itself to environmental factors, in > this case btcoex event. > i'm not familiar with the fw code. as mentioned above, we're moving to dyn_ps in fw soon, so from the driver side, there's one less thing to worry about :) anyway, thanks for your suggestions, Eliad. -- 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
