Hi David,
On 23/02/2021 at 17:23, David Mosberger-Tang wrote:
OK, the problem below is caused by wilc_set_power_mgmt(). If I change
that function into a no-op, the driver actually works! Does this make
any sense to you? From what I saw so far, it looks like relevant code
is pretty much identical to the one in the linux-at91 tree and that one
works fine.
One thing that comes off the top of my head is that we use
power-sequencing drivers in the Linux4SAM trees. The use of pwrseq
drivers allow us to adapt the power/sequencing/delays/reset to the
actual board the wilc1000 but moreover the wilc3000 is soldered to.
Indeed the wilc3000 needs special sequence to be up'n running if some
clock signals are connected to the SoC output for instance.
You can have an example of a pwrseq driver here:
drivers/mmc/core/pwrseq_wilc.c
(https://github.com/linux4sam/linux-at91/blob/master/drivers/mmc/core/pwrseq_wilc.c).
There are other pwrseq drivers for other WiFi chips and boards there.
True thing is that this sequencing seems dedicated to mmc sub-system and
I don't know if it can be used for SPI-based WiFi connections or if
another mechanism exists.
Anyway, hope that it helps.
Best regards,
Nicolas
On Mon, 2021-02-22 at 18:49 -0700, David Mosberger-Tang wrote:
Now the driver loads the firmware and generally seems to be happy.
However, as soon as a packet is received, things go awry. I'm seeing
this:
WILC_SPI spi1.0 wlan0: ChipID [1003a0] loading firmware
[atmel/wilc1000_wifi_firmware-1.bin]
WILC_SPI spi1.0: Failed cmd response, cmd (ca), resp (09)
On the SPI bus, I see these commands:
MOSI: 0xC8 0x00 0x00 0x00 0x00 0x00 0x38 (DMA_EXT_READ addr 0 size 56)
MISO: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xC8 0x88 (command response)
-----
MOSI: 0x00
MISO: 0xF3 (DATA header, last packet in this transaction)
-----
MOSI: 0x00*56
MISO: xx*56 (56 data bytes that may be a legitimate packet)
So far so good. I don't know if this matters, but the last 8 bytes of
data all contain 0x09.
The problem from then on is that no matter what command is sent, the
chip always returns only 0x09 bytes. For example, the first command
after the DMA read is:
MOSI: 0xca 0x00 0x10 0x6c (SINGLE_READ)
but the MISO line only returns 0x09, hence the above "Failed cmd
response" error.
It's as if the chip wants to send much more than 56 data bytes. The
byte-order for the DMA size matches that of the working driver though,
so maybe that's not it.
--
Nicolas Ferre
