Message ID | 1551692896-7062-9-git-send-email-sgruszka@redhat.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Felix Fietkau |
Headers | show |
Series | mt76x02: AP support for USB with PS | expand |
On 2019-03-04 10:48, Stanislaw Gruszka wrote: > Program beacons data and PS buffered frames on TBTT work for USB. > We do not have MT_TXQ_PSD queue available via USB endpoints. The way > we can send PS broadcast frames in timely manner before PS stations go > sleep again is program them in beacon data area. Hardware do not modify > those frames since TXWI is properly configured. mt76x02_mac_set_beacon() > already handle this and free no longer used frames. > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> I think it's a nice idea, but there is one problem with that approach: beacon slots only have 1024 bytes for TXWI + data. I think to support this properly, you probably need to adjust beacon offsets for USB dynamically and limit the number of frames to what you can fit in SRAM. - Felix
On Sat, Mar 16, 2019 at 08:44:21PM +0100, Felix Fietkau wrote: > On 2019-03-04 10:48, Stanislaw Gruszka wrote: > > Program beacons data and PS buffered frames on TBTT work for USB. > > We do not have MT_TXQ_PSD queue available via USB endpoints. The way > > we can send PS broadcast frames in timely manner before PS stations go > > sleep again is program them in beacon data area. Hardware do not modify > > those frames since TXWI is properly configured. mt76x02_mac_set_beacon() > > already handle this and free no longer used frames. > > > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> > I think it's a nice idea, but there is one problem with that approach: > beacon slots only have 1024 bytes for TXWI + data. > I think to support this properly, you probably need to adjust beacon > offsets for USB dynamically and limit the number of frames to what you > can fit in SRAM. That would be good since we could sent more buffered frames (ARP frames are small), but for now I would prefer simpler solution to enable AP support for USB: increase slot size to 1600 and make only 5 slots available. I assume we can not increase beacon SRAM area to more than 8kB. Stanislaw
On 2019-03-18 10:50, Stanislaw Gruszka wrote: > On Sat, Mar 16, 2019 at 08:44:21PM +0100, Felix Fietkau wrote: >> On 2019-03-04 10:48, Stanislaw Gruszka wrote: >> > Program beacons data and PS buffered frames on TBTT work for USB. >> > We do not have MT_TXQ_PSD queue available via USB endpoints. The way >> > we can send PS broadcast frames in timely manner before PS stations go >> > sleep again is program them in beacon data area. Hardware do not modify >> > those frames since TXWI is properly configured. mt76x02_mac_set_beacon() >> > already handle this and free no longer used frames. >> > >> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> >> I think it's a nice idea, but there is one problem with that approach: >> beacon slots only have 1024 bytes for TXWI + data. >> I think to support this properly, you probably need to adjust beacon >> offsets for USB dynamically and limit the number of frames to what you >> can fit in SRAM. > That would be good since we could sent more buffered frames (ARP frames > are small), but for now I would prefer simpler solution to enable > AP support for USB: increase slot size to 1600 and make only 5 slots > available. Then you should probably limit the number of AP interfaces for USB as well. Otherwise, people are going to do crazy things like bring up 4 virtual AP interfaces and expect multicast to work :) - Felix
On Mon, Mar 18, 2019 at 10:57:47AM +0100, Felix Fietkau wrote: > On 2019-03-18 10:50, Stanislaw Gruszka wrote: > > On Sat, Mar 16, 2019 at 08:44:21PM +0100, Felix Fietkau wrote: > >> On 2019-03-04 10:48, Stanislaw Gruszka wrote: > >> > Program beacons data and PS buffered frames on TBTT work for USB. > >> > We do not have MT_TXQ_PSD queue available via USB endpoints. The way > >> > we can send PS broadcast frames in timely manner before PS stations go > >> > sleep again is program them in beacon data area. Hardware do not modify > >> > those frames since TXWI is properly configured. mt76x02_mac_set_beacon() > >> > already handle this and free no longer used frames. > >> > > >> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> > >> I think it's a nice idea, but there is one problem with that approach: > >> beacon slots only have 1024 bytes for TXWI + data. > >> I think to support this properly, you probably need to adjust beacon > >> offsets for USB dynamically and limit the number of frames to what you > >> can fit in SRAM. > > That would be good since we could sent more buffered frames (ARP frames > > are small), but for now I would prefer simpler solution to enable > > AP support for USB: increase slot size to 1600 and make only 5 slots > > available. > Then you should probably limit the number of AP interfaces for USB as > well. Otherwise, people are going to do crazy things like bring up 4 > virtual AP interfaces and expect multicast to work :) Yes, sure, for now only one is allowed. Multi vifs for USB is on my TODO list. Stanislaw
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c index 28102082772b..63e2926cdd0c 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c @@ -38,6 +38,7 @@ const u16 mt76x02_beacon_offsets[16] = { 0xc000, 0xc000, }; +EXPORT_SYMBOL_GPL(mt76x02_beacon_offsets); static void mt76x02_set_beacon_offsets(struct mt76x02_dev *dev) { @@ -134,6 +135,7 @@ int mt76x02_mac_set_beacon(struct mt76x02_dev *dev, u8 vif_idx, bcn_idx - 1); return 0; } +EXPORT_SYMBOL_GPL(mt76x02_mac_set_beacon); static void __mt76x02_mac_set_beacon_enable(struct mt76x02_dev *dev, u8 vif_idx, diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c index 427d231c32f3..1e67d53098b0 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c @@ -164,9 +164,32 @@ static void mt76x02u_pre_tbtt_work(struct work_struct *work) { struct mt76x02_dev *dev = container_of(work, struct mt76x02_dev, pre_tbtt_work); + int beacon_len = mt76x02_beacon_offsets[1] - mt76x02_beacon_offsets[0]; + struct beacon_bc_data data = {}; + struct sk_buff *skb; + int i, nbeacons; if (!dev->beacon_mask) return; + + mt76x02_resync_beacon_timer(dev); + + ieee80211_iterate_active_interfaces(mt76_hw(dev), + IEEE80211_IFACE_ITER_RESUME_ALL, + mt76x02_update_beacon_iter, dev); + + nbeacons = hweight8(dev->beacon_mask); + mt76x02_enqueue_buffered_bc(dev, &data, 8 - nbeacons); + + for (i = nbeacons; i < 8; i++) { + skb = __skb_dequeue(&data.q); + if (skb && skb->len >= beacon_len) { + dev_kfree_skb(skb); + skb = NULL; + } + mt76x02_mac_set_beacon(dev, i, skb); + } + mt76x02u_restart_pre_tbtt_timer(dev); } @@ -190,13 +213,20 @@ static void mt76x02u_pre_tbtt_enable(struct mt76x02_dev *dev, bool en) static void mt76x02u_beacon_enable(struct mt76x02_dev *dev, bool en) { + int i; + if (WARN_ON_ONCE(!dev->beacon_int)) return; - if (en) + if (en) { mt76x02u_start_pre_tbtt_timer(dev); - - /* Nothing to do on disable as timer is already stopped */ + } else { + /* Timer is already stopped, only clean up + * PS buffered frames if any. + */ + for (i = 0; i < 8; i++) + mt76x02_mac_set_beacon(dev, i, NULL); + } } void mt76x02u_init_beacon_config(struct mt76x02_dev *dev)
Program beacons data and PS buffered frames on TBTT work for USB. We do not have MT_TXQ_PSD queue available via USB endpoints. The way we can send PS broadcast frames in timely manner before PS stations go sleep again is program them in beacon data area. Hardware do not modify those frames since TXWI is properly configured. mt76x02_mac_set_beacon() already handle this and free no longer used frames. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> --- .../wireless/mediatek/mt76/mt76x02_beacon.c | 2 ++ .../wireless/mediatek/mt76/mt76x02_usb_core.c | 36 +++++++++++++++++-- 2 files changed, 35 insertions(+), 3 deletions(-)