omap: hwmod: add default reset handling support

PATCH In review Kishon Vijay Abraham I 5 participants 12 messages Feb 8, 2016 – Feb 9, 2016

Subsystems (5)

Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP hwmod data +1 more subsystems

lore

Share & tools

lore

Kishon Vijay Abraham I

author

2016-02-08 11:12 UTC #0 lore raw

cover 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(-)

Signature · 1 line

1.7.9.5

Kishon Vijay Abraham I

author

2016-02-08 11:12 UTC #1 lore raw

PATCH 1/3 ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset handling

From: Paul Walmsley <[email protected]>

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 <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

arch/arm/mach-omap2/omap_hwmod.h +12 -0

index 76bce11..4198829 100644
@@ -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

Signature · 1 line

1.7.9.5

Kishon Vijay Abraham I

author

2016-02-08 11:12 UTC #2 lore raw

PATCH 2/3 ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset handling

In reply to Kishon Vijay Abraham I

From: Paul Walmsley <[email protected]>

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 <[email protected]>

---
 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(+)

arch/arm/mach-omap2/omap_hwmod_2420_data.c +2 -0

index 65b1647..2a7e5da 100644
@@ -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",
 };

arch/arm/mach-omap2/omap_hwmod_2430_data.c +1 -0

index 79127b3..7ec77ff 100644
@@ -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",
 };

arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +2 -0

index 907a452b..d8b701a 100644
@@ -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,
 };
 
 /*

arch/arm/mach-omap2/omap_hwmod_33xx_data.c +1 -0

index cc0791d..f843af6 100644
@@ -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,
 };
 
 /*

arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +3 -0

index 0a98532..544c53d 100644
@@ -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 = {

arch/arm/mach-omap2/omap_hwmod_43xx_data.c +1 -0

index e97a894..72346f0 100644
@@ -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 = {

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +6 -0

index dad871a..b38aad9 100644
@@ -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,
 };
 
 /*

arch/arm/mach-omap2/omap_hwmod_54xx_data.c +2 -0

index 8cdfd9b..b1d5433 100644
@@ -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 = {

Signature · 1 line

1.7.9.5

Kishon Vijay Abraham I

author

2016-02-08 11:12 UTC #3 lore raw

PATCH 3/3 ARM: OMAP2+: hwmod: Add default reset handling

In reply to Kishon Vijay Abraham I

From: Paul Walmsley <[email protected]>

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 <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

arch/arm/mach-omap2/omap_hwmod.c +11 -5

index e9f65fe..ab66dd9 100644
@@ -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) &&

Signature · 1 line

1.7.9.5

Tony Lindgren

maintainer

2016-02-08 20:44 UTC #4 lore raw

In reply to Kishon Vijay Abraham I

Hi Kishon,

Quoted 8 lines · Kishon Vijay Abraham I

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

Quoted 22 lines

 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(-)

Signature · 1 line

1.7.9.5

Kishon Vijay Abraham I

author

2016-02-09 05:13 UTC #5 lore raw

Hi Tony,

Quoted 6 lines · Tony Lindgren

Hi Kishon,
Quoted 3 lines · Kishon Vijay Abraham I
Add a new hwmod flag to indicate custom reset handling and use it for devices that require custom reset handling (like dsp, ipu, iva).

Quoted 8 lines

Quoted 5 lines
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

Quoted 28 lines

Regards,

Tony

Quoted 22 lines

 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(-)

Signature · 1 line

1.7.9.5

Tony Lindgren

maintainer

2016-02-09 15:58 UTC #6 lore raw

Quoted 13 lines · Kishon Vijay Abraham I

Hi Tony,
Quoted 10 lines · Tony Lindgren
Hi Kishon,
Quoted 7 lines · Kishon Vijay Abraham I
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?

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
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

Suman Anna

2016-02-08 21:07 UTC #7 lore raw

In reply to Kishon Vijay Abraham I

Quoted 6 lines · Kishon Vijay Abraham I

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

Quoted 22 lines

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

 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(-)

Kishon Vijay Abraham I

author

2016-02-09 05:17 UTC #8 lore raw

Hi,

Quoted 8 lines · Suman Anna

Quoted 6 lines · Kishon Vijay Abraham I
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?

Quoted 7 lines

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

Quoted 27 lines

regards
Suman

Quoted 22 lines

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

 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(-)

Suman Anna

2016-02-09 17:44 UTC #9 lore raw

Quoted 15 lines · Kishon Vijay Abraham I

Hi,
Quoted 12 lines · Suman Anna
Quoted 6 lines · Kishon Vijay Abraham I
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.

Quoted 7 lines

Quoted 3 lines
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 24 lines

Quoted 23 lines

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

 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(-)

Dave Gerlach

2016-02-09 20:19 UTC #10 lore raw

Hi,

Quoted 20 lines · Suman Anna

Quoted 19 lines · Kishon Vijay Abraham I
Hi,
Quoted 15 lines · Suman Anna
Quoted 6 lines · Kishon Vijay Abraham I
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.

Quoted 6 lines

Quoted 3 lines
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

Quoted 28 lines

regards
Suman
Quoted 24 lines
Quoted 24 lines
Quoted 23 lines
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(-)

Paul Walmsley

maintainer

2016-02-09 21:34 UTC #11 lore raw

Quoted 11 lines · Dave Gerlach

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:

Quoted 6 lines

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.

Quoted 4 lines

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