On 8/29/24 7:51 AM, Ajay.Kathat@xxxxxxxxxxxxx wrote:
Hi,
This patch assures the chip does not get power-cycled during
suspend/resume cycle, which makes it lose state (and firmware), so the
chip is unusable after resume without this patch.
During host suspend, the firmware doesn't get power-cycled and also doesn't
forward the frames to the host.
If the slot is powered OFF, which it currently can be, then the entire
WILC gets power-cycled.
1. Without this patch, is the station getting disconnected from the AP during
the suspend state? Does a rescan and reconnect help to resume the connection
with the AP?
Rescan doesn't work because there is no firmware in the WILC.
2. With this patch, does the ping to the station work during the suspend state?
I haven't tested this, but that's unlikely because the host is
suspended. Still, that's not really the point here, the point is that
the whole WILC gets powered off during suspend/resume without this
patch. At least on STM32MP15xx it is, maybe on the Atmel controller it
is not, but we cannot depend on that.
AFAIR, during host suspend, the firmware continues to run without passing
frames to the host unless 'wowlan' is enabled.
There is another scenario. Let's assume a host that wants to go to suspend
(power save mode) without caring about the WiFi status, i.e., it is okay to
reconnect with the AP if required (anyway, the AP may disconnect the station
based on inactivity timeout) or have to re-trigger the DHCP request again. But
with this change, the driver would block the host from entering suspend mode.
How about adding an 'if' check for host pm_caps before calling
sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER)? In that case, it will only
request when configured by the host platform.
Since this driver does not reload the firmware into the card on resume,
the card has to be kept powered on during suspend/resume cycle. The card
can NOT be powered off during suspend/resume cycle, otherwise the
firmware is lost.
Without this flag, the card may be powered off during suspend/resume
cycle. It possibly does not happen on the Atmel controller, but it does
on the STM32MP15xx ARM MMCI one.
Now, since the card does consume about the same amount of power whether
it is powered OFF or whether it is powered ON but suspended, I opt for
the later option -- keep the card powered ON, suspend it, and that's
what this patch does. This also allows us to support WoWlan then.
It may be that when the
power consumption was measured,the WILC suspend state is not enabled because
of MMC controller pm_caps in the test setup.
I think it is better to have a generic patch for any host which has
MMC_PM_KEEP_POWER capabilities defined or not. With proposed patch, driver
will not allow the host to go into the suspend state when MMC_PM_KEEP_POWER is
not set in PM caps. I think, sdio_set_host_pm_flags() should only be called if
MMC_PM_KEEP_POWER is defined in the host.
To retain firmware in the chip, the chip must not be powered off during
suspend/resume, which is what this patch assures. Without this patch,
the controller may power off the slot during suspend/resume and the WILC
will lose firmware and be unusable after resume.
Actually, WILC can support suspend mode with or without this host
capabilities. For SDIO, the host can be wake-up using the external IRQ GPIO
(uses out-of-band, instead of in-band interrupt) on WILC.
To test wake-on-wlan(wowlan) in suspend mode, the IRQ pin from WILC should be
connected with the host that will help to interrupt/wake the host when any
WiFi packet arrives. Without 'wowlan' enabled in suspend mode, the host should
be allowed to go into suspend mode but it can't be wake-up by WiFi packets.
All the packets will be dropped in the firmware in suspend state.
WILC supports only ANY option for wowlan. So, after connecting the IRQ line
with host, the below commands can be used to test "wowlan" in suspend state.
# iw phy <phyname> wowlan enable any
# echo mem > /sys/power/state
If the WILC is powered off because the slot is powered off, WILC cannot
resume anything.
I think, the wilc firmware should resume but the connection with AP may get
closed. Additional commands to scan and reconnect with AP may be required that
should work without downloading the firmware to wilc chip again.
Currently, the slot may get powered off and then there is no firmware.
