On 10/23/24 9:17 AM, Ajay.Kathat@xxxxxxxxxxxxx wrote:
Hello Ajay,
What I am trying to say is this:
With current code, this can happen, which is not good, because transfers
from multiple threads can be interleaved and interfere with each other:
Did you observe any bus failure in your test setup with SDIO. Is there any
configure to recreate it.
I am observing sporadic command and data CRC errors on STM32MP157F
system with SDIO WILC3000.
The SDIO transfer may appear to be split into into multiple transaction but
these calls should not impact each other since most of them are updating the
different registers except WILC_SDIO_FBR_CSA_REG register, which is used for
CSA read/write. If needed, wilc_sdio_set_func0_csa_address() can be modified
to club the 3x CMD52 and 1x CMD53 into a single transfer API.
In my opinion, If sdio_claim_host() is moved to acquire_bus() API then the
SDIO bus will be claimed longer than required especially in
wilc_wlan_handle_txq() API. Ideally, calling sdio_claim_host() call just
before the transfer is enough but now the SDIO I/O bus would be continuously
blocked for multiple independent SDIO transactions that is not necessary.
Why would that pose a problem ?
I am more concerned that ksdioirqd can insert a command transfer right
in the middle of CMD52/CMD53 register read composite transfer, because
while ksdioirqd does use proper sdio_claim/release_host, this driver
does it per-SDIO-command instead of per the whole e.g. register read
"transaction".
[...]
