The Design and Implementation of the FreeBSD Operating System, Second Edition
Now available: The Design and Implementation of the FreeBSD Operating System (Second Edition)


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]

FreeBSD/Linux Kernel Cross Reference
sys/contrib/device-tree/Bindings/spi/spi-peripheral-props.yaml

Version: -  FREEBSD  -  FREEBSD-13-STABLE  -  FREEBSD-13-0  -  FREEBSD-12-STABLE  -  FREEBSD-12-0  -  FREEBSD-11-STABLE  -  FREEBSD-11-0  -  FREEBSD-10-STABLE  -  FREEBSD-10-0  -  FREEBSD-9-STABLE  -  FREEBSD-9-0  -  FREEBSD-8-STABLE  -  FREEBSD-8-0  -  FREEBSD-7-STABLE  -  FREEBSD-7-0  -  FREEBSD-6-STABLE  -  FREEBSD-6-0  -  FREEBSD-5-STABLE  -  FREEBSD-5-0  -  FREEBSD-4-STABLE  -  FREEBSD-3-STABLE  -  FREEBSD22  -  l41  -  OPENBSD  -  linux-2.6  -  MK84  -  PLAN9  -  xnu-8792 
SearchContext: -  none  -  3  -  10 

    1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
    2 %YAML 1.2
    3 ---
    4 $id: http://devicetree.org/schemas/spi/spi-peripheral-props.yaml#
    5 $schema: http://devicetree.org/meta-schemas/core.yaml#
    6 
    7 title: Peripheral-specific properties for a SPI bus.
    8 
    9 description:
   10   Many SPI controllers need to add properties to peripheral devices. They could
   11   be common properties like spi-max-frequency, spi-cpha, etc. or they could be
   12   controller specific like delay in clock or data lines, etc. These properties
   13   need to be defined in the peripheral node because they are per-peripheral and
   14   there can be multiple peripherals attached to a controller. All those
   15   properties are listed here. The controller specific properties should go in
   16   their own separate schema that should be referenced from here.
   17 
   18 maintainers:
   19   - Mark Brown <broonie@kernel.org>
   20 
   21 properties:
   22   reg:
   23     minItems: 1
   24     maxItems: 256
   25     items:
   26       items:
   27         - minimum: 0
   28           maximum: 256
   29     description:
   30       Chip select used by the device.
   31 
   32   spi-3wire:
   33     $ref: /schemas/types.yaml#/definitions/flag
   34     description:
   35       The device requires 3-wire mode.
   36 
   37   spi-cs-high:
   38     $ref: /schemas/types.yaml#/definitions/flag
   39     description:
   40       The device requires the chip select active high.
   41 
   42   spi-lsb-first:
   43     $ref: /schemas/types.yaml#/definitions/flag
   44     description:
   45       The device requires the LSB first mode.
   46 
   47   spi-max-frequency:
   48     $ref: /schemas/types.yaml#/definitions/uint32
   49     description:
   50       Maximum SPI clocking speed of the device in Hz.
   51 
   52   spi-rx-bus-width:
   53     description:
   54       Bus width to the SPI bus used for read transfers.
   55       If 0 is provided, then no RX will be possible on this device.
   56     $ref: /schemas/types.yaml#/definitions/uint32
   57     enum: [0, 1, 2, 4, 8]
   58     default: 1
   59 
   60   spi-rx-delay-us:
   61     description:
   62       Delay, in microseconds, after a read transfer.
   63 
   64   rx-sample-delay-ns:
   65     description: SPI Rx sample delay offset, unit is nanoseconds.
   66       The delay from the default sample time before the actual
   67       sample of the rxd input signal occurs.
   68 
   69   spi-tx-bus-width:
   70     description:
   71       Bus width to the SPI bus used for write transfers.
   72       If 0 is provided, then no TX will be possible on this device.
   73     $ref: /schemas/types.yaml#/definitions/uint32
   74     enum: [0, 1, 2, 4, 8]
   75     default: 1
   76 
   77   spi-tx-delay-us:
   78     description:
   79       Delay, in microseconds, after a write transfer.
   80 
   81   stacked-memories:
   82     description: Several SPI memories can be wired in stacked mode.
   83       This basically means that either a device features several chip
   84       selects, or that different devices must be seen as a single
   85       bigger chip. This basically doubles (or more) the total address
   86       space with only a single additional wire, while still needing
   87       to repeat the commands when crossing a chip boundary. The size of
   88       each chip should be provided as members of the array.
   89     $ref: /schemas/types.yaml#/definitions/uint64-array
   90     minItems: 2
   91     maxItems: 4
   92 
   93   parallel-memories:
   94     description: Several SPI memories can be wired in parallel mode.
   95       The devices are physically on a different buses but will always
   96       act synchronously as each data word is spread across the
   97       different memories (eg. even bits are stored in one memory, odd
   98       bits in the other). This basically doubles the address space and
   99       the throughput while greatly complexifying the wiring because as
  100       many busses as devices must be wired. The size of each chip should
  101       be provided as members of the array.
  102     $ref: /schemas/types.yaml#/definitions/uint64-array
  103     minItems: 2
  104     maxItems: 4
  105 
  106 # The controller specific properties go here.
  107 allOf:
  108   - $ref: cdns,qspi-nor-peripheral-props.yaml#
  109   - $ref: samsung,spi-peripheral-props.yaml#
  110   - $ref: nvidia,tegra210-quad-peripheral-props.yaml#
  111 
  112 additionalProperties: true

Cache object: 035bd7fd32222c37bbd3064a1870ed5f


[ source navigation ] [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] [ list types ] [ track identifier ]


This page is part of the FreeBSD/Linux Linux Kernel Cross-Reference, and was automatically generated using a modified version of the LXR engine.