[Zephyr] Suggestion on removing nrf7002 dts binding file QSPI on-bus label

[rolandash]

Dear Nordic,

Currently nrf7002 dts binding file for QSPI bus has an 'QSPI' label inside for [compatible, on-bus] scheme matching, This may cause problem on non-NRF host MCU, because 'QSPI' is not really a standard name as 'SPI' among different host MCU families, which in the end may result in the failure of the binding process. 

For example, on stm32 processor, QSPI is regarded as a special 'spi' bus controller, any device node (like nrf7002) on this QSPI bus is resolved into something like 'node_name@spi'. It is obvious that Zephyr device tree binding tool will fail to match the name, and all properties under the node are missed in generated device tree file.

It is suggested to remove the 'QSPI' label in dts binding file, because the [compatible, on-bus] matching scheme only put formal constrains and does mot mean anytihing during real runtime. On the other hands, as 'SPI' is a real 'standard' name, it is actually recommended to put a 'SPI' label in 7002's dts binding file for SPI bus.

Thank you for your attention to this issue.

/Roland

[Elfving]

Thanks for the suggestion! I've forwarded this to the relevant team.

Regards,

Elfving

[rolandash]

Thank you Elfving .

Expecting feedback from the team soon.

/Roland

[Elfving]

I agree with your line of thinking when it comes to this improvement request, though it might be that the relevant R&D team won't be able to consider this change immediately, as it is not a bug per se. If you want this to get a priority, please contact your local regional sales manager about it.

Regards,

Elfving

[rolandash]

It is a bug, because otherwise on stm32 mcu it even can not compile when using QSPI interface with nrf7002.  'Suggestion' is another more gentle way to express the same thing.

Anyway, if your R&D team does not care about it then just forget it as nothing happened.

/Roland

[Elfving]

rolandash said:

Anyway, if your R&D team does not care about it then just forget it as nothing happened.

We always care, the question is just about how quickly we'll be able to address it. Got a bit of a response back here.

rolandash said:

It is a bug, because otherwise on stm32 mcu it even can not compile when using QSPI interface with nrf7002.

The nRF7002 QSPI should only be used with NRF devices (like you say QSPI is not standard, it’s tied to vendor), the QSPI driver (zephyr/modules/nrf_wifi/bus/qspi_if.c at main · zephyrproject-rtos/zephyr ) doesn’t work with non-NRF devices. So, you should be using nrf7002-spi binding for STM32, though the underlying bus might be QSPI.

Regards,

Elfving

[rolandash]

Thank you Elfving , for the effort and the feedback. I appreciate that.

Unfortunately the suggested method in the feedback does not work along with the structure of the current driver. The SPIM part of the driver code is bonded to standard SPI driver interfaces of Zephyr OS, which means if this interface was changed to other type of protocol then all other standard SPI peripherals on other SPI buses will be broke. The driver code still needs to be hacked before the system can work, and not to mention that this may further confuse people on what exactly does 'SPI' means from logical level.

The purpose of this post is not looking for any instant hot fix or likewise. I understand Nordic is providing these for free and I really appreciate that. Since Nordic already mentioned about non-NRF host mcu support in commitments of this driver, I assume the intention was to enable nrf's wifi on different platforms as possible, which in my view is great and will benefit everyone in overall effects. 

If my understanding of the intention is correct, then please take the suggestion in this post into consideration before the next update to the driver. Although developers can hack the driver code as they want in their customized repo, but it may not worth doing that only for a driver compatibility problem to maintain another dedicated branch/repo for it. The eco-system has been already fragmented too much.

/Roland

[Elfving]

Understood. Thanks for the suggestion, I understand that this can be both confusing for those not using a nordic MCU, as well potentially problematic. We'll consider this.

Regards,

Elfving

[Joey Wang]

I’m currently working on the STM32H757I together with the nRF7002.

We are still facing the same issue with the QSPI configuration. Have you been able to resolve this QSPI problem on your side?

It would be great if you could provide some guidance.

MCU: STM32H757I
Wi-Fi Module: nRF7002
IDE: Zephyr SDK

Right now, my DTS is configured in SPI mode, but I want to switch it to QSPI mode.

/* Configure SPI1 for high-speed nRF7002 communication (for h757 board) */
&spi1 {
	
    status = "okay";
	//pinctrl-0 = <&spi1_sck_pg11 &spi1_miso_pg9 &spi1_mosi_pd7 &spi1_nss_pg10>;
	pinctrl-0 = <&spi1_sck_pg11 &spi1_miso_pg9 &spi1_mosi_pd7>;
	pinctrl-names = "default";
	cs-gpios = <&gpiog 10 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; // NSS PG10

	dmas = <&dmamux1 3 38 0x20440>,  // 0x20440 
	       <&dmamux1 2 37 0x20480>;   // 0x20480
	dma-names = "tx", "rx";

	/* High speed SPI configuration for STM32H7 */
	clock-frequency = <DT_FREQ_M(8)>; /* 50MHz SPI clock */
	status = "okay";

	nrf70: nrf7002-spi@0 {
		compatible = "nordic,nrf7002-spi";
		status = "okay";
		reg = <0>;
		spi-max-frequency = <DT_FREQ_M(8)>; /* Increased from 8MHz to 16MHz */

		/* Control GPIOs - using available pins that don't conflict */
		iovdd-ctrl-gpios = <&gpioj 8 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* D0 */
		bucken-gpios = <&gpioj 9 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;     /* D1 */
		host-irq-gpios = <&gpioj 10 GPIO_ACTIVE_HIGH>;                     /* D7 */
		
		/* List of interfaces */
		wlan0: wlan0 {
			compatible = "nordic,wlan";

		};
		
		/* Wi-Fi TX power limits */
		wifi-max-tx-pwr-2g-dsss = <21>;
		wifi-max-tx-pwr-2g-mcs0 = <16>;
		wifi-max-tx-pwr-2g-mcs7 = <16>;
		wifi-max-tx-pwr-5g-low-mcs0 = <13>;
		wifi-max-tx-pwr-5g-low-mcs7 = <13>;
		wifi-max-tx-pwr-5g-mid-mcs0 = <13>;
		wifi-max-tx-pwr-5g-mid-mcs7 = <13>;
		wifi-max-tx-pwr-5g-high-mcs0 = <12>;
		wifi-max-tx-pwr-5g-high-mcs7 = <12>;
	};
};