69386aa6c0
Some checks are pending
Build Documentation / build-html (push) Waiting to run
MemBrowse Memory Report / changes-filter (push) Waiting to run
MemBrowse Memory Report / load-targets (push) Waiting to run
MemBrowse Memory Report / identical (push) Blocked by required conditions
MemBrowse Memory Report / analyze (push) Blocked by required conditions
The regulator framework has no way out to userspace: consumers reach a rail by name from inside the kernel, which is the right interface for controlling one, but it leaves a board with regulators offering no way to see what they are doing, and a newly written regulator driver cannot be looked at without writing a consumer for it first. Adds /proc/regulator, behind REGULATOR_PROCFS, listing every registered regulator: its present voltage, the range it will accept, whether it is enabled, how many consumers hold and enable it, its supply, and whether it is always on or expected on at boot. Lines carry the same key:value tokens in the same order, so the file is machine parseable. The last two are worth reading beside the consumer count, since a rail enabled with no consumers is expected rather than suspect when either is set. A part usually measures more than the framework has fields for, so struct regulator_ops_s gains an optional describe method: it writes key:value text and the renderer appends it to that rail's line. This is how a driver reports what only it knows, an input voltage, an output current, a temperature or a fault word, without the framework growing a field per part or the driver growing procfs code of its own. It is called with the list mutex held and never from interrupt context, so reading the part over a bus is allowed. The voltage and the enabled state are read back from the hardware rather than recalled, so a rail the boot loader set and nothing has touched since reads as it actually is. Both calls can fail, and a failure reports - rather than an errno formatted as a voltage or a rail that looks switched on. Reading the hardware is also why this takes the list mutex directly rather than calling regulator_list_lock(), which additionally disables interrupts so that callers in interrupt or idle context are safe. Asking a regulator on a bus what it is doing means a transfer, and a transfer waits; a task reading a file can afford to wait and an interrupt handler cannot. procfs_register() appends without checking for duplicates, so the entry is claimed once for the lifetime of the system rather than whenever the list is empty. It also needs FS_PROCFS_REGISTER, which the option now depends on rather than only FS_PROCFS. Documents the framework, which had no page at all: the consumer interface and what counted enables mean, what a driver supplies, and the new entry. The entry is read only. What voltage a rail may be is knowledge its consumers hold, and arranging the order between them is what the framework is for, so moving one from a shell would step around the part that matters. Assisted-by: Claude:claude-opus-5 Signed-off-by: Justin Hammond <justin@dynam.ac> |
||
|---|---|---|
| .github | ||
| arch | ||
| audio | ||
| binfmt | ||
| boards | ||
| cmake | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| dummy | ||
| fs | ||
| graphics | ||
| include | ||
| libs | ||
| mm | ||
| net | ||
| openamp | ||
| pass1 | ||
| sched | ||
| syscall | ||
| tools | ||
| video | ||
| wireless | ||
| .asf.yaml | ||
| .codespell-ignore-lines | ||
| .codespellrc | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmessage | ||
| .pre-commit-config.yaml | ||
| .yamllint | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| INVIOLABLES.md | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| ReleaseNotes | ||
Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).
For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.
Getting Started
First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.
Documentation
You can find the current NuttX documentation on the Documentation Page.
Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.
The old NuttX documentation is still available in the Apache wiki.
Supported Boards
NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.
Contributing
If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.
License
The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.