* wilc1000 driver @ 2021-02-22 0:22 David Mosberger-Tang 2021-02-22 10:01 ` Ajay.Kathat 0 siblings, 1 reply; 8+ messages in thread From: David Mosberger-Tang @ 2021-02-22 0:22 UTC (permalink / raw) To: linux-wireless; +Cc: Ajay Singh, davidm 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-22 0:22 wilc1000 driver David Mosberger-Tang @ 2021-02-22 10:01 ` Ajay.Kathat 2021-02-23 1:49 ` David Mosberger-Tang 0 siblings, 1 reply; 8+ messages in thread From: Ajay.Kathat @ 2021-02-22 10:01 UTC (permalink / raw) To: davidm, linux-wireless 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-22 10:01 ` Ajay.Kathat @ 2021-02-23 1:49 ` David Mosberger-Tang 2021-02-23 16:23 ` David Mosberger-Tang 0 siblings, 1 reply; 8+ messages in thread From: David Mosberger-Tang @ 2021-02-23 1:49 UTC (permalink / raw) To: Ajay.Kathat, linux-wireless Ajay, On Mon, 2021-02-22 at 10:01 +0000, Ajay.Kathat@microchip.com 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-23 1:49 ` David Mosberger-Tang @ 2021-02-23 16:23 ` David Mosberger-Tang 2021-02-23 17:19 ` Ajay.Kathat 2021-02-23 17:58 ` Nicolas Ferre 0 siblings, 2 replies; 8+ messages in thread From: David Mosberger-Tang @ 2021-02-23 16:23 UTC (permalink / raw) To: Ajay.Kathat, linux-wireless 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-23 16:23 ` David Mosberger-Tang @ 2021-02-23 17:19 ` Ajay.Kathat 2021-02-23 18:06 ` David Mosberger-Tang 2021-02-23 17:58 ` Nicolas Ferre 1 sibling, 1 reply; 8+ messages in thread From: Ajay.Kathat @ 2021-02-23 17:19 UTC (permalink / raw) To: davidm, linux-wireless 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. > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-23 17:19 ` Ajay.Kathat @ 2021-02-23 18:06 ` David Mosberger-Tang 0 siblings, 0 replies; 8+ messages in thread From: David Mosberger-Tang @ 2021-02-23 18:06 UTC (permalink / raw) To: Ajay.Kathat, linux-wireless On Tue, 2021-02-23 at 17:19 +0000, Ajay.Kathat@microchip.com 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-23 16:23 ` David Mosberger-Tang 2021-02-23 17:19 ` Ajay.Kathat @ 2021-02-23 17:58 ` Nicolas Ferre 2021-02-23 18:09 ` David Mosberger-Tang 1 sibling, 1 reply; 8+ messages in thread From: Nicolas Ferre @ 2021-02-23 17:58 UTC (permalink / raw) To: David Mosberger-Tang, Ajay.Kathat, linux-wireless; +Cc: Claudiu Beznea 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: wilc1000 driver 2021-02-23 17:58 ` Nicolas Ferre @ 2021-02-23 18:09 ` David Mosberger-Tang 0 siblings, 0 replies; 8+ messages in thread From: David Mosberger-Tang @ 2021-02-23 18:09 UTC (permalink / raw) To: Nicolas Ferre, Ajay.Kathat, linux-wireless; +Cc: Claudiu Beznea 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-02-23 18:10 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-22 0:22 wilc1000 driver David Mosberger-Tang 2021-02-22 10:01 ` Ajay.Kathat 2021-02-23 1:49 ` David Mosberger-Tang 2021-02-23 16:23 ` David Mosberger-Tang 2021-02-23 17:19 ` Ajay.Kathat 2021-02-23 18:06 ` David Mosberger-Tang 2021-02-23 17:58 ` Nicolas Ferre 2021-02-23 18:09 ` David Mosberger-Tang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.