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 @@
>;
};
+ 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_ECSPI2_SS0 0x156
+
+ >;
+ };
+
pinctrl_usdhc1_gpio: usdhc1grpgpio {
fsl,pins = <
MX8MN_IOMUXC_SD1_RESET_B_GPIO2_IO10 0x41
@@ -754,6 +764,19 @@
status = "okay";
};
+&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
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
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
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
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.
By
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
