[U-Boot] [PATCH] mtd: nand: denali_dt: Add reset support

Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com --- drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res; + struct reset_ctl reset_ctl; int ret;
data = (void *)dev_get_driver_data(dev); @@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
+ ret = reset_get_by_index(dev, 0, &reset_ctl); + if (!ret) { + reset_assert(&reset_ctl); + udelay(2); + reset_deassert(&reset_ctl); + } + return denali_init(denali); }

Hi Marek,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
U-Boot SPL 2018.09-rc2-00106-g5f0d7e5-dirty (Aug 24 2018 - 22:00:33 +0900) Trying to boot from NOR
U-Boot 2018.09-rc2-00106-g5f0d7e5-dirty (Aug 24 2018 - 22:00:33 +0900)
SoC: LD4 (model 1, revision 3) Model: UniPhier LD4 Reference Board DRAM: 512 MiB SC: Micro Support Card (CPLD version 3.6) NAND: nand_base: timeout while waiting for chip to become ready

On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
Hi Marek,
Hi,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?

On 08/24/2018 03:10 PM, Marek Vasut wrote:
On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
Hi Marek,
Hi,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
Did you figure something out ?

2018-09-05 17:31 GMT+09:00 Marek Vasut marek.vasut@gmail.com:
On 08/24/2018 03:10 PM, Marek Vasut wrote:
On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
Hi Marek,
Hi,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
I do not think so.
The reset sequence of Denali is not so simple as you may think because the HW sequencer runs after the reset de-assertion. It includes some SoC-dependent parts.
Did you figure something out ?
Just testing one of my boards.
It booted by adding mdelay() after reset_deassert().
reset_assert(&reset_ctl); udelay(2); reset_deassert(&reset_ctl); mdelay(1); /* Why is this long delay required? */
I will read HW docs more, and talk to HW engineers to figure out the right solution.

On 09/06/2018 03:46 AM, Masahiro Yamada wrote:
2018-09-05 17:31 GMT+09:00 Marek Vasut marek.vasut@gmail.com:
On 08/24/2018 03:10 PM, Marek Vasut wrote:
On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
Hi Marek,
Hi,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
I do not think so.
The reset sequence of Denali is not so simple as you may think because the HW sequencer runs after the reset de-assertion. It includes some SoC-dependent parts.
Did you figure something out ?
Just testing one of my boards.
It booted by adding mdelay() after reset_deassert().
reset_assert(&reset_ctl); udelay(2); reset_deassert(&reset_ctl); mdelay(1); /* Why is this long delay required? */
It works right away after ungating the reset on my board.
I will read HW docs more, and talk to HW engineers to figure out the right solution.
OK

Hi Marek,
2018-09-06 17:02 GMT+09:00 Marek Vasut marek.vasut@gmail.com:
On 09/06/2018 03:46 AM, Masahiro Yamada wrote:
2018-09-05 17:31 GMT+09:00 Marek Vasut marek.vasut@gmail.com:
On 08/24/2018 03:10 PM, Marek Vasut wrote:
On 08/24/2018 03:05 PM, Masahiro Yamada wrote:
Hi Marek,
Hi,
2018-08-21 22:57 GMT+09:00 Marek Vasut marex@denx.de:
Add optional reset support into the Denali NAND driver. In case there is a valid reset entry in the DT, the reset gets deasserted before the NAND controller gets used.
Signed-off-by: Marek Vasut marex@denx.de Cc: Masahiro Yamada yamada.masahiro@socionext.com
drivers/mtd/nand/denali_dt.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c index 65a7797f0f..6fcd7d3843 100644 --- a/drivers/mtd/nand/denali_dt.c +++ b/drivers/mtd/nand/denali_dt.c @@ -9,6 +9,7 @@ #include <linux/io.h> #include <linux/ioport.h> #include <linux/printk.h> +#include <reset.h>
#include "denali.h"
@@ -64,6 +65,7 @@ static int denali_dt_probe(struct udevice *dev) const struct denali_dt_data *data; struct clk clk; struct resource res;
struct reset_ctl reset_ctl; int ret; data = (void *)dev_get_driver_data(dev);
@@ -97,6 +99,13 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = clk_get_rate(&clk);
ret = reset_get_by_index(dev, 0, &reset_ctl);
if (!ret) {
reset_assert(&reset_ctl);
udelay(2);
reset_deassert(&reset_ctl);
}
return denali_init(denali);
}
I was testing this patch today because my SoC also has a reset line for NAND.
This patch looks trivial enough, but if the NAND is reset here, my board fails to boot with "nand_base: timeout while waiting for chip to become ready"
I do not know why. Please give me more time to figure out what is going on in my SoC.
Sure. Maybe you need to un-reset more stuff or the reset polarity is wrong ?
I do not think so.
The reset sequence of Denali is not so simple as you may think because the HW sequencer runs after the reset de-assertion. It includes some SoC-dependent parts.
Did you figure something out ?
Just testing one of my boards.
It booted by adding mdelay() after reset_deassert().
reset_assert(&reset_ctl); udelay(2); reset_deassert(&reset_ctl); mdelay(1); /* Why is this long delay required? */
It works right away after ungating the reset on my board.
With my further tests, it typically takes 200 usec for the chip identification sequence after the reset de-assertion.
The number is for my UniPhier SoC family.
This part is SoC-dependent, so the situation is probably different for SOCFPGA.
I'd like to suggest the following sequence.
reset_assert(&reset_ctl); udelay(1); reset_deassert(&reset_ctl); udelay(200);
Is this OK with you?
The IP datasheet says that the reset lines should be kept 10 clock cycles. I think udelay(1) is good enough for reset assertion.
BTW, are you applying this patch to your tree?
Or, do you want me to pick this up?
I will read HW docs more, and talk to HW engineers to figure out the right solution.
OK
participants (3)
-
Marek Vasut
-
Marek Vasut
-
Masahiro Yamada