mirror of
https://github.com/Qortal/Brooklyn.git
synced 2025-02-12 18:25:53 +00:00
a94b3d14aa
Changes included (and more): 1. Dynamic RAM merge 2. Real-time page scan and allocation 3. Cache compression 4. Real-time IRQ checks 5. Dynamic I/O allocation for Java heap 6. Java page migration 7. Contiguous memory allocation 8. Idle pages tracking 9. Per CPU RAM usage tracking 10. ARM NEON scalar multiplication library 11. NEON/ARMv8 crypto extensions 12. NEON SHA, Blake, RIPEMD crypto extensions 13. Parallel NEON crypto engine for multi-algo based CPU stress reduction
68 lines
2.6 KiB
YAML
68 lines
2.6 KiB
YAML
# SPDX-License-Identifier: GPL-2.0
|
|
%YAML 1.2
|
|
---
|
|
$id: http://devicetree.org/schemas/mux/mux-consumer.yaml#
|
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
|
|
|
title: Common multiplexer controller consumer bindings
|
|
|
|
maintainers:
|
|
- Peter Rosin <peda@axentia.se>
|
|
|
|
description: |
|
|
Mux controller consumers should specify a list of mux controllers that they
|
|
want to use with a property containing a 'mux-ctrl-list':
|
|
|
|
mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
|
|
single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
|
|
mux-ctrl-phandle : phandle to mux controller node
|
|
mux-ctrl-specifier : array of #mux-control-cells specifying the
|
|
given mux controller (controller specific)
|
|
|
|
Mux controller properties should be named "mux-controls". The exact meaning of
|
|
each mux controller property must be documented in the device tree binding for
|
|
each consumer. An optional property "mux-control-names" may contain a list of
|
|
strings to label each of the mux controllers listed in the "mux-controls"
|
|
property.
|
|
|
|
If it is required to provide the state that the mux controller needs to
|
|
be set to, the property "mux-states" must be used. An optional property
|
|
"mux-state-names" can be used to provide a list of strings, to label
|
|
each of the multiplixer states listed in the "mux-states" property.
|
|
|
|
Properties "mux-controls" and "mux-states" can be used depending on how
|
|
the consumers want to control the mux controller. If the consumer needs
|
|
needs to set multiple states in a mux controller, then property
|
|
"mux-controls" can be used. If the consumer needs to set the mux
|
|
controller to a given state then property "mux-states" can be used.
|
|
|
|
mux-ctrl-specifier typically encodes the chip-relative mux controller number.
|
|
If the mux controller chip only provides a single mux controller, the
|
|
mux-ctrl-specifier can typically be left out.
|
|
|
|
select: true
|
|
|
|
properties:
|
|
mux-controls:
|
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
|
|
|
mux-states:
|
|
$ref: /schemas/types.yaml#/definitions/phandle-array
|
|
|
|
mux-control-names:
|
|
description:
|
|
Devices that use more than a single mux controller can use the
|
|
"mux-control-names" property to map the name of the requested mux
|
|
controller to an index into the list given by the "mux-controls" property.
|
|
|
|
mux-state-names:
|
|
description:
|
|
Devices that use more than a single multiplexer state can use the
|
|
"mux-state-names" property to map the name of the requested mux
|
|
controller to an index into the list given by the "mux-states"
|
|
property.
|
|
|
|
additionalProperties: true
|
|
|
|
...
|