linux-stable.git/Documentation/devicetree/bindings/memory-controllers, branch v6.2

dt-bindings: drop redundant part of title (end, part three)

2022-12-16T17:41:49+00:00

The Devicetree bindings document does not have to say in the title that
it is a "binding", but instead just describe the hardware.

Drop trailing "bindings" in various forms (also with trailing full
stop):

  find Documentation/devicetree/bindings/ -type f -name '*.yaml' \
    -not -name 'trivial-devices.yaml' \
    -exec sed -i -e 's/^title: \(.*\) [bB]indings\?\.\?$/title: \1/' {} \;

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alexandre Belloni 
Acked-by: Matti Vaittinen  # ROHM
Acked-by: Ulf Hansson  # MMC
Acked-by: Stephen Boyd  # clk
Acked-by: Dmitry Torokhov  # input
Acked-by: Mark Brown 
Acked-by: Hans Verkuil  # media
Acked-by: Sebastian Reichel  # power
Acked-by: Viresh Kumar  # cpufreq
Link: https://lore.kernel.org/r/20221216163815.522628-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Rob Herring

dt-bindings: drop redundant part of title (end)

2022-12-16T17:41:49+00:00

The Devicetree bindings document does not have to say in the title that
it is a "Devicetree binding", but instead just describe the hardware.

Drop trailing "Devicetree bindings" in various forms (also with
trailing full stop):

  find Documentation/devicetree/bindings/ -type f -name '*.yaml' \
    -not -name 'trivial-devices.yaml' \
    -exec sed -i -e 's/^title: \(.*\) [dD]evice[ -]\?[tT]ree [bB]indings\?\.\?$/title: \1/' {} \;

  find Documentation/devicetree/bindings/ -type f -name '*.yaml' \
    -not -name 'trivial-devices.yaml' \
    -exec sed -i -e 's/^title: \(.*\) [dD]evice[ -]\?[nN]ode [bB]indings\?\.\?$/title: \1/' {} \;

  find Documentation/devicetree/bindings/ -type f -name '*.yaml' \
    -not -name 'trivial-devices.yaml' \
    -exec sed -i -e 's/^title: \(.*\) [dD][tT] [bB]indings\?\.\?$/title: \1/' {} \;

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alexandre Belloni 
Acked-by: Jonathan Cameron  # IIO
Reviewed-by: Jonathan Cameron 
Acked-by: Ulf Hansson  # MMC
Acked-by: Stephen Boyd  # clk
Acked-by: Dmitry Torokhov  # input
Acked-by: Mark Brown 
Acked-by: Hans Verkuil  # media
Acked-by: Sebastian Reichel  # power
Link: https://lore.kernel.org/r/20221216163815.522628-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Rob Herring

dt-bindings: memory-controllers: ti,gpmc-child: drop redundant part of title

2022-12-16T17:41:49+00:00

The Devicetree bindings document does not have to say in the title that
it is a "Devicetree binding", but instead just describe the hardware.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alexandre Belloni 
Acked-by: Ulf Hansson  # MMC
Link: https://lore.kernel.org/r/20221216163815.522628-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Rob Herring

dt-bindings: memory-controllers: ti,gpmc: add wait-pin polarity

2022-11-02T14:03:12+00:00

The GPMC controller has the ability to configure the polarity for the
wait pin. The current properties do not allow this configuration.
This binding directly configures the WAITPINPOLARITY bit
in the GPMC_CONFIG register by setting the "ti,wait-pin-polarity"
dt-property.

Signed-off-by: Benedikt Niedermayr 
Reviewed-by: Rob Herring 
Reviewed-by: Roger Quadros 
Link: https://lore.kernel.org/r/20221102133047.1654449-3-benedikt.niedermayr@siemens.com
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory-controllers: arm,pl353-smc: Extend to support 'arm,pl354' SMC

2022-10-28T12:55:29+00:00

Add support for the Arm PL354 static memory controller to the existing
Arm PL353 binding. Both are different configurations of the same IP with
support for different types of memory interfaces.

