[PATCH 0/3] omap: hwmod: add default reset handling support

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I'll post this series once again after performing these tests.

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

-- 
1.7.9.5

From: Paul Walmsley <paul@pwsan.com>

Many of the IP blocks with PRM hardreset lines are processor IP blocks
and need special reset handling to ensure that WFI/HLT-like
instructions are executed after reset. (This special handling ensures that
the IP blocks' bus initiator interfaces indicate that they are in standby
to the PRCM - thus allowing power management for the rest of the chip to
work correctly.)
Use HWMOD_CUSTOM_HARDRESET flags in the hwmod data for IP blocks that
require special reset handling.

Signed-off-by: Kishon Vijay Abraham I <redacted>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 8 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 65b1647..2a7e5da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c

@@ -59,6 +59,7 @@ static struct omap_hwmod omap2420_iva_hwmod = {
 	.clkdm_name	= "iva1_clkdm",
 	.rst_lines	= omap2420_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2420_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva1_ifck",
 };
 

@@ -78,6 +79,7 @@ static struct omap_hwmod omap2420_dsp_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap2420_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2420_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dsp_fck",
 };
 

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 79127b3..7ec77ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c

@@ -55,6 +55,7 @@ static struct omap_hwmod omap2430_iva_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap2430_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2430_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dsp_fck",
 };
 

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b..d8b701a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c

@@ -161,6 +161,7 @@ struct omap_hwmod am33xx_pruss_hwmod = {
 	},
 	.rst_lines	= am33xx_pruss_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_pruss_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /* gfx */

@@ -185,6 +186,7 @@ struct omap_hwmod am33xx_gfx_hwmod = {
 	},
 	.rst_lines	= am33xx_gfx_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_gfx_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index cc0791d..f843af6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c

@@ -86,6 +86,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	},
 	.rst_lines	= am33xx_wkup_m3_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_wkup_m3_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0a98532..544c53d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c

