Subject: [PATCH 1/4] clk: rockchip: protect critical clocks from getting disabled

From: [email-masked] (Mike Turquette)
Date: Thu, 31 Jul 2014 17:30:25 -0700

Quoting Heiko St?bner (2014-07-31 16:29:34)
> Hi Mike,
> 
> Am Donnerstag, 31. Juli 2014, 15:45:23 schrieb Mike Turquette:
> > Quoting Heiko Stuebner (2014-07-29 12:12:05)
> > 
> > > The clock-tree contains clocks that should never get disabled
> > > automatically. One example are the base ACLKs, the base supplies for all
> > > peripherals.
> > > 
> > > Therefore add a structure similar to the sunxi clock-tree to protect these
> > > special clocks from being disabled.
> > > 
> > > Signed-off-by: Heiko Stuebner <[email-masked]>
> > > ---
> > > 
> > >  drivers/clk/rockchip/clk-rk3188.c |  7 +++++++
> > >  drivers/clk/rockchip/clk-rk3288.c |  7 +++++++
> > >  drivers/clk/rockchip/clk.c        | 13 +++++++++++++
> > >  drivers/clk/rockchip/clk.h        |  1 +
> > >  4 files changed, 28 insertions(+)
> > > 
> > > diff --git a/drivers/clk/rockchip/clk-rk3188.c
> > > b/drivers/clk/rockchip/clk-rk3188.c index a83a6d8..5aef277 100644
> > > --- a/drivers/clk/rockchip/clk-rk3188.c
> > > +++ b/drivers/clk/rockchip/clk-rk3188.c
> > > @@ -599,6 +599,11 @@ static struct rockchip_clk_branch
> > > rk3188_clk_branches[] __initdata = {> 
> > >         GATE(ACLK_GPS, "aclk_gps", "aclk_peri", 0, RK2928_CLKGATE_CON(8),
> > >         13, GFLAGS),>  
> > >  };
> > > 
> > > +static const char *rk3188_critical_clocks[] __initconst = {
> > > +       "aclk_cpu",
> > > +       "aclk_peri",
> > 
> > I'm not against the idea of critical clocks, but I want to verify that
> > there is no other driver out there that is a better fit for claiming
> > these clks via clk_get and enabling them the normal way via clk_enable?
> 
> In the clock hierarchy of Rockchip SoCs, both aclks listed here, are sources 
> for pclk and hclk, as well as sourcing some other peripheral gates further 
> below too. So from what I've seen from the clock diagrams, there is nothing 
> that would claim these clocks directly, and it wouldn't also make any sense to 
> let them get disabled as there will always be something using them (for 
> example the dram-controller).

Sounds good. Just out of curiosity, under what circumstances would you
want to gate them? Is there a use case for it?

Regards,
Mike

> Heiko