mirror of
https://github.com/torvalds/linux.git
synced 2026-03-09 18:16:36 +01:00
9e549c7637
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
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmNZap0QHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1/ZWD/9DnBYeiDSsZgh3jN4lYlGtQMon+5NtuhQu
mfeVzUQcRx4bC+fSKwetFCIgftuuUHOGSUMdB9IqFHqT0Er51m54LCGRN832mS3Z
k7GMm8hCbCRF749dqs9CDBTpDUjwUqnd29Fx6kduKOyuGArNxvrpWBTfIP/O1HVW
i/kxQeS70eY8dojuKh6ucFpaNDFbLD1/aq9RvpCBEReSn530cUWyO/v2UdQ0yXGQ
1WX03a5uaDdhYgnt0RjEANIs13GrCKf1NPUjjolRI5plJbuZk8VEne22b7ONZjmp
5SUuWVTViv85sOVVVTFGtF43vUPOFVTZy0/SMZUBXMkSmFChhCpXgzfqOPhShUDn
yVXVu0NTnNOQdXhrWc+fbhgaik08WkJS8ejDZBqRKbFkPNaH9v6PJq9ZS5aGMk12
F7bqvSqlqNOLM5s1GpP5yDjL2Z1nyPN02W6E8YK8aQWHO9dapooo5jxE5jY39pfq
HqcLO/ndwCsiX3yfgqoJZhWyHYIv2ZE6yXCd3MKHDfvE31Nwk4Pa/R8o9hhWuCSX
hcQhzpi2KFOTwRMe6t7fE8CMKOQ9xh613zOtUaNu/ibaK1AZZyFEr9MS2+P3VPB6
viRWOzAUHJ4RWF8BDqdJVOxND7wAvv104Upu3z+HtF8VqUIwQGmmHGtkEEJbfjIy
Ymod/4tvAA==
=ancn
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmNi25wACgkQmmx57+YA
GNkJJg/9H7VF0VSpExpDJo8jEsXnV6HTs0EsthpOJnK6G10JFUpgsbEPYxJV6vjs
FaQgYoxNsox/hr/yhYeEO8HYI5Rs/qULr7HinbONdlm65g1fqr4WfwsdX4UM/5uM
HHn9w1CR8bxL1HH/fhYR4ElLJ8xEvlYztM+bUEUsAQXz4Hzj+6oXFq/pu+u68Zi1
mLT8hMxs/2ly5OQ2mL/mJCtSfH+y7rnRaSSvx/NBUg7RmUjH2o+baVRYHFlAUuKD
mvzrPohTXxSxOcfjrQYfQhEIyK4gwi0u4V+x+5fFMvTTIS0I6hDu9Us89F13EeF4
t2WbSoqLhKUF6qyUXOHTaFyDeQNb9U4Mz7aUsFDz+ya+ZAXIFmpq441lK6xru2cc
sBSiNWkFT+lnhG6qaOj2LZY6Anh60AMCQNz7nvEscgtJ7oq5Y5y2hvaVW+IpAh3w
xUXST3pHNyja5SI93MKxYayYlAiyXviNBMx8Ktjwm+CZmN0UHIfE4a11MDjeFAWd
rob99nGCTCdoDkrTUvxC2MLMBaARoHJitN0TY1mvr68TIv7r9yc/yjQHVB3thoaO
MbSRsWARaeDgUTSR7GwpMl7WSGWH4igsdMXuVB8FKm6ndg/Tr9A71/ErNFc8xilO
S/S9H7vR5/92O5l+h31eaIuGLubZXjilthzjnnPI+QHVhxf9J4o=
=HLKR
-----END PGP SIGNATURE-----
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.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kunit | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| memory | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| rv | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| ufs | ||
| vdso | ||
| video | ||
| xen | ||