What SBC/SoC users can achieve by adjusting clocks and pins?

What SBC/SoC users can achieve by adjusting clocks and pins (GPIO/pinctrl/pinmux) registered in kernel?

Is there any practical (or other) benefits available for users from adjusting clock frequencies and re-configuring pins either by modifying clock and pin driver codes or by using some commands which change pin states?

Yes, I know it's very easy to mess things up this way and bring the system to halt but I'm more interested in a potentially good (or at least interesting) outcomes.

CPU frequency rarely if ever left to pins but controlled internally. Different examples of the same chip will also achieve different speeds. The BCM2711 has been clocked as high as 2,800MHz successfully; The most common setting is 2147 MHz, but I could only get 2000Mhz, and after some years it slowed to 1800MHz.

Short answer: Suck it and see on a case by case basis.

I guess if the hardware is not suitable for a given task I will just look for another one. These are relatively cheap things. If I understand well.

The good/interesting outcome of overclocking is more performance. Think of the volume knobs on Amplifiers going up to 11 in "This is Spinal Tap." . The bad outcomes are more heat, loss of warranty, perhaps hardware damage, and finding all the faults that wouldn't be there if you behaved yourself.

Personally, I can understand overclocking a gaming rig. What's the point of overclocking a little sparrowfart cpu? +10% of nothing?

Originally Posted by sirabhorn What SBC/SoC users can achieve by adjusting ... pins (GPIO/pinctrl/pinmux) registered in kernel?

An SoC has to utilize pin multiplexing because the chip embeds (in its silicon) far more integrated peripherals than its packaging has pins or balls (i.e. the contacts for the necessary board connections). A pin could have a set of possible I/O functions for several peripherals, and the pin multiplexer is what assigns the specific function to such a pin. The board and/or system designer has to choose a subset of which peripherals of the SoC to utilize, and which pins those peripherals use to perform their I/O with the board and the external environment.

Pinctrl is simply the Linux kernel subsystem responsible for overall pin management and multiplexing.
The Device Tree is the typical method (e.g. for the ARM architecture) of presenting to the kernel these peripheral selections and pin multiplexing information for the board's configuration. The Device Tree provides the initial and presumably static pin multiplexing configuration.
However the Linux kernel does allow dynamic pin muxing, and the board would also need to cooperate. I have no idea how often dynamic pin muxing is employed, and am skeptical of its practicality.

On evaluation boards for an SoC, the pins that can be multiplexed could be (a) dedicated to a certain integrated peripheral (i.e. only connected to specialized circuitry on the board), or (b) exposed for almost any purpose as a header pin, or (c) wired to a dedicated-purpose (e.g. FPC) connector but still available for general use.

For instance the Ethernet MAC of the SoC would use a set of pins for an [R]MMI bus to connect to an external PHY chip on the board. Multiplexing those pins for some other purpose makes absolutely no sense because those pins on the board side lead only to an Ethernet PHY.

On most SoCs a pin that is not multiplexed/assigned to any peripheral can then be used as a GPIO (general purpose input/output) pin. Some SoCs also have (e.g. Broadcom?) a dedicated set of pins for GPIO. The Linux kernel has the gpio subsystem to manage such pins.


If your Linux kernel is configured for debugging, you can obtain several reports on pin muxing. One report is the state of each pin listed numerically. Another report lists the pins grouped by peripheral.
The pinctl driver can also be configured to output debugging messages, e.g. when a device driver requests pin muxing.