GPIO/docs: clarify PRU direct GPIO (R30/R31) vs SysConfig pinmux and runtime direction on AM26x PRU-ICSSM

[pratheesh]

Summary

Developers on the AM26x PRU-ICSSM parts (e.g. AM263Px) are unclear how PRU GPIO direction works and whether it can be changed at runtime — see E2E thread 1666087 ("AM263P4 PRU GPIO direction switching during runtime"). The confusion is between:

• PRU direct GPIO — output via R30, input via R31 (the fast, deterministic path used by most open-pru examples), and
• SysConfig / pinmux pad direction — which fixes the pad's input/output role at configuration time.

There is currently no open-pru example or doc note that clarifies what "changing GPIO direction at runtime" does and does not mean on PRU-ICSSM: which register actually drives a pin, how a pin is switched between drive and sample use, and the interaction with the pad configuration set in SysConfig.

Proposal

Add either (a) a short academy note / FAQ, or (b) a small example, that:

1. Explains R30 (output) vs R31 (input) direct-GPIO usage on PRU-ICSSM.
2. Clarifies the relationship to SysConfig pad direction/pinmux, and what is fixed at config time vs controllable from firmware.
3. Shows the recommended pattern for a pin that must alternate between driving and sampling (open-drain / bidirectional-style use), if applicable on this silicon.

This directly answers a recurring E2E question and complements the existing GPIO material.

Scope

Documentation, optionally with a minimal example. Device focus: AM26x (AM263Px / AM261x) PRU-ICSSM.