Skip to content

L
linux
Switch branch/tag
  1. 22 Nov, 2022 1 commit
  3. 21 Nov, 2022 4 commits
  5. 17 Nov, 2022 1 commit
  7. 14 Nov, 2022 3 commits
  9. 10 Nov, 2022 1 commit
  11. 09 Nov, 2022 3 commits
  13. 02 Nov, 2022 4 commits
    • Arnd Bergmann's avatar
      Merge tag 'memory-controller-drv-6.2' of... · 9e549c76
      Arnd Bergmann authored 
      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>
      9e549c76
    • Benedikt Niedermayr's avatar
      dt-bindings: memory-controllers: ti,gpmc: add wait-pin polarity · 1f1e46b8
      Benedikt Niedermayr authored 
      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 WAITPIN<X>POLARITY bit
in the GPMC_CONFIG register by setting the "ti,wait-pin-polarity"
dt-property.
Signed-off-by: default avatarBenedikt Niedermayr <benedikt.niedermayr@siemens.com>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Reviewed-by: default avatarRoger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20221102133047.1654449-3-benedikt.niedermayr@siemens.comSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      1f1e46b8
    • Benedikt Niedermayr's avatar
      memory: omap-gpmc: wait pin additions · 89aed3cd
      Benedikt Niedermayr authored 
      This patch introduces support for setting the wait-pin polarity as well
as using the same wait-pin for different CS regions.

The waitpin polarity can be configured via the WAITPIN<X>POLARITY bits
in the GPMC_CONFIG register. This is currently not supported by the
driver. This patch adds support for setting the required register bits
with the "ti,wait-pin-polarity" dt-property.

The wait-pin can also be shared between different CS regions for special
usecases. Therefore GPMC must keep track of wait-pin allocations, so it
knows that either GPMC itself or another driver has the ownership.
Signed-off-by: default avatarBenedikt Niedermayr <benedikt.niedermayr@siemens.com>
Link: https://lore.kernel.org/r/20221102133047.1654449-2-benedikt.niedermayr@siemens.comReviewed-by: default avatarRoger Quadros <rogerq@kernel.org>
Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      89aed3cd
    • Lukas Bulwahn's avatar
      MAINTAINERS: arm,pl353-smc: correct dt-binding path · 3821e96a
      Lukas Bulwahn authored 
      Commit de67fa80 ("dt-bindings: memory-controllers: arm,pl353-smc:
Extend to support 'arm,pl354' SMC") renames the arm,pl353-smc.yaml
memory-controller dt-binding, but misses to adjust its reference in
MAINTAINERS.
Signed-off-by: default avatarLukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20221031110223.30203-1-lukas.bulwahn@gmail.comSigned-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
      3821e96a
  15. 01 Nov, 2022 1 commit
    • Linus Walleij's avatar
      soc: fsl: qe: Avoid using gpio_to_desc() · 84582f9e
      Linus Walleij authored 
      The qe gpio driver is a custom API combined GPIO and pin control
driver that exist outside of the pin control subsystem for historical
reasons.

We want to get rid of the old GPIO numberspace, so instead of
calling gpio_to_desc() we get the gpio descriptor for the requested
line from the device tree directly without passing through the
GPIO numberspace, and then we get the gpiochip from the descriptor.

Using the reference counting inside the gpio descriptor we can drop
the reference counting code in this driver. A second gpiod_get()
will not succeed.

To obtain the local hardware offset of the GPIO line, the driver
need to include the header from the gpiolib internals. This isn't
pretty but it is the lesser evil compared to keeping the code
as a roadblock to gpiolib refactoring. A proper solution would be
to rewrite the driver as a real pin control driver with a
built-in gpio_chip.
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linux-gpio@vger.kernel.org
Link: https://lore.kernel.org/r/20221027081108.174662-1-linus.walleij@linaro.org'
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      84582f9e
  17. 29 Oct, 2022 1 commit
  19. 28 Oct, 2022 1 commit
  21. 24 Oct, 2022 1 commit
  23. 23 Oct, 2022 10 commits
  25. 22 Oct, 2022 9 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7