Change GPIO MUX globally - best practice

General Discussion
1

Dear beagleboard community
On my Beaglebone Black I want to disable the output of 24Mhz clock at the CLKOUT1 pin. We do not use the HDMI feature (it is used for the tda988x) and it interferes with our EMC compliance.
In order to do this I ended up with something like the following in arch/arm/boot/dts/am335x-boneblack.dts in a 4.4.14-bone11 Kernel tree (yes, old and ancient but applies to already delivered modules):

&am33xx_pinmux {
	nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
		pinctrl-single,pins = <
/*			0x1b0 0x03   */   /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
			0x1b0 0x00
			0x9b0 0x00 
			AM33XX_IOPAD(0x9b0, PIN_INPUT | MUX_MODE7)

So the initial 0x1b0 0x03 disabled, the other statements added by me changing to other function.
Quite redundant yet, 0x0b9 is wrong, but I suppose 0x1b0 0x00 does the trick. When I load the tdy988x module, the CLKOUT1 pin goes silent.

The question is, what is the best practice to do this in an actual (well, 5.10.x) kernel globally?
I investigate the dts tree further but all stuff done there applies to modules and drivers when active.
Is there a way to do something like this globally, like MUX GPIO this way ever on boot, regardeless what’s loaded enabled or disabled?
Regards
Konsti

2

HI @Konstantin one quick hack…

Do you use the hdmi for anything? If not, just force it to use the BeagleBone Green device-tree, which is a clone of the BeagleBone Black with no built-in HDMI…

Regards,

3

I do not use HDMI at all.
The Problem is, the MUXing is done at powerup via hardware at boot up via SYSBOOT settings soldered onto the Board. I need to not only not use HDMI but also I must change the muxing from this setting actively on my own.

4

SYSBOOT pins don’t affect the HDMI… The eeprom+device-tree does…

Regards,

5

SYSBOOT[5] is pulled up to VDD_3V3A which enables CLKOUT1.
CLKOUT1 is routed to JTAG footprint and SN74AUC1G74 which output is connected to HDMI framer TDA19988.

So even if HDMI is not used the MUXing of CLKOUT1 must be changed to disable it.

6

Finally I came up with this:

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 5b773d3e287e..aef75f0e7fde 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -120,7 +120,8 @@
 
 	clkout2_pin: pinmux_clkout2_pin {
 		pinctrl-single,pins = <
-			AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT_PULLDOWN, MUX_MODE3)	/* xdma_event_intr1.clkout2 */
+			AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR0, PIN_INPUT_PULLUP, MUX_MODE7)
+			AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_INPUT_PULLDOWN, MUX_MODE7)
 		>;
 	};
7

Nice @Konstantin i’ll roll that into an overlay!

ugh, forgot about the ‘jtag’ clock…

Regards,

8

I’m coming to this long after the fact, but I have a similar problem, and find that I am missing at least one critical bit of knowledge to put this into use, and hope that folks can help me.

I’m using the 4.19 kernel, which appears (from what i can tell) to already have the overlay changes described above. What’s not at all clear to me is how to make use of them to disable HDMI at boot!

What bit of magic am I missing?

9

For factory based images, you can use these options to disable built-in functionality…

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

disable_uboot_overlay_video=1

For other custom images, just force it to boot with the BeagleBone Green device tree (which is very similar to the Black, with no hdmi)…

Regards,

10

Thank you for the prompt answer!

We are actually already doing that, and still seeing EMI on harmonics that suggests that CLKOUT1 is still on.

I suppose it COULD be something else, but the harmonics are all multiples of 24MHz. The one I’m watching in particular as I try to hunt this down is 720MHz.

11

And now, i see something I should have seen earlier, which is that 720MHz is the CPU’s own speed!

12

So, it turns out the Black runs at 1GHz, not 720MHz, so that may still be a red herring.

We do see harmonics every 12MHz – it’s just that 720MHz is the spike that’s hurting us. It suggests CLKOUT1 is still ticking.

ETA: setting probes shows that CLKOUT1 is still ticking, for certain.

My effort to boot with the BBG device tree did not boot at all, and resulted in having to reimage the device!