[AM335x] Mcasp and gpio

I am trying to remove un-needed code from my device tree. I don’t have a mcasp (Multichannel Audio Serial Port) on my custom board. When I remove the the following from my DT then my GPIO lines stop working. I mean that my user program, which uses mmap() to get to the GPIO, no longer can use the GPIO.

&am33xx_pinmux {
        // note: I don't remove the entire &am33xx_pinmux, I only remove the mcasp0_pins node
	mcasp0_pins: mcasp0_pins {
		pinctrl-single,pins = <
			AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLUP | MUX_MODE0)	/* (A14) mcasp0_ahcklx.mcasp0_ahclkx */
			AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* (C12) mcasp0_ahclkr.mcasp0_axr2*/
			AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE0)	/* (B13) mcasp0_fsx.mcasp0_fsx */
			AM33XX_IOPAD(0x990, PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* (A13) mcasp0_aclkx.mcasp0_aclkx */
			AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7)	/* (V17) gpmc_a11.GPIO1_27 */
		>;
	};
};

&mcasp0	{
	#sound-dai-cells = <0>;
	pinctrl-names = "default";
	pinctrl-0 = <&mcasp0_pins>;
	status = "okay";
	op-mode = <0>;	/* MCASP_IIS_MODE */
	tdm-slots = <2>;
	serial-dir = <	/* 0: INACTIVE, 1: TX, 2: RX */
			0 0 1 0
		>;
	tx-num-evt = <32>;
	rx-num-evt = <32>;
};

/ {
	clk_mcasp0_fixed: clk_mcasp0_fixed {
		#clock-cells = <0>;
		compatible = "fixed-clock";
		clock-frequency = <24576000>;
	};

	clk_mcasp0: clk_mcasp0 {
		#clock-cells = <0>;
		compatible = "gpio-gate-clock";
		clocks = <&clk_mcasp0_fixed>;
		enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
	};
};

My best guess is that when I remove the above that I am also taking out a clock (or something) that allows the GPIO function.

What part of the above code is needed by the GPIO?
How to remove the mcasp code and add something to allow to GPIO to work?

Thank you,

Hi @jakthree , are you defining the GPIO you are using anywhere in the device-tree? Today there are a lot of kernel sub-systems that need to be utilized/enabled to properly configure the GPIO on the am335x. I believe your mmap (not recommended) either relied on the GPIO state, or the GPIO’s peripheral bus clocked when the old mcasp values where defined in the device tree.

Are these GPIO defined as input or output connnections?

Regards,

Robert,
Kernel 4.19.106-bone49 (bb-kernel).
I am new to using this forum so please excuse me if I don’t attach my .dts, .dtsi files correctly. I appended .txt extension and uploaded. If there is a preferred or better way to get content posted then please explain.
zcpu-common.dtsi.txt (13.8 KB) zcpu-main.dts.txt (1.0 KB) zcpu.dtsi.txt (30.0 KB)

I have found no instructions for adding pin configuration so I added ‘gpio1_pins_default:…’ and 'gpio2_pins_default:…" to &am33xx_pinmux.
I also added ‘&gpio1’ and ‘&gpio2’.

Your answer made me think to check which pad gpio1_27 (V17) was being used in more than one place. I found that my ‘cpsw_default’ slave2 PHY is using (V17) as rmii2_rxd0. (V17) is connected PHY2 on my board. I remember reading that the GPIO controller needs a clock to move the state from the bus into memory for the user program to read it. If there is no clock then the memory never gets updated. (or something like that)

Can another pad be used by casp for GPIO?

I understand mmap() is not recommended but it was the first google search result I found, so I used it and it worked. At the time I only knew abou mmap() and /sys/class/gpio (sysfs???). My application is an embedded industrial controller that need to read and write I/O every millisecond. I prefer to read in the entire bank, mask out the inputs, set the outputs and write the outputs all out at one time. I found I could do this with mmap() but not with /sys/class/gpio. I only discovered two days ago that character device /dev/gpiochipN was available. I found /tools/gpio examples and I want to try them after getting mmap() to work. The examples use ioctl() calls and can read/write the entire bank (if needed).
Are these calls capable of running faster than 1 millisecond?

Thank you,

One place is in under the pinmux:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi#n67

The PRU on the am335x is actually perfect for that situation.

https://markayoder.github.io/PRUCookbook/

Regards,

Robert,

I have a working device tree, well at least until I find something broken. I have tested all subsystems on my board except rmii1 and rmii2. The rmii1_refclk and rmii2_refclk lines are not connected to my LAN8710 PHY so I can’t bring the ethernet ports up. The lines will be fixed in the next board revision.

I have moved from using mmap() to libgpiod. gpioget is reporting the input is inverted. Here is pin config from my device tree
AM33XX_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE7)
The input has an external 3.3v pullup resistor. When input is pulled low (connected to common) then gpioget should report active. I want to set the input to ‘active low’.

Can the pin config configure the pad as ‘active low’. (low = 1, high = 0)

Thank you,

Robert,
Some follow up. I have been working with moving from u-boot 2019.04 to barebox 2021.03 for my boot loader. u-boot used kernel 4.19.106. barebox uses kernel 5.11.10. I edited my custom 4.10.106 device tree to work with kernel 5.11.10. That in itself was a job. After I got barebox and the kernel to boot, I found I had the same GPIO clock not enabled problem today where my GPIO was not working unless I executed ‘echo 5 > /dev/gpio/export’ command. I found enabling these kernel config setting fixed the problem.

LEDS_CLASS = Y
LEDS_GPIO = Y

My guess is that building these setting into the kernel allowed the ‘leds’ node of my custom device tree to enable the GPIO clock(s) when the output state was set by the kernel when parsing the device tree.

snippet from my DT…

leds {
	pinctrl-names = "default";
	pinctrl-0 = <&user_leds_s0>;
	compatible = "gpio-leds";
	led1 {
		label = "custom:green:usr0";
		gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
		default-state = "off";
	};
};

I think the default-state = “off”; sets the output also starts the clock.

Your comments are welcome,