topic Re: CS not working as GPIO, just native in i.MX Processors

CS not working as GPIO, just native

sibo — Mon, 18 May 2020 14:00:49 GMT

Hi guys,

I have a problem with my spi settings.

When I use the CS in native configuration, like so:

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index 039ece96b9b2..a96340455ef3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -282,6 +282,16 @@
>;
};

+&ecspi2 {
+ fsl,spi-num-chipselects = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+
+ spidev@0x00 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+};
+
&usbotg1 {
picophy,pre-emp-curr-control = <3>;
picophy,dc-vol-level-adjust = <7>;
--
2.17.1

it works:

but using it as GPIO, like:

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index 039ece96b9b2..f8350b5078e8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -282,6 +282,16 @@
>;
};

+       pinctrl_ecspi2: ecspi2grp {
+               fsl,pins = <
+                       MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK            0x156
+                       MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI            0x156
+                       MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO            0x156
+                       MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13              0x156
+
+               >;
+       };
+
        pinctrl_usdhc1_gpio: usdhc1grpgpio {
                fsl,pins = <
                        MX8MN_IOMUXC_SD1_RESET_B_GPIO2_IO10     0x41
@@ -754,6 +764,20 @@
        status = "okay";
};

+&ecspi2 {
+        fsl,spi-num-chipselects = <1>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&pinctrl_ecspi2>;
+        cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+        status = "okay";
+
+       spidev@0x00 {
+             compatible = "spidev";
+             reg = <0>;
+             spi-max-frequency = <10000000>;
+       };
+};
+
&usbotg1 {
        picophy,pre-emp-curr-control = <3>;
        picophy,dc-vol-level-adjust = <7>;
--
2.17.1

it does not work

My Board is a NXP i.MX8MNano DDR4 EVK board.

I use the patches for linux-imx in yocto with this build configuration:

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "imx8mnevk"
DISTRO               = "fsl-imx-xwayland"
DISTRO_VERSION       = "5.4-zeus"
TUNE_FEATURES        = "aarch64"
TARGET_FPU           = ""

Is there something wrong with my gpio configuration for spi-imx driver?

Thanks in advance,

Silke

Re: CS not working as GPIO, just native

igorpadykov — Mon, 18 May 2020 23:40:01 GMT

Hi Silke

what bsp used in the case, one can to try from nxp

source.codeaurora.org/external/imx/linux-imx repository
linux-imx - i.MX Linux kernel

MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13 is used on

imx8mn-evk.dts\freescale\dts\boot\arm64\arch - linux-imx - i.MX Linux kernel

and one can test it on EVK with Demo Image

Linux Binary Demo Files - i.MX 8M Nano EVK

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: CS not working as GPIO, just native

sibo — Tue, 19 May 2020 08:46:26 GMT

Hi Igor,

actually, this was my starting point.

I used the ecspi nodes from the imx8mn-evk.dts file and applied them to the imx8mn-ddr4-evk.dts. Just later on, I changed the mux values at the end to use a pullup and drive strength x6 (for the purpose to use my logic analyzer).

I tried the original again but with no success.

I tried out the demo images "imx-image-multimedia-imx8mnevk.sdcard" and "imx-image-full-imx8mnevk.sdcard", too but they do not even have a spidev in it, so I can not test the spi bus (or can I?).

Any ideas? I really appreciate your help :smileyhappy:

Greetings,

Silke

Re: CS not working as GPIO, just native

igorpadykov — Tue, 19 May 2020 11:20:27 GMT

Hi Silke

>I tried out the demo images "imx-image-multimedia-imx8mnevk.sdcard" and "imx-image-full-imx8mnevk.sdcard", >too but they do not even have a spidev in it,

actually it does have spidev :

Best regards
igor

Re: CS not working as GPIO, just native

sibo — Tue, 19 May 2020 15:12:52 GMT

Hmmm this is getting interesting.

The thing is, that my board does not load the imx8mn-evk.dtb, but the imx8mn-ddr4-evk.dtb.

When I erase the former one from the sd card (boot folder), I can boot it normally.

When I erase the later one, I see

Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
26616320 bytes read in 1179 ms (21.5 MiB/s)
Booting from mmc ...
WARN: Cannot load the DT
u-boot=>

instead.

Perhaps U-Boot is loading the wrong device tree?

How can I change that? Shouldn't that be done automatically by ... I don't know... some variable in a stored register or something like that?

Best regards,

Silke

Re: CS not working as GPIO, just native

igorpadykov — Tue, 19 May 2020 23:23:08 GMT

Hi Silke

one can look at Linux 5.4.3_1.0.0 Documentation

Linux Guide, Yocto Guide and https://community.nxp.com/docs/DOC-94849

Best regards
igor

Re: CS not working as GPIO, just native

sibo — Tue, 26 May 2020 12:39:57 GMT

Hi Igor,

I read through the Documentation and could not find anything different from what I did.

What I WAS able to do, is switching the device tree in U-Boot itself.

When my board booted i stopped the autoboot.

u-boot=> setenv fdt_file "imx8mn-evk.dtb"

and

u-boot=> saveenv

After that I have the normal /dev/spidev1.0

but when I test it with the test programm in /unit_tests/ECSPI

root@imx8mnevk:/unit_tests/ECSPI# ./mxc_spi_test1.out -D 0 -s 12000 -b 8 1337

I do not see any CS change in my Logic Analyzer.

So I patched the imx8mn-evk.dts in yocto, changing the iomux of the pin to ECSPI2_SS0, because of a vague idea.

The native CS is toggled. This fits to the debug outprints, that I included in the used spi and gpio drivers of the kernel.

The spi master struct (which is spi_controller) gets an array named cs_gpios[], where the number of gpios are included by the gpiolib driver.

The later one can parse the "cs-gpios" property of the node, but the returnes gpio-chip is NULL.

This leads to the error -517, returned to cs_gpios.

The spi_imx driver goes through the cs_gpios and just for the one valid, it requests the numbered gpio.

So, because there is the error, the gpio is not requested and the native CS is used.

I am still figuring out, why the returned gpio chip is NULL and I will let you know, if I find anything.

Interestinly, the spi is not the only thing with this error. So is wm8524-codec and imx_sec_dsim_drv and imx-drm.

Best regards,

Silke

Re: CS not working as GPIO, just native

sibo — Mon, 15 Jun 2020 13:49:01 GMT

I found out, why the driver did not use the gpio for spi.

Digging through the different drivers calling each other, I found out that the gpio driver uses a list object for its gpios. This list object is empty when the spi-imx driver is probed.

Therefore the error -517 (given by the gpio driver) is -EPROBE_DEFER, meaning that the probe should be deferred and called again at a later time.

In the spi-imx driver, this error is not regarded but handled as a normal GPIO number, which is considered invalid and therefore ignored.

By patching the spi-imx driver like

---
drivers/spi/spi-imx.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 91e32291c44e..f465d372e475 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1775,8 +1775,14 @@ static int spi_imx_probe(struct platform_device *pdev)
/* Request GPIO CS lines, if any */
if (!spi_imx->slave_mode && master->cs_gpios) {
for (i = 0; i < master->num_chipselect; i++) {
- if (!gpio_is_valid(master->cs_gpios[i]))
+ if (!gpio_is_valid(master->cs_gpios[i])){
+ if(master->cs_gpios[i] == -EPROBE_DEFER){
+ /*gpios not initialized yet, deferring probe*/
+ ret = -EPROBE_DEFER;
+ goto out_spi_bitbang;
+ }
continue;
+ }

ret = devm_gpio_request(&pdev->dev,
master->cs_gpios[i],
--
2.17.1

, the probe is deferred and called at a later time. Then the gpio-list is already filled and the right gpios are used.

Now, the CS works as expected

Perhaps someone else could use that information, too. I saw some other drivers which broke down at this point, too.

Best regards,

Silke