Enable SPI0 with buildroot image

General Discussion
1

Hello,
We’re working on a project that uses the beagle bone black to drive an HDMI screen to display some information gathered from some sensors using QT.
It was decided to use the buildroot image because it already contains a configuration that uses QT5 and enables the GPU (beaglebone_qt5_defconfig), and the boot time can be optimized easier.

Now to the issue we’re facing, after enabling SPI 0 by adding:

&am33xx_pinmux {
	spi0_pins: pinmux_spi0_pins {
		pinctrl-single,pins = <
			/* P9_22: spi0_sclk.spi0_sclk */
			BONE_P9_22 (PIN_INPUT_PULLUP | MUX_MODE0)
			/* P9_21: spi0_d0.spi0_d0 */
			BONE_P9_21 (PIN_INPUT_PULLUP | MUX_MODE0)
			/* P9_18: spi0_d1.spi0_d1 */
			BONE_P9_18 (PIN_INPUT_PULLUP | MUX_MODE0)
			/* P9_17: spi0_cs0.spi0_cs0 */
			BONE_P9_17 (PIN_INPUT_PULLUP | MUX_MODE0)
		>;
	};
};

&spi0 {
	pinctrl-names = "default";
	pinctrl-0 = <&spi0_pins>;
	status = "okay";

	spi0@0 {
		#address-cells = <1>;
		#size-cells = <0>;
		spi-max-frequency = <24000000>;
		reg = <0>;
		compatible = "spidev";
		symlink = "spi/0.0";
	};
};

to the corresponding DTS we encounter the following error when launching a kernel module designed to talk to one of the sensors on SPI: omap2_mcspi 48030000.spi: chipselect 0 already in use

Searching the internet for this error message only returns information related to the cape manager, which this image isn’t using and dts overlays which aren’t enabled.

Any suggestion/comment would be much appreciated.
Pavel

2

I would guess given the error message that some other peripheral has already grabbed that pin.

You will need to look through all the the dts/dtsi files that are being used ad try to find out what it is. You could search for BONE_P9_17, whatever is grabbing the pin may not be using that macro.

That pin is used by I2C1 SCL and UART0 TXD, so would check them first and of course it could also be a GPIO pin.

3

Hi Benedict,

This was also our thinking, that some other device was acquiring the pin. We spent some time going over the schematic and dts to figure out what was going on and it seems it was the user space spidev grabbing the pin.
The issue was masked because the kernel wasn’t built with user space SPI (CONFIG_SPI_SPIDEV=n). We weren’t seeing spidev in /dev and at the same time couldn’t use the interface from kernel.

Commenting out:

spi0@0 {
		#address-cells = <1>;
		#size-cells = <0>;
		spi-max-frequency = <24000000>;
		reg = <0>;
		compatible = "spidev";
		symlink = "spi/0.0";
	};

allowed the kernel module to access the SPI.

Now the problem is that we’re seeing gaps between bytes of the same transfer. We will investigate the relevant linux doc to see if it can be improved or we need to use the PRUs.

Thank you,
Pavel