drivers/ddr/altera: Add the DDR controller driver for SoCFPGA

From: Dinh Nguyen <[email protected]>

This patch enables the SDRAM controller that is used on Altera's SoCFPGA family. This patch configures the SDRAM controller based on a configuration file that is generated from the Quartus tool, sdram_config.h.

Signed-off-by Dinh Nguyen <[email protected]>

From: Dinh Nguyen <[email protected]>

This patch adds the DDR calibration portion of the Altera SDRAM driver.

Signed-off-by Dinh Nguyen <[email protected]>

Quoted 4 lines · dinguyen at opensource.altera.com

From: Dinh Nguyen <[email protected]>

This patch adds the DDR calibration portion of the Altera SDRAM driver.

Quoted 1 line

Signed-off-by Dinh Nguyen <[email protected]>

Hi,

DTTO here. The code is still ugly, but I'm afraid it's not gonna get any better if we keep it out of tree. It'd bet on getting this improved in-tree and under scrutiny from users. What do you think ?

Quoted 7 lines · Marek Vasut

Quoted 5 lines · dinguyen at opensource.altera.com

From: Dinh Nguyen <[email protected]>

This patch adds the DDR calibration portion of the Altera SDRAM driver.

Signed-off-by Dinh Nguyen <[email protected]>

Quoted 6 lines

Hi,

DTTO here. The code is still ugly, but I'm afraid it's not gonna get any better if we keep it out of tree. It'd bet on getting this improved in-tree and under scrutiny from users. What do you think ?

I agree. I really have tried my best to clean it up as best as I can.

Quoted 2 lines · Dinh Nguyen

Quoted 1 line · Marek Vasut

On Monday, May 18, 2015 at 09:36:48 PM, dinguyen at opensource.altera.com

Quoted 12 lines

Quoted 11 lines

Quoted 5 lines

From: Dinh Nguyen <[email protected]>

This patch adds the DDR calibration portion of the Altera SDRAM driver.

Signed-off-by Dinh Nguyen <[email protected]>

Hi,

DTTO here. The code is still ugly, but I'm afraid it's not gonna get any better if we keep it out of tree. It'd bet on getting this improved in-tree and under scrutiny from users. What do you think ?

Quoted 1 line

I agree. I really have tried my best to clean it up as best as I can.

Yes, thanks. Really appreciated. I know that especially these kind of DDR calibration code tend to be quite complex and "ugly". So I also vote for getting this applied now and perhaps improving it in-tree.

For this patch series:

Acked-by Stefan Roese <[email protected]>

Thanks,
Stefan

