| Message ID | 20191211054538.8283-1-yamada.masahiro@socionext.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | [v2,1/2] dt-binding: mtd: denali_dt: document reset property | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
On 12/11/19 6:45 AM, Masahiro Yamada wrote: [...] > diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c > index 8b779a899dcf..9a294c3f6ec8 100644 > --- a/drivers/mtd/nand/raw/denali_dt.c > +++ b/drivers/mtd/nand/raw/denali_dt.c > @@ -6,6 +6,7 @@ > */ > > #include <linux/clk.h> > +#include <linux/delay.h> > #include <linux/err.h> > #include <linux/io.h> > #include <linux/ioport.h> > @@ -14,6 +15,7 @@ > #include <linux/of.h> > #include <linux/of_device.h> > #include <linux/platform_device.h> > +#include <linux/reset.h> > > #include "denali.h" > > @@ -22,6 +24,8 @@ struct denali_dt { > struct clk *clk; /* core clock */ > struct clk *clk_x; /* bus interface clock */ > struct clk *clk_ecc; /* ECC circuit clock */ > + struct reset_control *rst; /* core reset */ > + struct reset_control *rst_reg; /* register reset */ > }; > > struct denali_dt_data { > @@ -151,6 +155,14 @@ static int denali_dt_probe(struct platform_device *pdev) > if (IS_ERR(dt->clk_ecc)) > return PTR_ERR(dt->clk_ecc); > > + dt->rst = devm_reset_control_get_optional_shared(dev, "nand"); > + if (IS_ERR(dt->rst)) > + return PTR_ERR(dt->rst); > + > + dt->rst_reg = devm_reset_control_get_optional_shared(dev, "reg"); > + if (IS_ERR(dt->rst_reg)) > + return PTR_ERR(dt->rst_reg); > + > ret = clk_prepare_enable(dt->clk); > if (ret) > return ret; > @@ -166,10 +178,30 @@ static int denali_dt_probe(struct platform_device *pdev) > denali->clk_rate = clk_get_rate(dt->clk); > denali->clk_x_rate = clk_get_rate(dt->clk_x); > > - ret = denali_init(denali); > + /* > + * Deassert the register reset, and the core reset in this order. > + * Deasserting the core reset while the register reset is asserted > + * will cause unpredictable behavior in the controller. > + */ > + ret = reset_control_deassert(dt->rst_reg); > if (ret) > goto out_disable_clk_ecc; > > + ret = reset_control_deassert(dt->rst); > + if (ret) > + goto out_assert_rst_reg; > + > + /* > + * When the reset is deasserted, the initialization sequence is kicked > + * (bootstrap process). The driver must wait until it finished. > + * Otherwise, it will result in unpredictable behavior. > + */ > + usleep_range(200, 1000); > + > + ret = denali_init(denali); > + if (ret) > + goto out_assert_rst; > + > for_each_child_of_node(dev->of_node, np) { > ret = denali_dt_chip_init(denali, np); > if (ret) { > @@ -184,6 +216,10 @@ static int denali_dt_probe(struct platform_device *pdev) > > out_remove_denali: > denali_remove(denali); > +out_assert_rst: > + reset_control_assert(dt->rst); > +out_assert_rst_reg: > + reset_control_assert(dt->rst_reg); Maybe you can use devm_add_action_or_reset() here , like in e.g. drivers/input/touchscreen/ili210x.c , to avoid this unwinding ? [...]
On Thu, Dec 12, 2019 at 10:05 AM Marek Vasut <marex@denx.de> wrote: > > On 12/11/19 6:45 AM, Masahiro Yamada wrote: > [...] > > diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c > > index 8b779a899dcf..9a294c3f6ec8 100644 > > --- a/drivers/mtd/nand/raw/denali_dt.c > > +++ b/drivers/mtd/nand/raw/denali_dt.c > > @@ -6,6 +6,7 @@ > > */ > > > > #include <linux/clk.h> > > +#include <linux/delay.h> > > #include <linux/err.h> > > #include <linux/io.h> > > #include <linux/ioport.h> > > @@ -14,6 +15,7 @@ > > #include <linux/of.h> > > #include <linux/of_device.h> > > #include <linux/platform_device.h> > > +#include <linux/reset.h> > > > > #include "denali.h" > > > > @@ -22,6 +24,8 @@ struct denali_dt { > > struct clk *clk; /* core clock */ > > struct clk *clk_x; /* bus interface clock */ > > struct clk *clk_ecc; /* ECC circuit clock */ > > + struct reset_control *rst; /* core reset */ > > + struct reset_control *rst_reg; /* register reset */ > > }; > > > > struct denali_dt_data { > > @@ -151,6 +155,14 @@ static int denali_dt_probe(struct platform_device *pdev) > > if (IS_ERR(dt->clk_ecc)) > > return PTR_ERR(dt->clk_ecc); > > > > + dt->rst = devm_reset_control_get_optional_shared(dev, "nand"); > > + if (IS_ERR(dt->rst)) > > + return PTR_ERR(dt->rst); > > + > > + dt->rst_reg = devm_reset_control_get_optional_shared(dev, "reg"); > > + if (IS_ERR(dt->rst_reg)) > > + return PTR_ERR(dt->rst_reg); > > + > > ret = clk_prepare_enable(dt->clk); > > if (ret) > > return ret; > > @@ -166,10 +178,30 @@ static int denali_dt_probe(struct platform_device *pdev) > > denali->clk_rate = clk_get_rate(dt->clk); > > denali->clk_x_rate = clk_get_rate(dt->clk_x); > > > > - ret = denali_init(denali); > > + /* > > + * Deassert the register reset, and the core reset in this order. > > + * Deasserting the core reset while the register reset is asserted > > + * will cause unpredictable behavior in the controller. > > + */ > > + ret = reset_control_deassert(dt->rst_reg); > > if (ret) > > goto out_disable_clk_ecc; > > > > + ret = reset_control_deassert(dt->rst); > > + if (ret) > > + goto out_assert_rst_reg; > > + > > + /* > > + * When the reset is deasserted, the initialization sequence is kicked > > + * (bootstrap process). The driver must wait until it finished. > > + * Otherwise, it will result in unpredictable behavior. > > + */ > > + usleep_range(200, 1000); > > + > > + ret = denali_init(denali); > > + if (ret) > > + goto out_assert_rst; > > + > > for_each_child_of_node(dev->of_node, np) { > > ret = denali_dt_chip_init(denali, np); > > if (ret) { > > @@ -184,6 +216,10 @@ static int denali_dt_probe(struct platform_device *pdev) > > > > out_remove_denali: > > denali_remove(denali); > > +out_assert_rst: > > + reset_control_assert(dt->rst); > > +out_assert_rst_reg: > > + reset_control_assert(dt->rst_reg); > > Maybe you can use devm_add_action_or_reset() here , like in e.g. > drivers/input/touchscreen/ili210x.c , to avoid this unwinding ? No. Drivers should be explicit about what and when to do about the hardware access. This comes down to a question about why Linux kernel does not have such APIs as: devm_clk_prepare_enable() devm_reset_control_deassert() devm_regulator_enable() In fact, I saw some people sending such patches in the past. Mark Brown clearly answered the question. https://lkml.org/lkml/2014/2/1/131 I really support his thinking. -- Best Regards Masahiro Yamada
On Wed, 11 Dec 2019 14:45:37 +0900, Masahiro Yamada wrote: > According to the Denali NAND Flash Memory Controller User's Guide, > this IP has two reset signals. > > rst_n: reset most of FFs in the controller core > reg_rst_n: reset all FFs in the register interface, and in the > initialization sequencer > > This commit specifies those reset signals. > > It is possible to control them separately from the IP point of view > although they might be often tied up together in actual SoC integration. > > At least for the upstream platforms, Altera/Intel SOCFPGA and Socionext > UniPhier, the reset controller seems to provide only 1-bit control for > the NAND controller. If it is the case, the resets property should > reference to the same phandles for "nand" and "reg" resets, like this: > > resets = <&nand_rst>, <&nand_rst>; > reset-names = "nand", "reg"; > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > Changes in v2: > - Split into two patches > > Documentation/devicetree/bindings/mtd/denali-nand.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > Acked-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt index b32aed1db46d..98916a84bbf6 100644 --- a/Documentation/devicetree/bindings/mtd/denali-nand.txt +++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt @@ -14,6 +14,11 @@ Required properties: interface clock, and the ECC circuit clock. - clock-names: should contain "nand", "nand_x", "ecc" +Optional properties: + - resets: may contain phandles to the controller core reset, the register + reset + - reset-names: may contain "nand", "reg" + Sub-nodes: Sub-nodes represent available NAND chips. @@ -46,6 +51,8 @@ nand: nand@ff900000 { reg-names = "nand_data", "denali_reg"; clocks = <&nand_clk>, <&nand_x_clk>, <&nand_ecc_clk>; clock-names = "nand", "nand_x", "ecc"; + resets = <&nand_rst>, <&nand_reg_rst>; + reset-names = "nand", "reg"; interrupts = <0 144 4>; nand@0 {
According to the Denali NAND Flash Memory Controller User's Guide, this IP has two reset signals. rst_n: reset most of FFs in the controller core reg_rst_n: reset all FFs in the register interface, and in the initialization sequencer This commit specifies those reset signals. It is possible to control them separately from the IP point of view although they might be often tied up together in actual SoC integration. At least for the upstream platforms, Altera/Intel SOCFPGA and Socionext UniPhier, the reset controller seems to provide only 1-bit control for the NAND controller. If it is the case, the resets property should reference to the same phandles for "nand" and "reg" resets, like this: resets = <&nand_rst>, <&nand_rst>; reset-names = "nand", "reg"; Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- Changes in v2: - Split into two patches Documentation/devicetree/bindings/mtd/denali-nand.txt | 7 +++++++ 1 file changed, 7 insertions(+)