So, I'd like to provide some patches for the wilc driver, but I'm
unclear what the most effective way to go about this is.
The driver in mainline (driver/net/wireless/microchip/wilc1000) only
seems to support WILC1000 (not WILC3000) and uses firmware:
atmel/wilc1000_wifi_firmware-1.bin
whereas the linux-at91 driver (driver/staging/wilc1000) supports both
WILC1000 and WILC3000 and uses firmware
mch/wilc1000_wifi_firmware.bin
(for WILC1000).
For the hardware I have (embedded system with WILC1000/SPI), the
mainline driver doesn't load, whereas the driver from linux-at91 does
load and work(mostly).
I'd really like to work off of mainline since it's much easier to track
things with a repository that's updated frequently, but it looks to me
like the mainline may be missing a lot of code that's already in
linux-at91.
What am I supposed to do?
--david
Thanks David. I appreciate your efforts to contribute for WILC driver.
On 22/02/21 5:52 am, David Mosberger-Tang wrote:
>
> So, I'd like to provide some patches for the wilc driver, but I'm
> unclear what the most effective way to go about this is.
To submit the patches for wilc1000 mainlined driver, please send the
patches to linux-wireless mailing list. Have a look at *submitting
patch* section in wireless wiki to know about the patch submission process.
Please refer the below link:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
> The driver in mainline (driver/net/wireless/microchip/wilc1000) only
> seems to support WILC1000 (not WILC3000) and uses firmware:
>
> atmel/wilc1000_wifi_firmware-1.bin
>
> whereas the linux-at91 driver (driver/staging/wilc1000) supports both
> WILC1000 and WILC3000 and uses firmware
>
> mch/wilc1000_wifi_firmware.bin
>
> (for WILC1000).
The WILC1000 15.4 firmware(wilc1000_wifi_firmware-1.bin) is available at
linux-firmware repo.
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Please use this firmware for your testing.
>
> For the hardware I have (embedded system with WILC1000/SPI), the
> mainline driver doesn't load, whereas the driver from linux-at91 does
> load and work(mostly).
>
What error are you getting during driver loading. Could you please check
if FW file is available at "atmel/wilc1000_wifi_firmware-1.bin" path.
> I'd really like to work off of mainline since it's much easier to track
> things with a repository that's updated frequently, but it looks to me
> like the mainline may be missing a lot of code that's already in
> linux-at91.
>
> What am I supposed to do?
The mainlined driver only support for WILC1000. WILC3000 chip(Wifi+BT
combo) support needs to be added. Earlier the wilc driver was part of
staging so adding new features were not encouraged but now new features
are welcome.
We need to port different features to the mainlined driver. Recently we
have added the support for WMM[1]. Similarly we need to add other
features(like wilc3000 support) to the mainline driver by following
kernel development guideline.
1. https://www.spinics.net/lists/linux-wireless/msg205899.html
Regards,
Ajay
Ajay,
On Mon, 2021-02-22 at 10:01 +0000, [email protected] wrote:
>
> On 22/02/21 5:52 am, David Mosberger-Tang wrote:
> > So, I'd like to provide some patches for the wilc driver, but I'm
> > unclear what the most effective way to go about this is.
>
> To submit the patches for wilc1000 mainlined driver, please send the
> patches to linux-wireless mailing list. Have a look at *submitting
> patch* section in wireless wiki to know about the patch submission process.
>
> Please refer the below link:
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
OK.
> > The driver in mainline (driver/net/wireless/microchip/wilc1000) only
> > seems to support WILC1000 (not WILC3000) and uses firmware:
> >
> > atmel/wilc1000_wifi_firmware-1.bin
> >
> > whereas the linux-at91 driver (driver/staging/wilc1000) supports both
> > WILC1000 and WILC3000 and uses firmware
> >
> > mch/wilc1000_wifi_firmware.bin
> >
> > (for WILC1000).
>
> The WILC1000 15.4 firmware(wilc1000_wifi_firmware-1.bin) is available at
> linux-firmware repo.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Please use this firmware for your testing.
OK, can do.
> > For the hardware I have (embedded system with WILC1000/SPI), the
> > mainline driver doesn't load, whereas the driver from linux-at91 does
> > load and work(mostly).
>
> What error are you getting during driver loading. Could you please check
> if FW file is available at "atmel/wilc1000_wifi_firmware-1.bin" path.
OK, the first issue was a trivial one: the mainline driver doesn't
appear to support the reset-gpios so, on our platform, the chip
remained in RESET and it never responded to anything. Was reset-gpios
never supported in the mainline driver or was there a reason to remove
that support?
Anyhow, I worked around the reset issue. Next problem: from what I can
see, wlan.c:chip_allow_sleep() only support SDIO, not SPI. To work
around this issue, I just commented out the
chip_wakeup()/chip_allow_sleep() calls in acquire_bus() and
release_bus() for now.
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.
> The mainlined driver only support for WILC1000. WILC3000 chip(Wifi+BT
> combo) support needs to be added. Earlier the wilc driver was part of
> staging so adding new features were not encouraged but now new features
> are welcome.
> We need to port different features to the mainlined driver. Recently we
> have added the support for WMM[1]. Similarly we need to add other
> features(like wilc3000 support) to the mainline driver by following
> kernel development guideline.
>
> 1. https://www.spinics.net/lists/linux-wireless/msg205899.html
OK, thanks for the background. That's helpful.
--david
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.
--david
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.
Hi David,
On 23/02/21 9:53 pm, David Mosberger-Tang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> 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.
>
As I understand you are testing with default powersave mode enabled. One
approach could be to disable the default powersave mode by compiling
with CFG80211_DEFAULT_PS disabled. When its disabled, .set_power_mgmt cb
is called with powersave disable.
If the powersave mode is enabled, the chip need to be wakeup by
following the wakeup sequence. We need to bring in chip_wake() API
changes, to set registers specific for WILC1000. I have plans to port
these changes to support PSM mode but it will take few weeks.
Regards,
Ajay
> --david
>
>
> 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.
>
>
>
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
On Tue, 2021-02-23 at 17:19 +0000, [email protected] wrote:
> Hi David,
>
> On 23/02/21 9:53 pm, David Mosberger-Tang wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > 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.
> >
>
> As I understand you are testing with default powersave mode enabled. One
> approach could be to disable the default powersave mode by compiling
> with CFG80211_DEFAULT_PS disabled. When its disabled, .set_power_mgmt cb
> is called with powersave disable.
> If the powersave mode is enabled, the chip need to be wakeup by
> following the wakeup sequence. We need to bring in chip_wake() API
> changes, to set registers specific for WILC1000. I have plans to port
> these changes to support PSM mode but it will take few weeks.
Indeed. Sure, I'll just compile with powersave mode disabled for now
until you've had a chance to bring forward the missing pieces.
Thanks!
--david
Nicolas,
On Tue, 2021-02-23 at 18:58 +0100, Nicolas Ferre wrote:
> 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.
Ah, *that's* where the RESET pins are hiding. Yeah, it wouldn't have
occurred to me to like in the MMC subsystem, but I see there is a
precedent for another WiFi chip using that place. OK, I things are
starting to make sense and I should be able to work on the actual
patches I've been meaning to submit.
Thanks for the help!
--david