Commit 9e549c76 authored by Arnd Bergmann's avatar Arnd Bergmann

Merge tag 'memory-controller-drv-6.2' of...

Merge tag 'memory-controller-drv-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

Memory controller drivers for v6.2

1. STM32 FMC2:
   a. Correct in bindings the name of property for address
      setup duration. The DTS and driver were already using proper name,
      so it is only alignment of bindings with real usage.
   b. Split off STM32 memory controller bus peripheral properties into
      generic ones (re-usable by multiple memory controllers) and STM32 bus
      peripheral.  This way, the FMC2 controller properties in Micrel
      KSZ8851MLL ethernet controller node can be properly validated.

2. Tegra MC: simplify with DEFINE_SHOW_ATTRIBUTE.

3. Renesas RPC IF: add suppor tfor R-Car Gen4.

4. LPDDR bindings: refactor and extend with description of DDR channels.
   Add also bindings for LPDDR4 and LPDDR5.

The rationale for (4) above - LPDDR bindings changes, wrote by Julius Werner:

"We (Chromium OS) have been trying to find a way to pass LPDDR memory
chip information that is available to the firmware through the FDT
(mostly for userspace informational purposes, for now). We have been
using and expanding the existing "jedec,lpddr2" and "jedec,lpddr3"
bindings for this (e.g. [1]). The goal is to be able to identify the
memory layout of the system (how the parts look like, how they're tied
together, how much capacity there is in total) as accurately as
possible from software-probed values.

...

The problem with this is that each individual LPDDR chip has its own
set of mode registers (per rank) that only describe the density of
that particular chip (rank). The host memory controller may have
multiple channels (each of which is basically an entirely separate set
of physical LPDDR pins on the board), a single channel may be
connected to multiple LPDDR chips (e.g. if the memory controller has
an outgoing 32-bit channel, that channel could be tied to two 16-bit
LPDDR chips by tying the low 16 bits to one and the high 16 bits to
the other), and then each of those chips may offer multiple
independent ranks (which rank is being accessed at a given time is
controlled by a separate chip select pin).

So if we just have one "io-width" and one "density" field in the FDT,
there's no way to figure out how much memory there's actually
connected in total, because that only describes a single LPDDR chip.
Worse, there may be chips where different ranks have different
densities (e.g. a 6GB dual-rank chip with one 4GB and one 2GB rank),
and different channels could theoretically be connected to chips of
completely different manufacturers."

Link: https://lore.kernel.org/r/CAODwPW9E8wWwxbYKyf4_-JFb4F-JSmLR3qOF_iudjX0f9ndF0A@mail.gmail.com

* tag 'memory-controller-drv-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
  dt-bindings: memory-controller: st,stm32: Split off MC properties
  dt-bindings: memory: Add jedec,lpddrX-channel binding
  dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings
  dt-bindings: memory: Add numeric LPDDR compatible string variant
  dt-bindings: memory: Factor out common properties of LPDDR bindings
  memory: renesas-rpc-if: Add support for R-Car Gen4
  memory: renesas-rpc-if: Clear HS bit during hardware initialization
  dt-bindings: memory: renesas,rpc-if: Document R-Car V4H support
  memory: tegra186-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
  memory: tegra210-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
  memory: tegra30-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
  memory: tegra20-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
  dt-bindings: memory-controller: st,stm32: Fix st,fmc2_ebi-cs-write-address-setup-ns

