All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
	arm@kernel.org, soc@kernel.org
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	linux-kernel@vger.kernel.org,
	Krzysztof Kozlowski <krzk@kernel.org>
Subject: [GIT PULL] memory: drivers for v6.2
Date: Wed, 26 Oct 2022 13:13:54 -0400	[thread overview]
Message-ID: <20221026171354.51877-1-krzysztof.kozlowski@linaro.org> (raw)

Hi,

This includes pieces from late (3rd) pull for v6.1, which did not make that time.

Best regards,
Krzysztof


The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:

  Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git tags/memory-controller-drv-6.2

for you to fetch changes up to a11a5debdf4b5b5c24e88a378b53b42cc4fe1bb9:

  dt-bindings: memory-controller: st,stm32: Split off MC properties (2022-10-18 13:05:18 -0400)

----------------------------------------------------------------
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

----------------------------------------------------------------
Cong Dang (1):
      memory: renesas-rpc-if: Clear HS bit during hardware initialization

Geert Uytterhoeven (1):
      memory: renesas-rpc-if: Add support for R-Car Gen4

Hai Pham (1):
      dt-bindings: memory: renesas,rpc-if: Document R-Car V4H support

Julius Werner (4):
      dt-bindings: memory: Factor out common properties of LPDDR bindings
      dt-bindings: memory: Add numeric LPDDR compatible string variant
      dt-bindings: memory: Add jedec,lpddr4 and jedec,lpddr5 bindings
      dt-bindings: memory: Add jedec,lpddrX-channel binding

Liu Shixin (4):
      memory: tegra20-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
      memory: tegra30-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
      memory: tegra210-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code
      memory: tegra186-emc: use DEFINE_SHOW_ATTRIBUTE to simplify code

Marek Vasut (2):
      dt-bindings: memory-controller: st,stm32: Fix st,fmc2_ebi-cs-write-address-setup-ns
      dt-bindings: memory-controller: st,stm32: Split off MC properties

 .../ddr/jedec,lpddr-channel.yaml                   | 146 +++++++++++++++++++++
 .../memory-controllers/ddr/jedec,lpddr-props.yaml  |  74 +++++++++++
 .../memory-controllers/ddr/jedec,lpddr2.yaml       |  48 ++-----
 .../memory-controllers/ddr/jedec,lpddr3.yaml       |  44 ++-----
 .../memory-controllers/ddr/jedec,lpddr4.yaml       |  35 +++++
 .../memory-controllers/ddr/jedec,lpddr5.yaml       |  46 +++++++
 .../memory-controllers/mc-peripheral-props.yaml    |  38 ++++++
 .../memory-controllers/renesas,rpc-if.yaml         |   5 +
 .../st,stm32-fmc2-ebi-props.yaml                   | 144 ++++++++++++++++++++
 .../memory-controllers/st,stm32-fmc2-ebi.yaml      | 138 +------------------
 .../devicetree/bindings/net/micrel,ks8851.yaml     |   1 +
 drivers/memory/renesas-rpc-if.c                    |  22 +++-
 drivers/memory/tegra/tegra186-emc.c                |  15 +--
 drivers/memory/tegra/tegra20-emc.c                 |  15 +--
 drivers/memory/tegra/tegra210-emc-core.c           |  15 +--
 drivers/memory/tegra/tegra30-emc.c                 |  15 +--
 include/memory/renesas-rpc-if.h                    |   1 +
 17 files changed, 531 insertions(+), 271 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-channel.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi-props.yaml

             reply	other threads:[~2022-10-26 17:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26 17:13 Krzysztof Kozlowski [this message]
2022-11-02 21:20 ` [GIT PULL] memory: drivers for v6.2 patchwork-bot+linux-soc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221026171354.51877-1-krzysztof.kozlowski@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=soc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.