The 'arm,pl354' binding has already been in use upstream for a long time
in Arm development boards. The existing users have only the controller
without any child devices, so drop the required address properties
(ranges, #address-cells, #size-cells). The schema for 'ranges' is too
constrained as the order is not important and the PL354 has 8
chipselects (And the PL353 actually has up to 8 too).

The clocks aren't really correct in either case. There's 1 bus clock and
then a clock for each of the 2 memory interfaces.

Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20221021203928.286169-1-robh@kernel.org
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory-controller: st,stm32: Split off MC properties

2022-10-18T17:05:18+00:00

Split st,stm32-fmc2-ebi.yaml specific properties into
st,stm32-fmc2-ebi-props.yaml, split memory-controller bus peripheral
properties into mc-peripheral-props.yaml, reference the
st,stm32-fmc2-ebi-props.yaml in mc-peripheral-props.yaml and reference
the mc-peripheral-props.yaml in micrel,ks8851.yaml.

This way, the FMC2 controller properties in Micrel KSZ8851MLL ethernet
controller node can be properly validated.

Fixes the following warning:
  arch/arm/boot/dts/stm32mp153c-dhcor-drc-compact.dtb: ethernet@1,0:
    Unevaluated properties are not allowed ('bank-width', 'st,fmc2-ebi-cs-mux-enable', ... 'st,fmc2-ebi-cs-write-data-hold-ns' were unexpected)

Reviewed-by: Rob Herring 
Signed-off-by: Marek Vasut 
Link: https://lore.kernel.org/r/20220928181944.194808-1-marex@denx.de
[krzk: trim warning message]
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: Add jedec,lpddrX-channel binding

2022-10-18T17:05:18+00:00

This patch adds a new device tree binding for an LPDDR channel to serve
as a top-level organizing node for LPDDR part nodes nested below it. An
LPDDR channel needs to have an "io-width" property to describe its width
(this is important because this width does not always match the io-width
of the part number, indicating that multiple parts are wired in parallel
on the same channel), as well as one or more nested "rank@X" nodes.
Those represent information about the individual ranks of each LPDDR
part connected on that channel and should match the existing
"jedec,lpddrX" bindings for individual LPDDR parts.

New platforms should be using this node -- the existing practice of
providing a raw, toplevel "jedec,lpddrX" node without indication of how
many identical parts are in the system should be considered deprecated.

Signed-off-by: Julius Werner 
Reviewed-by: Rob Herring 
Link: https://lore.kernel.org/r/20220930220606.303395-4-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings

2022-10-18T17:05:15+00:00

This patch adds bindings for LPDDR4 and LPDDR5 memory analogous to the
existing bindings for LPDDR2 and LPDDR3. For now, the new types are only
needed for topology description, so other properties like timing
parameters are omitted. They can be added later if needed.

Signed-off-by: Julius Werner 
Reviewed-by: Rob Herring 
Link: https://lore.kernel.org/r/20220930220606.303395-3-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: Add numeric LPDDR compatible string variant

2022-10-18T17:05:06+00:00

This patch allows a new kind of compatible string for LPDDR parts in the
device tree bindings, in addition to the existing hardcoded
, strings. The new format contains manufacturer and
part (revision) information in numerical form, such as lpddr3-ff,0201
for an LPDDR3 part with manufacturer ID ff and revision ID 0201. This
helps cases where LPDDR parts are probed at runtime by boot firmware and
cannot be matched to hardcoded part numbers, such as the firmware on the
qcom/sc7280-herobrine boards does (which supports 4 different memory
configurations at the moment, and more are expected to be added later at
a point where the boot firmware can no longer be updated to specifically
accommodate them).

Signed-off-by: Julius Werner 
Acked-by: Rob Herring 
Link: https://lore.kernel.org/r/20220930220606.303395-2-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski

dt-bindings: memory: Factor out common properties of LPDDR bindings

2022-10-18T17:02:58+00:00

The bindings for different LPDDR versions mostly use the same kinds of
properties, so in order to reduce duplication when we're adding support
for more versions, this patch creates a new lpddr-props subschema that
can be referenced by the others to define these common parts. (This will
consider a few smaller I/O width and density numbers "legal" for LPDDR3
that are usually not used there, but this should be harmless.)

Signed-off-by: Julius Werner 
Acked-by: Rob Herring 
Link: https://lore.kernel.org/r/20220930220606.303395-1-jwerner@chromium.org
Signed-off-by: Krzysztof Kozlowski