Acquire the SDIO as needed as possible because either MT7663S or MT7921S
is a multiple-function device that always includes Bluetooth that would
share with the same SDIO bus. So not to avoid breaking Bluetooth pairing,
audio, and HID such kind of time critical application on that, we only
lock sdio bus when it is necessary in WiFi driver.
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Update pm->suspended usage to be consistent with mt7921e driver.
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
Update pm->suspended usage to be consistent with mt7921e driver.
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
According to the MT7921S firmware, the cmd MCU_UNI_CMD_HIF_CTRL have to
be last MCU command to execute in suspend handler and all data traffic
have to be stopped before the cmd MCU_UNI_CMD_HIF_CTRL starts as well
in order that mt7921 can successfully fall into the deep sleep mode.
Where we reuse the flag MT76_STATE_SUSPEND and avoid creating
another global flag to stop all of the traffic onto the SDIO bus.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Reported-by: Leon Yen <[email protected]>
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
This is a preliminary patch for the following patch
("mt76: mt7921s: fix the device cannot sleep deeply in suspend).
mt76_connac_mcu_set_hif_suspend eventually would be handled in each
bus-level suspend/resume handler in either mt7921/sdio.c or mt7921/pci.c
depending on what type of the bus the device is running on. We can move
mt76_connac_mcu_set_hif_suspend to bus-related files to simplify the logic.
Signed-off-by: Sean Wang <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
