1) pin configuration ultimately boils down to two steps, for every pin (ball on
the SoC): what is it internally connected to (and operationally configured), and
separately, controlling that function once connected.
Yes. The physical pin is connected to a pin multiplexer, which is
generally completely separate from any logical device (gpio, uart,
timer, etc) that might use the pin.
2) specifying the function/connection and operation is what the "traditional"
pinmux ("pinctrl-single") entries do. It is accomplished by setting values in
GPIO control registers, which is just writing values to locations in the SoC
memory mapped space (with pinmux child nodes using "pinctrl-single,pins" driver
to specify offset from pinmux base address and mode selection, in 2-tuples for
each pin being configured). It is a bit tricky because this requires privilege
and thus a kernel driver (in kernel space/ring 0). The selection of
function/connection is done by the "mode" bits (2:0) in the control register,
and the operation by other bits (pullup/down, pull-enable, receiver enable, slew
rate).
Yes, with the caveat that different systems may have different ways of
specifying the pinmux control. The BBB uses two values, but there are
many different flavors of pinmux control across the various SoC's
available.
*I haven't tried it (don't want to damage hardware) but does this mean that
directly poking at the GPIO registers from userspace with /dev/mem & mmap()
won't work?
*if this is correct so far, what prevents loading a series of cape overlays that
change the configuration of a pin with this "old" style of pinmux control?
In the "old days", you could do this if you were root. Now I believe
the hardware configuration register space is setup with memory
protections so you have to access it from kernel space or you get an
exception. You can still work around this if you're root by playing
"tricks" (you can use something like the DMA engine or PRU to write
values to the pinmux registers, bypassing the MMU).
3) this is where things start being less clear to me: I think I was just
understanding pinmuxing; now I see devices with properties "pinctrl-0;" with no
value. Is that because the devices no longer "own" their pins, but the
config-pin driver does?
Not every device need to manage pins. Some devices don't have any
pins (a DMA controller, cryptographic acceleartor, etc) and sometime
the pins are already setup or are controlled by a different driver
(like the pinmux-helper driver).
4) the cape-universal node uses the "gpio-of-helper" driver, and apparently has
a node for each header pin, with a 3-tuple. It looks like {mode,?,0} but that's
a guess. I've searched, and found some examples from Pantelis Antoniou, but no
explanation.
The gpio-of-helper exports the GPIO pins so this doesn't have to be
done by the user. The three values you are referring to describe a
particular GPIO pin. The number of values needed, and their meaning
is device specific:
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
Ultimately, I'd like to understand this so that I can create mappings/dts on my
own, rather than just relying on finding something that works offered by someone
else.
Read through the device tree binding documentation in the kernel
source. It is also helpful to view the full working device tree from
your system. You can take the binary device tree from /boot and
convert it into source with dtc. Then instead of a bunch of dangling
references like &gpio3, you can go to gpio3 and see what it is, which
will help you find it's documentation in the kernel's Documentation
directory.