+/******************************************************************************
+ ******************************************************************************
+ ** NOTE: Special Rules for Globale Variables **

+ ** All global variables that are explicitly initialized (including          **
+ ** explicitly initialized to zero), are only initialized once, during       **
+ ** configuration time, and not again on reset.  This means that they        **
+ ** preserve their current contents across resets, which is needed for some  **
+ ** special cases involving communication with external modules.  In         **
+ ** addition, this avoids paying the price to have the memory initialized,   **

+ ** even for zeroed data, provided it is explicitly set to zero in the code, **
+ ** and doesn't rely on implicit initialization. **
+ ****************************************************************************** +

Quoted 11 lines

+ ** All global variables that are explicitly initialized (including          **
+ ** explicitly initialized to zero), are only initialized once, during       **
+ ** configuration time, and not again on reset.  This means that they        **
+ ** preserve their current contents across resets, which is needed for some  **
+ ** special cases involving communication with external modules.  In         **
+ ** addition, this avoids paying the price to have the memory initialized,   **

+ ** even for zeroed data, provided it is explicitly set to zero in the code, **
+ ** and doesn't rely on implicit initialization. **
+ ****************************************************************************** +

Is this sane thing to do? How does it work for variables in other sources?

Dear Pavel,

Quoted 12 lines · In message <20150525123750.GD9943@amd> you wrote:

Quoted 11 lines

+ ** All global variables that are explicitly initialized (including          **
+ ** explicitly initialized to zero), are only initialized once, during       **
+ ** configuration time, and not again on reset.  This means that they        **
+ ** preserve their current contents across resets, which is needed for some  **
+ ** special cases involving communication with external modules.  In         **
+ ** addition, this avoids paying the price to have the memory initialized,   **

+ ** even for zeroed data, provided it is explicitly set to zero in the code, **
+ ** and doesn't rely on implicit initialization. **
+ ****************************************************************************** +

Quoted 2 lines

Is this sane thing to do? How does it work for variables in other sources?

My concern is if this is actually true (and I asked this before, in an
earlier round ov reviews). I cannot make heads or tails of this
comment, as I don't understand what "configuration time" and "reset" are supposed to mean in U-Boot context. In my understanding, after a reset the memory content is uninitialized, i. e. random, and thus MUST always be properly initialized.

Also, what are "external modules"?

Quoted 19 lines · Wolfgang Denk

Dear Pavel,

Quoted 15 lines · In message <20150525123750.GD9943@amd> you wrote:

Quoted 9 lines

+ ** All global variables that are explicitly initialized (including ** + ** explicitly initialized to zero), are only initialized
once, during ** + ** configuration time, and not again on reset.
This means that they ** + ** preserve their current contents
across resets, which is needed for some ** + ** special cases
involving communication with external modules. In ** + **
addition, this avoids paying the price to have the memory initialized,
** + ** even for zeroed data, provided it is explicitly set to zero
in the code, ** + ** and doesn't rely on implicit initialization.

Quoted 3 lines

                       ** +

**********************************************************************
******** +

Is this sane thing to do? How does it work for variables in other sources?

Quoted 6 lines

My concern is if this is actually true (and I asked this before, in an
earlier round ov reviews). I cannot make heads or tails of this
comment, as I don't understand what "configuration time" and "reset" are supposed to mean in U-Boot context. In my understanding, after a reset the memory content is uninitialized, i. e. random, and thus MUST always be properly initialized.

This comment is related to the configuration where we have the NiOS cpu doing the ddr calibration and is not applicable for the Cyclone5/Arria5. So I think I can remove the comment for the the A5/C5 configuration.

This situation will come into play for the Arria10 SoCFPGA, because that part will have a NiOS cpu that will do the DDR configuration. "configuration time" happens at power-up

and "reset" is a warm reset.
From what I was told, the situation where we might want to preserve a variable after a reset is to avoid reconfiguring the NiOS in the FPGA for DDR operations.

Quoted 1 line

Also, what are "external modules"?

I think these could be different FPGA instances that needs these variables that have survived a warm reset to the CPU.

Quoted 20 lines · Dinh Nguyen

Quoted 19 lines · Wolfgang Denk

Dear Pavel,

Quoted 15 lines · In message <20150525123750.GD9943@amd> you wrote:

Quoted 9 lines

+ ** All global variables that are explicitly initialized (including ** + ** explicitly initialized to zero), are only initialized
once, during ** + ** configuration time, and not again on reset.
This means that they ** + ** preserve their current contents
across resets, which is needed for some ** + ** special cases
involving communication with external modules. In ** + **
addition, this avoids paying the price to have the memory initialized,
** + ** even for zeroed data, provided it is explicitly set to zero
in the code, ** + ** and doesn't rely on implicit initialization.

Quoted 3 lines

                       ** +

**********************************************************************
******** +

Is this sane thing to do? How does it work for variables in other sources?

Quoted 6 lines

Quoted 6 lines

My concern is if this is actually true (and I asked this before, in an
earlier round ov reviews). I cannot make heads or tails of this
comment, as I don't understand what "configuration time" and "reset" are supposed to mean in U-Boot context. In my understanding, after a reset the memory content is uninitialized, i. e. random, and thus MUST always be properly initialized.

Meh, since there's a pushback, I'll wait a bit with applying these until these remaining concerns settle :-/

Quoted 4 lines

This comment is related to the configuration where we have the NiOS cpu doing the ddr calibration and is not applicable for the Cyclone5/Arria5. So I think I can remove the comment for the the A5/C5 configuration.

OK, then this should be removed. A10 support should then be added in a separate patch please.

Quoted 3 lines

This situation will come into play for the Arria10 SoCFPGA, because that part will have a NiOS cpu that will do the DDR configuration. "configuration time" happens at power-up

So "configuration time" happens if the FPGA loads itself from EPCQ or does it happen also if the FPGA is not loaded at all ?

Quoted 5 lines

and "reset" is a warm reset.
From what I was told, the situation where we might want to preserve a variable after a reset is to avoid reconfiguring the NiOS in the FPGA for DDR operations.

Can't you synthesize a sticky register for this purpose in the FPGA instead? Or is it that this NIOS2 which configures the DRAM is actually a hardware, not a softcore ?

Quoted 4 lines

Quoted 1 line

Also, what are "external modules"?

I think these could be different FPGA instances that needs these variables that have survived a warm reset to the CPU.

I _think_ I understand most of the above, but I kinda wonder why don't you cook a small IP block on the avalon bus in the FPGA which would contain a sticky register to hold all those configuration sticky bits. That'd look much more sensible to me.

Quoted 9 lines

Quoted 6 lines

Quoted 6 lines

My concern is if this is actually true (and I asked this before, in an
earlier round ov reviews). I cannot make heads or tails of this
comment, as I don't understand what "configuration time" and "reset" are supposed to mean in U-Boot context. In my understanding, after a reset the memory content is uninitialized, i. e. random, and thus MUST always be properly initialized.

Meh, since there's a pushback, I'll wait a bit with applying these until these remaining concerns settle :-/

That's fine. I'll send a v4 with further clean ups.

Quoted 7 lines

Quoted 3 lines

This comment is related to the configuration where we have the NiOS cpu doing the ddr calibration and is not applicable for the Cyclone5/Arria5. So I think I can remove the comment for the the A5/C5 configuration.

OK, then this should be removed. A10 support should then be added in a separate patch please.

Quoted 6 lines

Quoted 3 lines

This situation will come into play for the Arria10 SoCFPGA, because that part will have a NiOS cpu that will do the DDR configuration. "configuration time" happens at power-up

So "configuration time" happens if the FPGA loads itself from EPCQ or does it happen also if the FPGA is not loaded at all ?

I think configuration time is only applicable when FPGA is programmed.

Quoted 8 lines

Quoted 4 lines

and "reset" is a warm reset.
From what I was told, the situation where we might want to preserve a variable after a reset is to avoid reconfiguring the NiOS in the FPGA for DDR operations.

Can't you synthesize a sticky register for this purpose in the FPGA instead? Or is it that this NIOS2 which configures the DRAM is actually a hardware, not a softcore ?

On the Arria10, the NIOS2 is a hardened block and not a softcore.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Also, what are "external modules"?

I think these could be different FPGA instances that needs these variables that have survived a warm reset to the CPU.

Quoted 4 lines

I _think_ I understand most of the above, but I kinda wonder why don't you cook a small IP block on the avalon bus in the FPGA which would contain a sticky register to hold all those configuration sticky bits. That'd look much more sensible to me.

That does sound like a great idea. I think some of our customers are probably doing that already that.

Dear Pavel,

Quoted 12 lines · In message <20150525123750.GD9943@amd> you wrote:

Quoted 11 lines

+ ** All global variables that are explicitly initialized (including          **
+ ** explicitly initialized to zero), are only initialized once, during       **
+ ** configuration time, and not again on reset.  This means that they        **
+ ** preserve their current contents across resets, which is needed for some  **
+ ** special cases involving communication with external modules.  In         **
+ ** addition, this avoids paying the price to have the memory initialized,   **

+ ** even for zeroed data, provided it is explicitly set to zero in the code, **
+ ** and doesn't rely on implicit initialization. **
+ ****************************************************************************** +

Quoted 2 lines

Is this sane thing to do? How does it work for variables in other sources?

My concern is if this is actually true (and I asked this before, in an
earlier round ov reviews). I cannot make heads or tails of this
comment, as I don't understand what "configuration time" and "reset" are supposed to mean in U-Boot context. In my understanding, after a reset the memory content is uninitialized, i. e. random, and thus MUST always be properly initialized.

From: Dinh Nguyen <[email protected]>

Enable the Altera SDRAM driver for the SoCFPGA platform.

Signed-off-by Dinh Nguyen <[email protected]>