<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/ram, branch v2022.10</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>RAM: Add changes for i.MXRT11xx series</title>
<updated>2022-09-18T18:42:56+00:00</updated>
<author>
<name>Jesse Taube</name>
<email>mr.bossman075@gmail.com</email>
</author>
<published>2022-07-26T05:43:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7d9c6f1781be08512703aa1aa2f6bb9b17b7150f'/>
<id>7d9c6f1781be08512703aa1aa2f6bb9b17b7150f</id>
<content type='text'>
The i.MXRT11 series has different offsets for IOCR_MUX, it also can
address 64MiB of SDRAM so add a macro for that.

Signed-off-by: Jesse Taube &lt;Mr.Bossman075@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The i.MXRT11 series has different offsets for IOCR_MUX, it also can
address 64MiB of SDRAM so add a macro for that.

Signed-off-by: Jesse Taube &lt;Mr.Bossman075@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ram: rk3399: Conduct memory training at 400MHz</title>
<updated>2022-09-04T12:00:38+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2022-08-11T07:58:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=337e92e79c95ffb8c0c6e7b4023c955c50fca018'/>
<id>337e92e79c95ffb8c0c6e7b4023c955c50fca018</id>
<content type='text'>
Currently the default initialisation frequency is 50MHz.  Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.

Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.

Link: https://lore.kernel.org/u-boot/Yo4v3jUeHXTovjOH@google.com/
Suggested-by: YouMin Chen &lt;cym@rock-chips.com&gt;
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
Tested-by: Michal Suchánek &lt;msuchanek@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the default initialisation frequency is 50MHz.  Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.

Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.

Link: https://lore.kernel.org/u-boot/Yo4v3jUeHXTovjOH@google.com/
Suggested-by: YouMin Chen &lt;cym@rock-chips.com&gt;
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
Tested-by: Michal Suchánek &lt;msuchanek@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ram: rk3399: Fix faulty frequency change reports</title>
<updated>2022-09-04T12:00:38+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2022-08-11T07:58:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=daef678cffb9fb387c44d45d827d2b8ea199eb5b'/>
<id>daef678cffb9fb387c44d45d827d2b8ea199eb5b</id>
<content type='text'>
Frequency changes to 400MHz are presently reported as:

  lpddr4_set_rate_0: change freq to 400000000 mhz 0, 1

This is obviously wrong by 6 orders of magnitude.

Ensure frequency changes are reported accurately.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Frequency changes to 400MHz are presently reported as:

  lpddr4_set_rate_0: change freq to 400000000 mhz 0, 1

This is obviously wrong by 6 orders of magnitude.

Ensure frequency changes are reported accurately.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ram: rk3399: Fix .set_rate_index() error handling</title>
<updated>2022-09-04T12:00:38+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2022-08-11T07:58:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7b561e2ab8ac980023c5e5325f45a8ca1951c0dd'/>
<id>7b561e2ab8ac980023c5e5325f45a8ca1951c0dd</id>
<content type='text'>
Functions pointed to by this op pointer can return non-zero values
indicating an error.  Ensure any error value is propagated back up the
call-chain.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Functions pointed to by this op pointer can return non-zero values
indicating an error.  Ensure any error value is propagated back up the
call-chain.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Tested-by: Xavier Drudis Ferran &lt;xdrudis@tinet.cat&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: ram: rockchip: Fix dram channels calculation for rk3399</title>
<updated>2022-09-04T12:00:38+00:00</updated>
<author>
<name>Han Pengfei</name>
<email>pengphei@foxmail.com</email>
</author>
<published>2022-05-15T06:11:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=fc1526f651a557ddbf7c3cba8575be963573871f'/>
<id>fc1526f651a557ddbf7c3cba8575be963573871f</id>
<content type='text'>
Only add the dram channel when we finally setup it successfully at the
last step.

Signed-off-by: Han Pengfei &lt;pengphei@foxmail.com&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Only add the dram channel when we finally setup it successfully at the
last step.

Signed-off-by: Han Pengfei &lt;pengphei@foxmail.com&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654</title>
<updated>2022-07-25T17:02:04+00:00</updated>
<author>
<name>Andrew Davis</name>
<email>afd@ti.com</email>
</author>
<published>2022-07-15T15:25:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=80b93bb71cfff8b0ba9bbb5704231216f7518998'/>
<id>80b93bb71cfff8b0ba9bbb5704231216f7518998</id>
<content type='text'>
The first AM6x device was the AM654x, but being the first we named it
just AM6, since more devices have come out with this same prefix we
should switch it to the normal convention of using the full name of the
first compatibility device the series. This makes what device we are
talking about more clear and matches all the K3 devices added since.

Signed-off-by: Andrew Davis &lt;afd@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The first AM6x device was the AM654x, but being the first we named it
just AM6, since more devices have come out with this same prefix we
should switch it to the normal convention of using the full name of the
first compatibility device the series. This makes what device we are
talking about more clear and matches all the K3 devices added since.

Signed-off-by: Andrew Davis &lt;afd@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpl: Ensure all TPL symbols in Kconfig have some TPL dependency</title>
<updated>2022-06-28T21:03:31+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2022-06-08T12:24:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8bea4bf7d31d2ab8a4a0162755b79a4a59a90dcd'/>
<id>8bea4bf7d31d2ab8a4a0162755b79a4a59a90dcd</id>
<content type='text'>
Tighten up symbol dependencies in a number of places.  Ensure that a TPL
specific option has at least a direct dependency on TPL.  In places
where it's clear that we depend on something more specific, use that
dependency instead.

Reported-by: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tighten up symbol dependencies in a number of places.  Ensure that a TPL
specific option has at least a direct dependency on TPL.  In places
where it's clear that we depend on something more specific, use that
dependency instead.

Reported-by: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ram: stm32mp1: add support of STM32MP13x</title>
<updated>2022-06-17T08:41:16+00:00</updated>
<author>
<name>Patrick Delaunay</name>
<email>patrick.delaunay@foss.st.com</email>
</author>
<published>2022-05-20T16:24:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a46dce2817f574ee1186cc82a19ca9a99869b349'/>
<id>a46dce2817f574ee1186cc82a19ca9a99869b349</id>
<content type='text'>
Add support for new compatible "st,stm32mp13-ddr" to manage the
DDR sub system (Controller and PHY) in STM32MP13x SOC:
- only one AXI port
- support of 16 port output (MEMC_DRAM_DATA_WIDTH = 2)

The STM32MP15x SOC have 2 AXI ports and 32 bits support.

Signed-off-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Reviewed-by: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for new compatible "st,stm32mp13-ddr" to manage the
DDR sub system (Controller and PHY) in STM32MP13x SOC:
- only one AXI port
- support of 16 port output (MEMC_DRAM_DATA_WIDTH = 2)

The STM32MP15x SOC have 2 AXI ports and 32 bits support.

Signed-off-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Reviewed-by: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: mach-k3: Introduce the basic files to support AM62</title>
<updated>2022-06-10T17:37:32+00:00</updated>
<author>
<name>Suman Anna</name>
<email>s-anna@ti.com</email>
</author>
<published>2022-05-25T08:08:42+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d98e860051553fa4d395a7e7da8e40d1c8e21f71'/>
<id>d98e860051553fa4d395a7e7da8e40d1c8e21f71</id>
<content type='text'>
The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
architecture platform, providing ultra-low-power modes, dual display,
multi-sensor edge compute, security and other BOM-saving integration.
The AM62 SoC targets broad market to enable applications such as
Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
Automation, Appliances and more.

Some highlights of this SoC are:

* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
  Pin-to-pin compatible options for single and quad core are available.
* Cortex-M4F for general-purpose or safety usage.
* Dual display support, providing 24-bit RBG parallel interface and
  OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
  resolution.
* Selectable GPUsupport, up to 8GFLOPS, providing better user experience
  in 3D graphic display case and Android.
* PRU(Programmable Realtime Unit) support for customized programmable
  interfaces/IOs.
* Integrated Giga-bit Ethernet switch supporting up to a total of two
  external ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
  NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
  1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized System Controller for Security, Power, and
  Resource Management.
* Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
  enabling battery powered system design.

AM625 is the first device of the family. Add DT bindings for the same.

More details can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7

Signed-off-by: Suman Anna &lt;s-anna@ti.com&gt;
Signed-off-by: Gowtham Tammana &lt;g-tammana@ti.com&gt;
Signed-off-by: Aswath Govindraju &lt;a-govindraju@ti.com&gt;
Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
architecture platform, providing ultra-low-power modes, dual display,
multi-sensor edge compute, security and other BOM-saving integration.
The AM62 SoC targets broad market to enable applications such as
Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
Automation, Appliances and more.

Some highlights of this SoC are:

* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
  Pin-to-pin compatible options for single and quad core are available.
* Cortex-M4F for general-purpose or safety usage.
* Dual display support, providing 24-bit RBG parallel interface and
  OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
  resolution.
* Selectable GPUsupport, up to 8GFLOPS, providing better user experience
  in 3D graphic display case and Android.
* PRU(Programmable Realtime Unit) support for customized programmable
  interfaces/IOs.
* Integrated Giga-bit Ethernet switch supporting up to a total of two
  external ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
  NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
  1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized System Controller for Security, Power, and
  Resource Management.
* Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
  enabling battery powered system design.

AM625 is the first device of the family. Add DT bindings for the same.

More details can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7

Signed-off-by: Suman Anna &lt;s-anna@ti.com&gt;
Signed-off-by: Gowtham Tammana &lt;g-tammana@ti.com&gt;
Signed-off-by: Aswath Govindraju &lt;a-govindraju@ti.com&gt;
Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ram: stm32mp1: Conditionally enable ASR</title>
<updated>2022-05-10T11:54:47+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2022-04-26T14:37:41+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=221869efc3a4cf975c1bf068227f17ce10cd5597'/>
<id>221869efc3a4cf975c1bf068227f17ce10cd5597</id>
<content type='text'>
Enable DRAM ASR, auto self-refresh, conditionally, based on DT PWRCTL
register bits. While ASR does save considerable amount of power at
runtime automatically, it also causes LTDC underruns on large panels.
Let user select whether or not ASR is required or not, generally ASR
should be enabled on portable and battery operated devices.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Cc: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
Reviewed-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Signed-off-by: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable DRAM ASR, auto self-refresh, conditionally, based on DT PWRCTL
register bits. While ASR does save considerable amount of power at
runtime automatically, it also causes LTDC underruns on large panels.
Let user select whether or not ASR is required or not, generally ASR
should be enabled on portable and battery operated devices.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Cc: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
Reviewed-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
Signed-off-by: Patrice Chotard &lt;patrice.chotard@foss.st.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