@@ -120,6 +120,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
 	.clkdm_name	= "iva2_clkdm",
 	.rst_lines	= omap3xxx_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva2_ck",
 	.prcm = {
 		.omap2 = {

@@ -2071,6 +2072,7 @@ static struct omap_hwmod omap3xxx_sad2d_hwmod = {
 	.name		= "sad2d",
 	.rst_lines	= omap3xxx_sad2d_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_sad2d_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "sad2d_ick",
 	.prcm		= {
 		.omap2 = {

@@ -2993,6 +2995,7 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
 	.clkdm_name	= "iva2_clkdm",
 	.rst_lines	= omap3xxx_mmu_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_mmu_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva2_ck",
 	.prcm = {
 		.omap2 = {

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..72346f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c

@@ -73,6 +73,7 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
 	},
 	.rst_lines	= am33xx_wkup_m3_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_wkup_m3_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 static struct omap_hwmod am43xx_control_hwmod = {

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dad871a..b38aad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c

@@ -544,6 +544,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.clkdm_name	= "tesla_clkdm",
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m4x2_ck",
 	.prcm = {
 		.omap4 = {

@@ -1424,6 +1425,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
 	.clkdm_name	= "ducati_clkdm",
 	.rst_lines	= omap44xx_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "ducati_clk_mux_ck",
 	.prcm = {
 		.omap4 = {

@@ -1508,6 +1510,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
 	.clkdm_name	= "ivahd_clkdm",
 	.rst_lines	= omap44xx_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m5x2_ck",
 	.prcm = {
 		.omap4 = {

@@ -2106,6 +2109,7 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
 	.clkdm_name	= "ducati_clkdm",
 	.rst_lines	= omap44xx_mmu_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_mmu_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "ducati_clk_mux_ck",
 	.prcm = {
 		.omap4 = {

@@ -2138,6 +2142,7 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
 	.clkdm_name	= "tesla_clkdm",
 	.rst_lines	= omap44xx_mmu_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_mmu_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m4x2_ck",
 	.prcm = {
 		.omap4 = {

@@ -2299,6 +2304,7 @@ static struct omap_hwmod omap44xx_prm_hwmod = {
 	.class		= &omap44xx_prcm_hwmod_class,
 	.rst_lines	= omap44xx_prm_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_prm_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 8cdfd9b..b1d5433 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c

@@ -1388,6 +1388,7 @@ static struct omap_hwmod omap54xx_mmu_dsp_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap54xx_mmu_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_mmu_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_h11x2_ck",
 	.prcm = {
 		.omap4 = {

@@ -1410,6 +1411,7 @@ static struct omap_hwmod omap54xx_mmu_ipu_hwmod = {
 	.clkdm_name	= "ipu_clkdm",
 	.rst_lines	= omap54xx_mmu_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_mmu_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_core_h22x2_ck",
 	.prcm = {
 		.omap4 = {

-- 
1.7.9.5

From: Paul Walmsley <paul@pwsan.com>

Many of the IP blocks with PRM hardreset lines are processor IP blocks
and need special reset handling to ensure that WFI/HLT-like
instructions are executed after reset. Introduce a new hwmod flag
_HWMOD_CUSTOM_HARDRESET_ to indicate if the IP block requires
special reset handling.

Signed-off-by: Kishon Vijay Abraham I <redacted>
---
 arch/arm/mach-omap2/omap_hwmod.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 76bce11..4198829 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h

@@ -525,6 +525,17 @@ struct omap_hwmod_omap4_prcm {
  *     or idled.
  * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
  *     operate and they need to be handled at the same time as the main_clk.
+ * HWMOD_CUSTOM_HARDRESET: By default, if a hwmod has PRCM hardreset
+ *     lines associated with it (i.e., a populated .rst_lines field in
+ *     the hwmod), the hwmod code will assert the hardreset lines when
+ *     the IP block is initially reset, deassert the hardreset lines
+ *     in _enable(), and reassert them in _shutdown().  If this flag
+ *     is set, the hwmod code will not deassert the hardreset lines in
+ *     _enable(), leaving this responsibility to the driver code.  This flag may
+ *     be needed for processor IP blocks that must be put into a WFI/HLT
+ *     state after reset is deasserted, lest the processor leave its MSTANDBY
+ *     signal deasserted, thus blocking the chip from entering a system-wide
+ *     low power state.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)

@@ -541,6 +552,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_SWSUP_SIDLE_ACT			(1 << 12)
 #define HWMOD_RECONFIG_IO_CHAIN			(1 << 13)
 #define HWMOD_OPT_CLKS_NEEDED			(1 << 14)
+#define HWMOD_CUSTOM_HARDRESET			(1 << 15)
 
 /*
  * omap_hwmod._int_flags definitions

-- 
1.7.9.5

From: Paul Walmsley <paul@pwsan.com>

Certain devices (like PCIe in DRA7xx) require default reset
handling where the reset line should be asserted and then
de-asserted. Other devices require special reset handling
and is indicated using HWMOD_CUSTOM_HARDRESET.
Add default reset handling here where the reset line is
asserted in _reset and deasserted in _enable.

Signed-off-by: Kishon Vijay Abraham I <redacted>
---
 arch/arm/mach-omap2/omap_hwmod.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e9f65fe..ab66dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c

@@ -2077,7 +2077,7 @@ static int _enable_preprogram(struct omap_hwmod *oh)
  */
 static int _enable(struct omap_hwmod *oh)
 {
-	int r;
+	int r, i;
 	int hwsup = 0;
 
 	pr_debug("omap_hwmod: %s: enabling\n", oh->name);

@@ -2109,17 +2109,23 @@ static int _enable(struct omap_hwmod *oh)
 	}
 
 	/*
-	 * If an IP block contains HW reset lines and all of them are
-	 * asserted, we let integration code associated with that
-	 * block handle the enable.  We've received very little
+	 * If an IP block contains HW reset lines, all of them are
+	 * asserted, and the IP block is marked as requiring a custom
+	 * hardreset handler, we let integration code associated with
+	 * that block handle the enable.  We've received very little
 	 * information on what those driver authors need, and until
 	 * detailed information is provided and the driver code is
 	 * posted to the public lists, this is probably the best we
 	 * can do.
 	 */
-	if (_are_all_hardreset_lines_asserted(oh))
+	if ((oh->flags & HWMOD_CUSTOM_HARDRESET) &&
+	    _are_all_hardreset_lines_asserted(oh))
 		return 0;
 
+	/* If the IP block is an initiator, release it from hardreset */
+	for (i = 0; i < oh->rst_lines_cnt; i++)
+		_deassert_hardreset(oh, oh->rst_lines[i].name);
+
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
 			((oh->_state == _HWMOD_STATE_IDLE) &&

-- 
1.7.9.5

Hi Kishon,

* Kishon Vijay Abraham I [off-list ref] [160208 03:13]:

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I'll post this series once again after performing these tests.

Do we also still need to patch something in the pcie driver too
or can all that be left out now?

Regards,

Tony

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

-- 
1.7.9.5

Hi Tony,

On Tuesday 09 February 2016 02:14 AM, Tony Lindgren wrote:

Hi Kishon,

* Kishon Vijay Abraham I [off-list ref] [160208 03:13]:

quoted

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I'll post this series once again after performing these tests.

Do we also still need to patch something in the pcie driver too
or can all that be left out now?

With this series changes in PCIe driver is not required at all.

Thanks
Kishon

Regards,

Tony

quoted

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

-- 
1.7.9.5

* Kishon Vijay Abraham I [off-list ref] [160208 21:14]:

Hi Tony,

On Tuesday 09 February 2016 02:14 AM, Tony Lindgren wrote:

quoted

Hi Kishon,

* Kishon Vijay Abraham I [off-list ref] [160208 03:13]:

quoted

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I'll post this series once again after performing these tests.

Do we also still need to patch something in the pcie driver too
or can all that be left out now?

With this series changes in PCIe driver is not required at all.

OK good to hear.

Thanks,

Tony

On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I won't be able to test this week, and have requested Dave to check on
wkup_m3_rproc driver atleast. I see one potential issue (see my commment
on the other thread), but can confirm that only after testing.

Have you tested multiple probe/removal sequences? Can you check the
return status on the _hardreset_deassert call with your PCIe driver,
believe even that one would return an error on multiple probes.

regards
Suman

I'll post this series once again after performing these tests.

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

Hi,

On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:

On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:

quoted

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I won't be able to test this week, and have requested Dave to check on
wkup_m3_rproc driver atleast. I see one potential issue (see my commment
on the other thread), but can confirm that only after testing.

Have you tested multiple probe/removal sequences? Can you check the
return status on the _hardreset_deassert call with your PCIe driver,
believe even that one would return an error on multiple probes.

hmm.. the PCIe driver is built-in and can't be made as module because of other
issues in PCIe core. But looks like the first deassert succeeded since I didn't
observe the boot hang because of PCIe.

Thanks
Kishon

regards
Suman

quoted

I'll post this series once again after performing these tests.

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

On 02/08/2016 11:17 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:

quoted

On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:

quoted

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I won't be able to test this week, and have requested Dave to check on
wkup_m3_rproc driver atleast. I see one potential issue (see my commment
on the other thread), but can confirm that only after testing.

Have you tested multiple probe/removal sequences? Can you check the
return status on the _hardreset_deassert call with your PCIe driver,
believe even that one would return an error on multiple probes.

hmm.. the PCIe driver is built-in and can't be made as module because of other
issues in PCIe core. But looks like the first deassert succeeded since I didn't
observe the boot hang because of PCIe.

You can try unbind and bind through sysfs, it should result in a remove
and probe even if your driver is built-in.

regards
Suman

quoted

quoted

I'll post this series once again after performing these tests.

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

Hi,
On 02/09/2016 11:44 AM, Suman Anna wrote:

On 02/08/2016 11:17 PM, Kishon Vijay Abraham I wrote:

quoted

Hi,

On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:

quoted

On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:

quoted

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I won't be able to test this week, and have requested Dave to check on
wkup_m3_rproc driver atleast. I see one potential issue (see my commment
on the other thread), but can confirm that only after testing.

Have you tested multiple probe/removal sequences? Can you check the
return status on the _hardreset_deassert call with your PCIe driver,
believe even that one would return an error on multiple probes.

hmm.. the PCIe driver is built-in and can't be made as module because of other
issues in PCIe core. But looks like the first deassert succeeded since I didn't
observe the boot hang because of PCIe.

You can try unbind and bind through sysfs, it should result in a remove
and probe even if your driver is built-in.

Sorry got held up by the discussion here [1], that regression affects 
rmmod/re-insmod of wkup_m3_rproc as well. If I revert the guilty patch 
5de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind") and apply these three 
patches, on initial probe of the wkup_m3_rproc and wkup_m3_ipc drivers 
in v4.5-rc3 I see:

[   15.593460] omap_hwmod: wkup_m3: _wait_target_disable failed

Which is triggered by the reset of the wkup_m3 from the wkup_m3_ipc 
driver when booting the wkup_m3_rproc. Flow is:

1. wkup_m3_rproc probes and calls pm_runtime_get_sync, which calls hwmod 
_enable but bails out because _are_all_hardreset_lines_asserted(oh) 
causes it to return 0.

2. wkup_m3_ipc probes and calls rproc_boot, which triggers 
omap_device_deassert_hardreset in order to let the wkup_m3 start.

It is inside the omap_device_deassert_hardreset ( and inside that, 
omap_hwmod_deassert_hardreset) where I end up with the error message, 
but after that rmmod/insmod of the module over and over again shows no 
additional error messages (at least with the above mentioned PM patch 
reverted).

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg477160.html

regards
Suman

quoted

quoted

quoted

I'll post this series once again after performing these tests.

Paul Walmsley (3):
   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
     handling
   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
     handling
   ARM: OMAP2+: hwmod: Add default reset handling

  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
  10 files changed, 41 insertions(+), 5 deletions(-)

On Tue, 9 Feb 2016, Dave Gerlach wrote:

Sorry got held up by the discussion here [1], that regression affects
rmmod/re-insmod of wkup_m3_rproc as well. If I revert the guilty patch
5de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind") and apply these three patches, on
initial probe of the wkup_m3_rproc and wkup_m3_ipc drivers in v4.5-rc3 I see:

[   15.593460] omap_hwmod: wkup_m3: _wait_target_disable failed

Which is triggered by the reset of the wkup_m3 from the wkup_m3_ipc driver
when booting the wkup_m3_rproc. Flow is:

1. wkup_m3_rproc probes and calls pm_runtime_get_sync, which calls hwmod
_enable but bails out because _are_all_hardreset_lines_asserted(oh) causes it
to return 0.

2. wkup_m3_ipc probes and calls rproc_boot, which triggers
omap_device_deassert_hardreset in order to let the wkup_m3 start.

The patches that Kishon posted shouldn't change the existing hardreset 
behavior for any IP block with HWMOD_CUSTOM_HARDRESET marked.  If the
behavior changes before and after that patch set, something isn't right.

It is inside the omap_device_deassert_hardreset ( and inside that,
omap_hwmod_deassert_hardreset) where I end up with the error message, but
after that rmmod/insmod of the module over and over again shows no additional
error messages (at least with the above mentioned PM patch reverted).

I no longer recall why we had the _are_all_hardreset_lines_asserted(oh) 
test in place.  But we might be able to drop it now that we have the 
HWMOD_CUSTOM_HARDRESET flag.
 

- Paul