diff mbox series

[5/6] clk: ti: am33xx: drop idlest polling from gfx clkctrl clock

Message ID 1554365467-1325-6-git-send-email-t-kristo@ti.com (mailing list archive)
State New, archived
Headers show
Series clk: ti: a few OMAP clock fixes | expand

Commit Message

Tero Kristo April 4, 2019, 8:11 a.m. UTC 
From: Eric Ruei <e-ruei1@ti.com>

The GFX modules on AM33xx SoCs have a hardreset line and are controlled
by a GFX reset line. Any clkctrl enable/disable operations cannot be
checked for module enabled/disabled status independent of the reset
operation, and this causes some unwanted timeouts in the kernel and
unbalanced states for the GFX clocks. These details should be handled
by the driver integration code itself.

Signed-off-by: Eric Ruei <e-ruei1@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 drivers/clk/ti/clk-33xx-compat.c | 2 +-
 drivers/clk/ti/clk-33xx.c        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Tony Lindgren April 4, 2019, 2:06 p.m. UTC | #1 
Hi,

* Tero Kristo <t-kristo@ti.com> [190404 08:12]:
> From: Eric Ruei <e-ruei1@ti.com>
> 
> The GFX modules on AM33xx SoCs have a hardreset line and are controlled
> by a GFX reset line. Any clkctrl enable/disable operations cannot be
> checked for module enabled/disabled status independent of the reset
> operation, and this causes some unwanted timeouts in the kernel and
> unbalanced states for the GFX clocks. These details should be handled
> by the driver integration code itself.

These last two patches should no longer be needed with ti-sysc.
Well, at least based on testing with the earlier reset-simple driver
patch and a test for sgx register access on am335x.

On init we deassert rstctrl if configured and in reset, then enable
clocks, and read the module revision. And the module is ready for child
device driver(s) to probe, and do what they want with the rstctrl via a
reset driver. If no child device driver(s) are configured, ti-sysc will
just put the module rstctrl back to reset using reset driver.

Regards,

Tony
Tero Kristo April 8, 2019, 5:45 a.m. UTC | #2 
On 04/04/2019 17:06, Tony Lindgren wrote:
> Hi,
> 
> * Tero Kristo <t-kristo@ti.com> [190404 08:12]:
>> From: Eric Ruei <e-ruei1@ti.com>
>>
>> The GFX modules on AM33xx SoCs have a hardreset line and are controlled
>> by a GFX reset line. Any clkctrl enable/disable operations cannot be
>> checked for module enabled/disabled status independent of the reset
>> operation, and this causes some unwanted timeouts in the kernel and
>> unbalanced states for the GFX clocks. These details should be handled
>> by the driver integration code itself.
> 
> These last two patches should no longer be needed with ti-sysc.
> Well, at least based on testing with the earlier reset-simple driver
> patch and a test for sgx register access on am335x.
> 
> On init we deassert rstctrl if configured and in reset, then enable
> clocks, and read the module revision. And the module is ready for child
> device driver(s) to probe, and do what they want with the rstctrl via a
> reset driver. If no child device driver(s) are configured, ti-sysc will
> just put the module rstctrl back to reset using reset driver.

Ok good to know, lets drop these patches for now and re-consider once we 
can try out graphics with latest kernel... unfortunately it is not 
available upstream.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Stephen Boyd April 25, 2019, 5:51 p.m. UTC | #3 
Quoting Tero Kristo (2019-04-07 22:45:08)
> On 04/04/2019 17:06, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [190404 08:12]:
> >> From: Eric Ruei <e-ruei1@ti.com>
> >>
> >> The GFX modules on AM33xx SoCs have a hardreset line and are controlled
> >> by a GFX reset line. Any clkctrl enable/disable operations cannot be
> >> checked for module enabled/disabled status independent of the reset
> >> operation, and this causes some unwanted timeouts in the kernel and
> >> unbalanced states for the GFX clocks. These details should be handled
> >> by the driver integration code itself.
> > 
> > These last two patches should no longer be needed with ti-sysc.
> > Well, at least based on testing with the earlier reset-simple driver
> > patch and a test for sgx register access on am335x.
> > 
> > On init we deassert rstctrl if configured and in reset, then enable
> > clocks, and read the module revision. And the module is ready for child
> > device driver(s) to probe, and do what they want with the rstctrl via a
> > reset driver. If no child device driver(s) are configured, ti-sysc will
> > just put the module rstctrl back to reset using reset driver.
> 
> Ok good to know, lets drop these patches for now and re-consider once we 
> can try out graphics with latest kernel... unfortunately it is not 
> available upstream.

Sooooo drop the last two patches and I should pick up the first four?
Tony Lindgren April 25, 2019, 5:56 p.m. UTC | #4 
* Stephen Boyd <sboyd@kernel.org> [190425 17:51]:
> Quoting Tero Kristo (2019-04-07 22:45:08)
> > On 04/04/2019 17:06, Tony Lindgren wrote:
> > > * Tero Kristo <t-kristo@ti.com> [190404 08:12]:
> > >> From: Eric Ruei <e-ruei1@ti.com>
> > >>
> > >> The GFX modules on AM33xx SoCs have a hardreset line and are controlled
> > >> by a GFX reset line. Any clkctrl enable/disable operations cannot be
> > >> checked for module enabled/disabled status independent of the reset
> > >> operation, and this causes some unwanted timeouts in the kernel and
> > >> unbalanced states for the GFX clocks. These details should be handled
> > >> by the driver integration code itself.
> > > 
> > > These last two patches should no longer be needed with ti-sysc.
> > > Well, at least based on testing with the earlier reset-simple driver
> > > patch and a test for sgx register access on am335x.
> > > 
> > > On init we deassert rstctrl if configured and in reset, then enable
> > > clocks, and read the module revision. And the module is ready for child
> > > device driver(s) to probe, and do what they want with the rstctrl via a
> > > reset driver. If no child device driver(s) are configured, ti-sysc will
> > > just put the module rstctrl back to reset using reset driver.
> > 
> > Ok good to know, lets drop these patches for now and re-consider once we 
> > can try out graphics with latest kernel... unfortunately it is not 
> > available upstream.
> 
> Sooooo drop the last two patches and I should pick up the first four?

Yes please.

Regards,

Tony
diff mbox series

Patch

diff --git a/drivers/clk/ti/clk-33xx-compat.c b/drivers/clk/ti/clk-33xx-compat.c
index 3e07f12..d11fb42 100644
--- a/drivers/clk/ti/clk-33xx-compat.c
+++ b/drivers/clk/ti/clk-33xx-compat.c
@@ -181,7 +181,7 @@ 
 };
 
 static const struct omap_clkctrl_reg_data am3_gfx_l3_clkctrl_regs[] __initconst = {
-	{ AM3_GFX_CLKCTRL, NULL, CLKF_SW_SUP, "gfx_fck_div_ck" },
+	{ AM3_GFX_CLKCTRL, NULL, CLKF_SW_SUP | CLKF_NO_IDLEST, "gfx_fck_div_ck" },
 	{ 0 },
 };
 
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index a360d31..7436e0f 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -217,7 +217,7 @@ 
 };
 
 static const struct omap_clkctrl_reg_data am3_gfx_l3_clkctrl_regs[] __initconst = {
-	{ AM3_GFX_L3_GFX_CLKCTRL, NULL, CLKF_SW_SUP, "gfx_fck_div_ck" },
+	{ AM3_GFX_L3_GFX_CLKCTRL, NULL, CLKF_SW_SUP | CLKF_NO_IDLEST, "gfx_fck_div_ck" },
 	{ 0 },
 };