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: Arnd Bergmann <arnd@arndb.de>
Showing
Please register or sign in to comment