SPI2_SDO configuration for mcp2517fd

Embedded Devices Linux
, ,
1

Hi,

I’m using an ccimx8x-sbc-pro, and I’m trying to configure the devicetree so that I can use an mcp2517fd to get an additional can bus. To do so, I’ve added the following to my devicetree:

&lpspi0 {
	status = "okay";

	can4: can@3 {
		reg = <0>;
		compatible = "microchip,mcp2517fd";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_mcp2517fd>;
		spi-max-frequency = <4000000>;
		interrupt-parent = <&lsio_gpio1>;
		interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
		clocks = <&mcp2517fd_osc>;
		gpio-controller;
	};
};

&iomuxc {

	/* SPI0_IRQ_N */
	pinctrl_mcp2517fd: mcp2517fdgrp {
		fsl,pins = <
			IMX8QXP_SPI2_SDO_LSIO_GPIO1_IO01			0x24000060
		>;
	};
};

The mcp2517fd driver loads correctly and initializes the chip. However when I try to bring up the device:

ip link set can2 type can bitrate 500000
ip link set can2 up

The following error pops up:

tried to flag a GPIO set as output for IRQ

It seems as if my iomuxc configuration is not being applied. The pin has been commented from the pinctrl_expansion, so it should not be defined else where.

Does anyone have an idea on what I’m doing wrong?

2

please use smart IO mux tool to resolve IO configuration and generate proper device tree snippets

If the SPI is configured properly, please try to scope the signals on SPI pins to see if the CPU communicates properly with mcp2517fd
Check this page out as they are doing something very similar:

3

Hi @LeonidM,

It seemed like I was not able to apply my configuration to GPIO1_IO1 for some reason. I tried GPIO0_IO12, with the same pad configuration and it worked. This is okay for now, but ideally I would like to use GPIO1_IO1 instead. As far as I understand, the pin is only used in the expansion_grp. So I commented it there and added the pin to my own pinctrl group.

I have looked a little bit into smart iomux, but I fail to understand how I can add a custom component (the mcp2517fd driver) in the design.

Do you have some tips on how to do this?

4

So some more testing. I thought it was maybe related to lsio_gpio1, since GPIO0_IO12 worked, but I’ve tried GPIO1_13 now, and it works as well.

I’ve then checked /sys/kernel/debug/pinctrl/scu:pinctrl/pinmux-pins, which shows the pin to be claimed by spi0.0. This happens for any pin I configure. When GPIO1_IO1 is not used in my driver and commented in the expansion_grp, /sys/kernel/debug/pinctrl/scu:pinctrl/pinmux-pins shows that the pin is unclaimed and unused. When the pin is used, I can see the correct configuration of the pads as well.

Is this pin just not configurable as an input? I don’t understand how this specific pin is not able to be reconfigured.