Link: https://lore.kernel.org/r/20221026171354.51877-1-krzysztof.kozlowski@linaro.orgSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
parents 84582f9e a11a5deb
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-channel.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LPDDR channel with chip/rank topology description
description:
An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS,
CK, etc.) that connect one or more LPDDR chips to a host system. The main
purpose of this node is to overall LPDDR topology of the system, including the
amount of individual LPDDR chips and the ranks per chip.
maintainers:
- Julius Werner <jwerner@chromium.org>
properties:
compatible:
enum:
- jedec,lpddr2-channel
- jedec,lpddr3-channel
- jedec,lpddr4-channel
- jedec,lpddr5-channel
io-width:
description:
The number of DQ pins in the channel. If this number is different
from (a multiple of) the io-width of the LPDDR chip, that means that
multiple instances of that type of chip are wired in parallel on this
channel (with the channel's DQ pins split up between the different
chips, and the CA, CS, etc. pins of the different chips all shorted
together). This means that the total physical memory controlled by a
channel is equal to the sum of the densities of each rank on the
connected LPDDR chip, times the io-width of the channel divided by
the io-width of the LPDDR chip.
enum:
- 8
- 16
- 32
- 64
- 128
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^rank@[0-9]+$":
type: object
description:
Each physical LPDDR chip may have one or more ranks. Ranks are
internal but fully independent sub-units of the chip. Each LPDDR bus
transaction on the channel targets exactly one rank, based on the
state of the CS pins. Different ranks may have different densities and
timing requirements.
required:
- reg
allOf:
- if:
properties:
compatible:
contains:
const: jedec,lpddr2-channel
then:
patternProperties:
"^rank@[0-9]+$":
$ref: /schemas/memory-controllers/ddr/jedec,lpddr2.yaml#
- if:
properties:
compatible:
contains:
const: jedec,lpddr3-channel
then:
patternProperties:
"^rank@[0-9]+$":
$ref: /schemas/memory-controllers/ddr/jedec,lpddr3.yaml#
- if:
properties:
compatible:
contains:
const: jedec,lpddr4-channel
then:
patternProperties:
"^rank@[0-9]+$":
$ref: /schemas/memory-controllers/ddr/jedec,lpddr4.yaml#
- if:
properties:
compatible:
contains:
const: jedec,lpddr5-channel
then:
patternProperties:
"^rank@[0-9]+$":
$ref: /schemas/memory-controllers/ddr/jedec,lpddr5.yaml#
required:
- compatible
- io-width
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
lpddr-channel0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "jedec,lpddr3-channel";
io-width = <32>;
rank@0 {
compatible = "lpddr3-ff,0100", "jedec,lpddr3";
reg = <0>;
density = <8192>;
io-width = <16>;
revision-id = <1 0>;
};
};
lpddr-channel1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "jedec,lpddr4-channel";
io-width = <32>;
rank@0 {
compatible = "lpddr4-05,0301", "jedec,lpddr4";
reg = <0>;
density = <4096>;
io-width = <32>;
revision-id = <3 1>;
};
rank@1 {
compatible = "lpddr4-05,0301", "jedec,lpddr4";
reg = <1>;
density = <2048>;
io-width = <32>;
revision-id = <3 1>;
};
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-props.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common properties for LPDDR types
description:
Different LPDDR types generally use the same properties and only differ in the
range of legal values for each. This file defines the common parts that can be
reused for each type. Nodes using this schema should generally be nested under
an LPDDR channel node.
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
properties:
compatible:
description:
Compatible strings can be either explicit vendor names and part numbers
(e.g. elpida,ECB240ABACN), or generated strings of the form
lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID
(from MR5) and ZZZZ is the revision ID (from MR6 and MR7). Both IDs are
formatted in lower case hexadecimal representation with leading zeroes.
The latter form can be useful when LPDDR nodes are created at runtime by
boot firmware that doesn't have access to static part number information.
reg:
description:
The rank number of this LPDDR rank when used as a subnode to an LPDDR
channel.
minimum: 0
maximum: 3
revision-id:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
maxItems: 2
items:
minimum: 0
maximum: 255
density:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Density in megabits of SDRAM chip. Decoded from Mode Register 8.
enum:
- 64
- 128
- 256
- 512
- 1024
- 2048
- 3072
- 4096
- 6144
- 8192
- 12288
- 16384
- 24576
- 32768
io-width:
$ref: /schemas/types.yaml#/definitions/uint32
description:
IO bus width in bits of SDRAM chip. Decoded from Mode Register 8.
enum:
- 8
- 16
- 32
additionalProperties: true
......@@ -9,6 +9,9 @@ title: LPDDR2 SDRAM compliant to JEDEC JESD209-2
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: jedec,lpddr-props.yaml#
properties:
compatible:
oneOf:
......@@ -17,13 +20,15 @@ properties:
- elpida,ECB240ABACN
- elpida,B8132B2PB-6D-F
- enum:
- jedec,lpddr2-s4
- items:
- enum:
- jedec,lpddr2-nvm
- jedec,lpddr2-s2
- jedec,lpddr2-s4
- items:
- pattern: "^lpddr2-[0-9a-f]{2},[0-9a-f]{4}$"
- enum:
- jedec,lpddr2-nvm
- jedec,lpddr2-s2
- jedec,lpddr2-s4
revision-id1:
$ref: /schemas/types.yaml#/definitions/uint32
......@@ -41,41 +46,6 @@ properties:
Property is deprecated, use revision-id instead.
deprecated: true
revision-id:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: |
Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
minItems: 2
maxItems: 2
items:
minimum: 0
maximum: 255
density:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Density in megabits of SDRAM chip. Obtained from device datasheet.
enum:
- 64
- 128
- 256
- 512
- 1024
- 2048
- 4096
- 8192
- 16384
- 32768
io-width:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
IO bus width in bits of SDRAM chip. Obtained from device datasheet.
enum:
- 32
- 16
- 8
tRRD-min-tck:
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 16
......@@ -168,7 +138,7 @@ required:
- density
- io-width
additionalProperties: false
unevaluatedProperties: false
examples:
- |
......
......@@ -9,35 +9,24 @@ title: LPDDR3 SDRAM compliant to JEDEC JESD209-3
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: jedec,lpddr-props.yaml#
properties:
compatible:
items:
- enum:
- samsung,K3QF2F20DB
- const: jedec,lpddr3
oneOf:
- items:
- enum:
- samsung,K3QF2F20DB
- const: jedec,lpddr3
- items:
- pattern: "^lpddr3-[0-9a-f]{2},[0-9a-f]{4}$"
- const: jedec,lpddr3
'#address-cells':
const: 1
deprecated: true
density:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Density in megabits of SDRAM chip.
enum:
- 4096
- 8192
- 16384
- 32768
io-width:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
IO bus width in bits of SDRAM chip.
enum:
- 32
- 16
manufacturer-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
......@@ -45,15 +34,6 @@ properties:
deprecated, manufacturer should be derived from the compatible.
deprecated: true
revision-id:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
items:
maximum: 255
description: |
Revision value of SDRAM chip read from Mode Registers 6 and 7.
'#size-cells':
const: 0
deprecated: true
......@@ -206,7 +186,7 @@ required:
- density
- io-width
additionalProperties: false
unevaluatedProperties: false
examples:
- |
......
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr4.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LPDDR4 SDRAM compliant to JEDEC JESD209-4
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: jedec,lpddr-props.yaml#
properties:
compatible:
items:
- pattern: "^lpddr4-[0-9a-f]{2},[0-9a-f]{4}$"
- const: jedec,lpddr4
required:
- compatible
- density
- io-width
unevaluatedProperties: false
examples:
- |
lpddr {
compatible = "lpddr4-ff,0100", "jedec,lpddr4";
density = <8192>;
io-width = <16>;
revision-id = <1 0>;
};
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LPDDR5 SDRAM compliant to JEDEC JESD209-5
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
allOf:
- $ref: jedec,lpddr-props.yaml#
properties:
compatible:
items:
- pattern: "^lpddr5-[0-9a-f]{2},[0-9a-f]{4}$"
- const: jedec,lpddr5
serial-id:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
Serial IDs read from Mode Registers 47 through 54. One byte per uint32
cell (i.e. <MR47 MR48 MR49 MR50 MR51 MR52 MR53 MR54>).
maxItems: 8
items:
minimum: 0
maximum: 255
required:
- compatible
- density
- io-width
unevaluatedProperties: false
examples:
- |
lpddr {
compatible = "lpddr5-01,0200", "jedec,lpddr5";
density = <8192>;
io-width = <8>;
revision-id = <2 0>;
serial-id = <3 1 0 0 0 0 0 0>;
};
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/mc-peripheral-props.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Peripheral-specific properties for a Memory Controller bus.
description:
Many Memory Controllers need to add properties to peripheral devices.
They could be common properties like reg or they could be controller
specific like delay in clock or data lines, etc. These properties need
to be defined in the peripheral node because they are per-peripheral
and there can be multiple peripherals attached to a controller. All
those properties are listed here. The controller specific properties
should go in their own separate schema that should be referenced
from here.
maintainers:
- Marek Vasut <marex@denx.de>
properties:
reg:
description: Bank number, base address and size of the device.
bank-width:
$ref: /schemas/types.yaml#/definitions/uint32
description: Bank width of the device, in bytes.
enum: [1, 2, 4]
required:
- reg
# The controller specific properties go here.
allOf:
- $ref: st,stm32-fmc2-ebi-props.yaml#
additionalProperties: true
......@@ -42,6 +42,11 @@ properties:
- renesas,r8a779a0-rpc-if # R-Car V3U
- const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2{E,H,M,N} device
- items:
- enum:
- renesas,r8a779g0-rpc-if # R-Car V4H
- const: renesas,rcar-gen4-rpc-if # a generic R-Car gen4 device
- items:
- enum:
- renesas,r9a07g043-rpc-if # RZ/G2UL
......
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi-props.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Peripheral properties for ST FMC2 Controller
maintainers:
- Christophe Kerello <christophe.kerello@foss.st.com>
- Marek Vasut <marex@denx.de>
properties:
st,fmc2-ebi-cs-transaction-type:
description: |
Select one of the transactions type supported
0: Asynchronous mode 1 SRAM/FRAM.
1: Asynchronous mode 1 PSRAM.
2: Asynchronous mode A SRAM/FRAM.
3: Asynchronous mode A PSRAM.
4: Asynchronous mode 2 NOR.
5: Asynchronous mode B NOR.
6: Asynchronous mode C NOR.
7: Asynchronous mode D NOR.
8: Synchronous read synchronous write PSRAM.
9: Synchronous read asynchronous write PSRAM.
10: Synchronous read synchronous write NOR.
11: Synchronous read asynchronous write NOR.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 11
st,fmc2-ebi-cs-cclk-enable:
description: Continuous clock enable (first bank must be configured
in synchronous mode). The FMC_CLK is generated continuously
during asynchronous and synchronous access. By default, the
FMC_CLK is only generated during synchronous access.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-mux-enable:
description: Address/Data multiplexed on databus (valid only with
NOR and PSRAM transactions type). By default, Address/Data
are not multiplexed.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-buswidth:
description: Data bus width
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 8, 16 ]
default: 16
st,fmc2-ebi-cs-waitpol-high:
description: Wait signal polarity (NWAIT signal active high).
By default, NWAIT is active low.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-waitcfg-enable:
description: The NWAIT signal indicates wheither the data from the
device are valid or if a wait state must be inserted when accessing
the device in synchronous mode. By default, the NWAIT signal is
active one data cycle before wait state.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-wait-enable:
description: The NWAIT signal is enabled (its level is taken into
account after the programmed latency period to insert wait states
if asserted). By default, the NWAIT signal is disabled.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-asyncwait-enable:
description: The NWAIT signal is taken into account during asynchronous
transactions. By default, the NWAIT signal is not taken into account
during asynchronous transactions.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-cpsize:
description: CRAM page size. The controller splits the burst access
when the memory page is reached. By default, no burst split when
crossing page boundary.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 128, 256, 512, 1024 ]
default: 0
st,fmc2-ebi-cs-byte-lane-setup-ns:
description: This property configures the byte lane setup timing
defined in nanoseconds from NBLx low to Chip Select NEx low.
st,fmc2-ebi-cs-address-setup-ns:
description: This property defines the duration of the address setup
phase in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-address-hold-ns:
description: This property defines the duration of the address hold
phase in nanoseconds used for asynchronous multiplexed read/write
transactions.
st,fmc2-ebi-cs-data-setup-ns:
description: This property defines the duration of the data setup phase
in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-bus-turnaround-ns:
description: This property defines the delay in nanoseconds between the
end of current read/write transaction and the next transaction.
st,fmc2-ebi-cs-data-hold-ns:
description: This property defines the duration of the data hold phase
in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-clk-period-ns:
description: This property defines the FMC_CLK output signal period in
nanoseconds.
st,fmc2-ebi-cs-data-latency-ns:
description: This property defines the data latency before reading or
writing the first data in nanoseconds.
st,fmc2-ebi-cs-write-address-setup-ns:
description: This property defines the duration of the address setup
phase in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-write-address-hold-ns:
description: This property defines the duration of the address hold
phase in nanoseconds used for asynchronous multiplexed write
transactions.
st,fmc2-ebi-cs-write-data-setup-ns:
description: This property defines the duration of the data setup
phase in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-write-bus-turnaround-ns:
description: This property defines the delay between the end of current
write transaction and the next transaction in nanoseconds.
st,fmc2-ebi-cs-write-data-hold-ns:
description: This property defines the duration of the data hold phase
in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-max-low-pulse-ns:
description: This property defines the maximum chip select low pulse
duration in nanoseconds for synchronous transactions. When this timing
reaches 0, the controller splits the current access, toggles NE to
allow device refresh and restarts a new access.
additionalProperties: true
......@@ -48,143 +48,7 @@ properties:
patternProperties:
"^.*@[0-4],[a-f0-9]+$":
type: object
properties:
reg:
description: Bank number, base address and size of the device.
st,fmc2-ebi-cs-transaction-type:
description: |
Select one of the transactions type supported
0: Asynchronous mode 1 SRAM/FRAM.
1: Asynchronous mode 1 PSRAM.
2: Asynchronous mode A SRAM/FRAM.
3: Asynchronous mode A PSRAM.
4: Asynchronous mode 2 NOR.
5: Asynchronous mode B NOR.
6: Asynchronous mode C NOR.
7: Asynchronous mode D NOR.
8: Synchronous read synchronous write PSRAM.
9: Synchronous read asynchronous write PSRAM.
10: Synchronous read synchronous write NOR.
11: Synchronous read asynchronous write NOR.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 11
st,fmc2-ebi-cs-cclk-enable:
description: Continuous clock enable (first bank must be configured
in synchronous mode). The FMC_CLK is generated continuously
during asynchronous and synchronous access. By default, the
FMC_CLK is only generated during synchronous access.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-mux-enable:
description: Address/Data multiplexed on databus (valid only with
NOR and PSRAM transactions type). By default, Address/Data
are not multiplexed.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-buswidth:
description: Data bus width
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 8, 16 ]
default: 16
st,fmc2-ebi-cs-waitpol-high:
description: Wait signal polarity (NWAIT signal active high).
By default, NWAIT is active low.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-waitcfg-enable:
description: The NWAIT signal indicates wheither the data from the
device are valid or if a wait state must be inserted when accessing
the device in synchronous mode. By default, the NWAIT signal is
active one data cycle before wait state.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-wait-enable:
description: The NWAIT signal is enabled (its level is taken into
account after the programmed latency period to insert wait states
if asserted). By default, the NWAIT signal is disabled.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-asyncwait-enable:
description: The NWAIT signal is taken into account during asynchronous
transactions. By default, the NWAIT signal is not taken into account
during asynchronous transactions.
$ref: /schemas/types.yaml#/definitions/flag
st,fmc2-ebi-cs-cpsize:
description: CRAM page size. The controller splits the burst access
when the memory page is reached. By default, no burst split when
crossing page boundary.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 128, 256, 512, 1024 ]
default: 0
st,fmc2-ebi-cs-byte-lane-setup-ns:
description: This property configures the byte lane setup timing
defined in nanoseconds from NBLx low to Chip Select NEx low.
st,fmc2-ebi-cs-address-setup-ns:
description: This property defines the duration of the address setup
phase in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-address-hold-ns:
description: This property defines the duration of the address hold
phase in nanoseconds used for asynchronous multiplexed read/write
transactions.
st,fmc2-ebi-cs-data-setup-ns:
description: This property defines the duration of the data setup phase
in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-bus-turnaround-ns:
description: This property defines the delay in nanoseconds between the
end of current read/write transaction and the next transaction.
st,fmc2-ebi-cs-data-hold-ns:
description: This property defines the duration of the data hold phase
in nanoseconds used for asynchronous read/write transactions.
st,fmc2-ebi-cs-clk-period-ns:
description: This property defines the FMC_CLK output signal period in
nanoseconds.
st,fmc2-ebi-cs-data-latency-ns:
description: This property defines the data latency before reading or
writing the first data in nanoseconds.
st,fmc2_ebi-cs-write-address-setup-ns:
description: This property defines the duration of the address setup
phase in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-write-address-hold-ns:
description: This property defines the duration of the address hold
phase in nanoseconds used for asynchronous multiplexed write
transactions.
st,fmc2-ebi-cs-write-data-setup-ns:
description: This property defines the duration of the data setup
phase in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-write-bus-turnaround-ns:
description: This property defines the delay between the end of current
write transaction and the next transaction in nanoseconds.
st,fmc2-ebi-cs-write-data-hold-ns:
description: This property defines the duration of the data hold phase
in nanoseconds used for asynchronous write transactions.
st,fmc2-ebi-cs-max-low-pulse-ns:
description: This property defines the maximum chip select low pulse
duration in nanoseconds for synchronous transactions. When this timing
reaches 0, the controller splits the current access, toggles NE to
allow device refresh and restarts a new access.
required:
- reg
$ref: mc-peripheral-props.yaml#
required:
- "#address-cells"
......
......@@ -44,6 +44,7 @@ required:
allOf:
- $ref: ethernet-controller.yaml#
- $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
- if:
properties:
compatible:
......
......@@ -136,7 +136,8 @@
#define RPCIF_PHYCNT_DDRCAL BIT(19)
#define RPCIF_PHYCNT_HS BIT(18)
#define RPCIF_PHYCNT_CKSEL(v) (((v) & 0x3) << 16) /* valid only for RZ/G2L */
#define RPCIF_PHYCNT_STRTIM(v) (((v) & 0x7) << 15) /* valid for R-Car and RZ/G2{E,H,M,N} */
#define RPCIF_PHYCNT_STRTIM(v) (((v) & 0x7) << 15 | ((v) & 0x8) << 24) /* valid for R-Car and RZ/G2{E,H,M,N} */
#define RPCIF_PHYCNT_WBUF2 BIT(4)
#define RPCIF_PHYCNT_WBUF BIT(2)
#define RPCIF_PHYCNT_PHYMEM(v) (((v) & 0x3) << 0)
......@@ -317,9 +318,15 @@ int rpcif_hw_init(struct rpcif *rpc, bool hyperflash)
regmap_update_bits(rpc->regmap, RPCIF_PHYCNT, RPCIF_PHYCNT_PHYMEM_MASK,
RPCIF_PHYCNT_PHYMEM(hyperflash ? 3 : 0));
/* DMA Transfer is not supported */
regmap_update_bits(rpc->regmap, RPCIF_PHYCNT, RPCIF_PHYCNT_HS, 0);
if (rpc->type == RPCIF_RCAR_GEN3)
regmap_update_bits(rpc->regmap, RPCIF_PHYCNT,
RPCIF_PHYCNT_STRTIM(7), RPCIF_PHYCNT_STRTIM(7));
else if (rpc->type == RPCIF_RCAR_GEN4)
regmap_update_bits(rpc->regmap, RPCIF_PHYCNT,
RPCIF_PHYCNT_STRTIM(15), RPCIF_PHYCNT_STRTIM(15));
regmap_update_bits(rpc->regmap, RPCIF_PHYOFFSET1, RPCIF_PHYOFFSET1_DDRTMG(3),
RPCIF_PHYOFFSET1_DDRTMG(3));
......@@ -330,17 +337,17 @@ int rpcif_hw_init(struct rpcif *rpc, bool hyperflash)
regmap_update_bits(rpc->regmap, RPCIF_PHYINT,
RPCIF_PHYINT_WPVAL, 0);
if (rpc->type == RPCIF_RCAR_GEN3)
regmap_update_bits(rpc->regmap, RPCIF_CMNCR,
RPCIF_CMNCR_MOIIO(3) | RPCIF_CMNCR_BSZ(3),
RPCIF_CMNCR_MOIIO(3) |
RPCIF_CMNCR_BSZ(hyperflash ? 1 : 0));
else
if (rpc->type == RPCIF_RZ_G2L)
regmap_update_bits(rpc->regmap, RPCIF_CMNCR,
RPCIF_CMNCR_MOIIO(3) | RPCIF_CMNCR_IOFV(3) |
RPCIF_CMNCR_BSZ(3),
RPCIF_CMNCR_MOIIO(1) | RPCIF_CMNCR_IOFV(2) |
RPCIF_CMNCR_BSZ(hyperflash ? 1 : 0));
else
regmap_update_bits(rpc->regmap, RPCIF_CMNCR,
RPCIF_CMNCR_MOIIO(3) | RPCIF_CMNCR_BSZ(3),
RPCIF_CMNCR_MOIIO(3) |
RPCIF_CMNCR_BSZ(hyperflash ? 1 : 0));
/* Set RCF after BSZ update */
regmap_write(rpc->regmap, RPCIF_DRCR, RPCIF_DRCR_RCF);
......@@ -715,6 +722,7 @@ static int rpcif_remove(struct platform_device *pdev)
static const struct of_device_id rpcif_of_match[] = {
{ .compatible = "renesas,rcar-gen3-rpc-if", .data = (void *)RPCIF_RCAR_GEN3 },
{ .compatible = "renesas,rcar-gen4-rpc-if", .data = (void *)RPCIF_RCAR_GEN4 },
{ .compatible = "renesas,rzg2l-rpc-if", .data = (void *)RPCIF_RZ_G2L },
{},
};
......
......@@ -84,20 +84,7 @@ static int tegra186_emc_debug_available_rates_show(struct seq_file *s,
return 0;
}
static int tegra186_emc_debug_available_rates_open(struct inode *inode,
struct file *file)
{
return single_open(file, tegra186_emc_debug_available_rates_show,
inode->i_private);
}
static const struct file_operations tegra186_emc_debug_available_rates_fops = {
.open = tegra186_emc_debug_available_rates_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
DEFINE_SHOW_ATTRIBUTE(tegra186_emc_debug_available_rates);
static int tegra186_emc_debug_min_rate_get(void *data, u64 *rate)
{
......
......@@ -841,20 +841,7 @@ static int tegra_emc_debug_available_rates_show(struct seq_file *s, void *data)
return 0;
}
static int tegra_emc_debug_available_rates_open(struct inode *inode,
struct file *file)
{
return single_open(file, tegra_emc_debug_available_rates_show,
inode->i_private);
}
static const struct file_operations tegra_emc_debug_available_rates_fops = {
.open = tegra_emc_debug_available_rates_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
DEFINE_SHOW_ATTRIBUTE(tegra_emc_debug_available_rates);
static int tegra_emc_debug_min_rate_get(void *data, u64 *rate)
{
......
......@@ -1621,20 +1621,7 @@ static int tegra210_emc_debug_available_rates_show(struct seq_file *s,
return 0;
}
static int tegra210_emc_debug_available_rates_open(struct inode *inode,
struct file *file)
{
return single_open(file, tegra210_emc_debug_available_rates_show,
inode->i_private);
}
static const struct file_operations tegra210_emc_debug_available_rates_fops = {
.open = tegra210_emc_debug_available_rates_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
DEFINE_SHOW_ATTRIBUTE(tegra210_emc_debug_available_rates);
static int tegra210_emc_debug_min_rate_get(void *data, u64 *rate)
{
......
......@@ -1359,20 +1359,7 @@ static int tegra_emc_debug_available_rates_show(struct seq_file *s, void *data)
return 0;
}
static int tegra_emc_debug_available_rates_open(struct inode *inode,
struct file *file)
{
return single_open(file, tegra_emc_debug_available_rates_show,
inode->i_private);
}
static const struct file_operations tegra_emc_debug_available_rates_fops = {
.open = tegra_emc_debug_available_rates_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
DEFINE_SHOW_ATTRIBUTE(tegra_emc_debug_available_rates);
static int tegra_emc_debug_min_rate_get(void *data, u64 *rate)
{
......
......@@ -59,6 +59,7 @@ struct rpcif_op {
enum rpcif_type {
RPCIF_RCAR_GEN3,
RPCIF_RCAR_GEN4,
RPCIF_RZ_G2L,
};
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment