<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/ddr, branch v2022.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/drivers/ddr?h=v2022.04</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers/ddr?h=v2022.04'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2022-02-17T13:17:07Z</updated>
<entry>
<title>ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision</title>
<updated>2022-02-17T13:17:07Z</updated>
<author>
<name>Marek Behún</name>
<email>marek.behun@nic.cz</email>
</author>
<published>2022-02-17T00:08:37Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a163db9fbaa9004bc461d8b1c6b648c674c25f09'/>
<id>urn:sha1:a163db9fbaa9004bc461d8b1c6b648c674c25f09</id>
<content type='text'>
In commit 3fc92a215b69 ("ddr: marvell: a38x: fix SPLIT_OUT_MIX state
decision") I ported a cleaned up and changed version of patch
  mv_ddr: a380: fix SPLIT_OUT_MIX state decision

In the port we removed checking for BYTE_HOMOGENEOUS_SPLIT_OUT bit,
because:
- the fix seemed to work without it
- the bit was checked for only at one place out of two, while the second
  bit, BYTE_SPLIT_OUT_MIX, was checked for in both cases
- without the removal it didn't work on Allied Telesis' x530 board

We recently had a chance to test on more boards, and it seems that the
change needs to be opposite: instead of removing the check for
BYTE_HOMOGENEOUS_SPLIT_OUT from the first if() statement, the check
needs to be added also to the second one - it needs to be at both
places.

With this change all the Turris Omnia boards I have had available to
test seem to work, I didn't encounter not even one failed DDR training.

As last time, I am noting that I do not understand what this code is
actually doing, I haven't studied the DDR training algorithm and
I suspect that no one will be able to explain it to U-Boot contributors,
so we are left with this blind poking in the code with testing whether
it works on several boards and hoping it doesn't break anything for
anyone :-(.

Signed-off-by: Marek Behún &lt;marek.behun@nic.cz&gt;
Tested-by: Chris Packham &lt;judge.packham@gmail.com&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>imx8ulp: ddr: Fix DDR frequency request issue</title>
<updated>2022-02-05T12:38:39Z</updated>
<author>
<name>Ye Li</name>
<email>ye.li@nxp.com</email>
</author>
<published>2021-10-29T01:46:34Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=01aa4cd8baacec1ac1135ba8ead9f5e968aef9ae'/>
<id>urn:sha1:01aa4cd8baacec1ac1135ba8ead9f5e968aef9ae</id>
<content type='text'>
After acking the requested frequency, should wait the ack bit clear
by DDR controller and check the DFS interrupt for next request polling.
Otherwise, the next polling of request bit will get previous value
that DDR controller have not cleared it, so a wrong request frequency
is used.

Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Signed-off-by: Ye Li &lt;ye.li@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>imx8ulp:ddr: saving the dram config timing data into sram</title>
<updated>2022-02-05T12:38:39Z</updated>
<author>
<name>Jacky Bai</name>
<email>ping.bai@nxp.com</email>
</author>
<published>2021-10-29T01:46:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b80ec768a3b27e245dbea3e4fac0a0d154e4b729'/>
<id>urn:sha1:b80ec768a3b27e245dbea3e4fac0a0d154e4b729</id>
<content type='text'>
On i.MX8ULP, The dram config timing need to be saved into sram for
ddr retention when APD enter PD mode, so add this support on i.MX8ULP.

Reviewed-by: Ye Li &lt;ye.li@nxp.com&gt;
Signed-off-by: Jacky Bai &lt;ping.bai@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision</title>
<updated>2022-01-14T10:39:15Z</updated>
<author>
<name>Marek Behún</name>
<email>marek.behun@nic.cz</email>
</author>
<published>2022-01-12T16:06:59Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3fc92a215b69ad448c151489228eb340df9a8703'/>
<id>urn:sha1:3fc92a215b69ad448c151489228eb340df9a8703</id>
<content type='text'>
This is a cleaned up and fixed version of a patch
  mv_ddr: a380: fix SPLIT_OUT_MIX state decision

  in each pattern cycle the bus state can be changed
  in order to avoide it, need to back to the same bus state on each
  pattern cycle
by
  Moti Boskula &lt;motib@marvell.com&gt;

The original patch is not in Marvell's mv-ddr-marvell repository. It was
gives to us by Marvell to fix an issues with DDR training on some
boards, but it cannot be applied as is to mv-ddr-marvell, because it is
a very dirty draft patch that would certainly break other things, mainly
DDR4 training code in mv-ddr-marvell, since it changes common functions.

I have cleaned up the patch and removed stuff that seemed unnecessary
(when removed, it still fixed things). Note that I don't understand
completely what the code does exactly, since I haven't studied the DDR
training code extensively (and I suspect that no one besides some few
people in Marvell understand the code completely).

Anyway after the cleanup the patch still fixes isssues with DDR training
on the failing boards.

There was also a problem with the original patch on some of the Allied
Telesis' x530 boards, reported by Chris Packham. I have asked Chris to
send me some logs, and managed to fix it:
- if you look at the change, you'll notice that it introduces
  subtraction of cur_start_win[] and cur_end_win[] members, depending on
  a bit set in the current_byte_status variable
- the original patch subtracted cur_start_win[] if either
  BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but
  subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX)
  was set
- from Chris Packham logs I discovered that the x530 board where the
  original patch introduced DDR training failure, only the
  BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the
  patch is needed only the BYTE_SPLIT_OUT_MIX is set in the
  current_byte_status variable
- this led me to the hypothesis that both cur_start_win[] and
  cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is
  set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all
- this hypothesis also gains credibility when considering the commit
  title ("fix SPLIT_OUT_MIX state decision")

Hopefully this will fix things without breaking anything else.

Signed-off-by: Marek Behún &lt;marek.behun@nic.cz&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
Tested-by: Chris Packham &lt;judge.packham@gmail.com&gt;
</content>
</entry>
<entry>
<title>ddr: marvell: a38x: Fix Synchronous vs Asynchronous mode determination</title>
<updated>2022-01-14T06:47:57Z</updated>
<author>
<name>Marek Behún</name>
<email>marek.behun@nic.cz</email>
</author>
<published>2022-01-04T14:57:49Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=eadc4f512fb43bba2fa4e842c982da919da664be'/>
<id>urn:sha1:eadc4f512fb43bba2fa4e842c982da919da664be</id>
<content type='text'>
Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode"), Asynchornous Mode was only used when the CPU Subsystem Clock
Options[4:0] field in the SAR1 register was set to value 0x13: CPU at
2 GHz and DDR at 933 MHz.

Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async
mode") added support for Asynchornous Modes with frequencies other than
933 MHz (but at least 467 MHz), but the code it added to check for
whether Asynchornous Mode should be used is wrong: it checks whether the
frequency setting in board DDR topology map is set to value other than
MV_DDR_FREQ_SAR.

Thus boards which define a specific value, greater than 400 MHz, for DDR
frequency in their board topology (e.g. Turris Omnia defines
MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that
commit.

The A38x Functional Specification, section 10.12 DRAM Clocking, says:
  In Synchornous mode, the DRAM and CPU clocks are edge aligned and run
  in 1:2 or 1:3 CPU to DRAM frequency ratios.

Change the check for whether Asynchornous Mode should be used according
to this explanation in Functional Specification.

Signed-off-by: Marek Behún &lt;marek.behun@nic.cz&gt;
Tested-by: Chris Packham &lt;judge.packham@gmail.com&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>drivers/ddr/altera/sequencer.c: Fix spelling of "resetting".</title>
<updated>2022-01-13T12:57:50Z</updated>
<author>
<name>Vagrant Cascadian</name>
<email>vagrant@debian.org</email>
</author>
<published>2021-12-21T21:07:01Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0776c5fbb7d3693d69796fc811f3040644e3576b'/>
<id>urn:sha1:0776c5fbb7d3693d69796fc811f3040644e3576b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>arm: mvebu: axp: ddr: Switch to using DM I2C API</title>
<updated>2021-12-19T08:50:47Z</updated>
<author>
<name>Stefan Roese</name>
<email>sr@denx.de</email>
</author>
<published>2021-11-18T08:19:38Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0cbd3d8121189690130257009aa9363232c888d5'/>
<id>urn:sha1:0cbd3d8121189690130257009aa9363232c888d5</id>
<content type='text'>
No functional change intended. This patch switches from the legacy I2C
API to the DM I2C API, so that this code can be used with DM I2C
enabled.

Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>arm: mvebu: axp: Remove unreferenced ddr3_get_eprom_fabric() function</title>
<updated>2021-12-19T08:50:47Z</updated>
<author>
<name>Stefan Roese</name>
<email>sr@denx.de</email>
</author>
<published>2021-11-18T08:19:37Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=622882893d83e73e63d6c8c03c81bbbd2f04c19a'/>
<id>urn:sha1:622882893d83e73e63d6c8c03c81bbbd2f04c19a</id>
<content type='text'>
This function is not referenced in mainline U-Boot. Let's remove now.

Signed-off-by: Stefan Roese &lt;sr@denx.de&gt;
</content>
</entry>
<entry>
<title>Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig</title>
<updated>2021-12-01T15:58:10Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2021-11-13T23:10:40Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=c7fad78ec0ee41b72a58bebb61959570eb937ab1'/>
<id>urn:sha1:c7fad78ec0ee41b72a58bebb61959570eb937ab1</id>
<content type='text'>
This converts the following to Kconfig:
   CONFIG_SYS_BR0_PRELIM
   CONFIG_SYS_OR1_PRELIM
   CONFIG_SYS_BR1_PRELIM
   CONFIG_SYS_OR2_PRELIM
   CONFIG_SYS_BR2_PRELIM
   CONFIG_SYS_OR2_PRELIM
   CONFIG_SYS_BR3_PRELIM
   CONFIG_SYS_OR3_PRELIM
   CONFIG_SYS_BR4_PRELIM
   CONFIG_SYS_OR4_PRELIM
   CONFIG_SYS_BR5_PRELIM
   CONFIG_SYS_OR5_PRELIM
   CONFIG_SYS_BR6_PRELIM
   CONFIG_SYS_OR6_PRELIM
   CONFIG_SYS_BR7_PRELIM
   CONFIG_SYS_OR7_PRELIM

This also introduces CONFIG_SYS_BR0_PRELIM_BOOL as not all platforms
that can set these values do so.  Add the relevant SYS_BRx_PRELIM_BOOL
to platforms that had not been previously migrated.

Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>drivers: ddr: lc_common_dimm_params.c : Fix Divison by zero issue</title>
<updated>2021-11-09T11:48:23Z</updated>
<author>
<name>Maninder Singh</name>
<email>maninder.singh_1@nxp.com</email>
</author>
<published>2021-10-10T16:12:16Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=38ce95a1c6fdc7a2a8cc177202cd421beef56427'/>
<id>urn:sha1:38ce95a1c6fdc7a2a8cc177202cd421beef56427</id>
<content type='text'>
Adds check for memory clock variable before calculating caslat_actual.

Set mclk_ps to slowest DIMM supported if mclk_ps is found zero.

Signed-off-by: Maninder Singh &lt;maninder.singh_1@nxp.com&gt;
Reviewed-by: Priyanka Jain &lt;priyanka.jain@nxp.com&gt;
</content>
</entry>
</feed>
