mt76: sdio: extend sdio module to support CONNAC2
A message that is not in the archive (sent off-list or not yet received): YWcuGcFPGCtaPh+2@lore-desk--annotate
From: Sean Wang <[email protected]>
Quoted 14 lines
[...]
Quoted 13 lines
In the current driver, we can see we only created one Rx queue
(dev->q_rxwith qid = 0) inmt76s_alloc_queuesfor processing all incoming packets including MCU events and wifi packets.And from the point of view of the device, mt7663s use the hardware queue 0 for all MCU events and wifi packets; mt7921s use the hardware queue 1 for all MCU events and wifi packets.
So if we don't remap from hardware queue 1 to dev->q_rx[0] for mt7921s
to handle incoming packets, we will get the kernel panic on accessing the invalid pointer on dev->q_rx[1].Sean
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Regards,
Lorenzo<snip>
ok, what about doing something like the patch below? If it works for you, I will post a formal patch.
go ahead. that looks fine to me.
Quoted 4 lines
Regards,
Lorenzo
<snip>
_______________________________________________
Linux-mediatek mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/2] mt76: mt7921s: fix the device cannot sleep deeply in suspend
In reply to a message not in the archiveFrom: Sean Wang <[email protected]>
Quoted 30 lines
Quoted 30 lines
From: Sean Wang <[email protected]>
<snip>
Quoted 18 lines
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
(quoted diff) +0
-6- if (test_bit(MT76_MCU_RESET, &dev->phy.state)) { - if (!mt76s_txqs_empty(dev)) - continue; - else - wake_up(&sdio->wait); - }} while (nframes > 0);Quoted 4 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+ if (test_bit(MT76_MCU_RESET, &dev->phy.state) && + mt76s_txqs_empty(dev)) + wake_up(&sdio->wait); +If doing so,
mt76s_txqs_emptymay not always be true because enqueuing packets toq_txor MCU command toq_mcusimultanenously from the other contexts in different cpu is possible.Quoted 4 lines
Quoted 2 lines
It seemed to me we should check it for each iteration to guarantee
that we can wake up the one that is waiting for the all the queues are empty at some time.IIUC what we are interested here is there are no queued frames into the hw queues during suspend or reset, right?
That is not completely true. Take the suspend procedure on mt7921s as an example.
Quoted 8 lines
Quoted 5 lines
That should be "There are no queued frames into the hw queues right after
mt76_connac_mcu_set_hif_suspend."The MCU data and WiFi are all handled in
mt76s_txrx_workerso we
should synchronize all of the Tx queues are all empty and then handlemt76_connac_mcu_set_hif_suspendto guaranteemt76_connac_mcu_set_hif_suspendis the last one to access the SDIO bus and there is no frame that accesses SDIO bus afterhand.ack, correct, "there are no queued frames into the hw queues right after
mt76_connac_mcu_set_hif_suspend."
What I mean is we are not really checking there are no frames in the hw queue here, but mt76 sdio has processed all the frames, got my point? maybe it is what we are looking for..
It seemed to me there is no a way to check if no frames in the hw queue for mt7921s
I think we can discuss the topic "it is ok move the check out of the loop" with another patch in the future
because it seemed not related to the patch.
Quoted 22 lines
Regards,
LorenzoQuoted 18 lines
Quoted 18 lines
Quoted 17 lines
Quoted 16 lines
Quoted 13 lines
/* enable interrupt */ sdio_writel(sdio->func, WHLPCR_INT_EN_SET, MCR_WHLPCR, NULL); sdio_release_host(sdio->func);Regards,
LorenzoQuoted 3 lines
--
2.25.1
Re: [PATCH 2/2] mt76: mt7921s: fix the device cannot sleep deeply in suspend
Quoted 38 lines
From: Sean Wang <[email protected]>
Quoted 36 lines
Quoted 35 lines
From: Sean Wang <[email protected]>
<snip>
Quoted 18 lines
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
(quoted diff) +0
-6- if (test_bit(MT76_MCU_RESET, &dev->phy.state)) { - if (!mt76s_txqs_empty(dev)) - continue; - else - wake_up(&sdio->wait); - }} while (nframes > 0);Quoted 4 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+ if (test_bit(MT76_MCU_RESET, &dev->phy.state) && + mt76s_txqs_empty(dev)) + wake_up(&sdio->wait); +If doing so,
mt76s_txqs_emptymay not always be true because enqueuing packets toq_txor MCU command toq_mcusimultanenously from the other contexts in different cpu is possible.Quoted 4 lines
Quoted 2 lines
It seemed to me we should check it for each iteration to guarantee
that we can wake up the one that is waiting for the all the queues are empty at some time.IIUC what we are interested here is there are no queued frames into the hw queues during suspend or reset, right?
That is not completely true. Take the suspend procedure on mt7921s as an example.
That should be "There are no queued frames into the hw queues right after
mt76_connac_mcu_set_hif_suspend."The MCU data and WiFi are all handled in
mt76s_txrx_workerso we
should synchronize all of the Tx queues are all empty and then handlemt76_connac_mcu_set_hif_suspendto guaranteemt76_connac_mcu_set_hif_suspendis the last one to access the SDIO bus and there is no frame that accesses SDIO bus afterhand.
Quoted 8 lines
Quoted 2 lines
ack, correct, "there are no queued frames into the hw queues right after
mt76_connac_mcu_set_hif_suspend."
What I mean is we are not really checking there are no frames in the hw queue here, but mt76 sdio has processed all the frames, got my point? maybe it is what we are looking for..It seemed to me there is no a way to check if no frames in the hw queue for mt7921s
I think we can discuss the topic "it is ok move the check out of the loop" with another patch in the future
because it seemed not related to the patch.
sure, fine to me.
Regards,
Lorenzo
Quoted 23 lines
Quoted 23 lines
Regards,
LorenzoQuoted 18 lines
Quoted 18 lines
Quoted 17 lines
Quoted 16 lines
Quoted 13 lines
/* enable interrupt */ sdio_writel(sdio->func, WHLPCR_INT_EN_SET, MCR_WHLPCR, NULL); sdio_release_host(sdio->func);Regards,
LorenzoQuoted 3 lines
--
2.25.1