Re: [PATCH v2] clk: samsung: exynos5420: Keep top G3D clocks enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Sylwester Nawrocki (2019-12-19 02:05:04)
> On 12/16/19 14:14, Marek Szyprowski wrote:
> > In Exynos542x/5800 SoCs, the G3D leaf clocks are located in the G3D power
> > domain. This is similar to the other hardware modules and their power
> > domains. However there is one thing specific to G3D clocks hierarchy.
> > Unlike other hardware modules, the G3D clocks hierarchy doesn't have any
> > gate clock between the TOP part of the hierarchy and the part located in
> > the power domain and some SoC internal busses are sourced directly from
> > the TOP muxes. The consequence of this design if the fact that the TOP
> > part of the hierarchy has to be enabled permanently to ensure proper
> > operation of the SoC power related components (G3D power domain and
> > Exynos Power Management Unit for system suspend/resume).
> > 
> > This patch adds an explicit call to clk_prepare_enable() on the last MUX
> > in the TOP part of G3D clock hierarchy to keep it enabled permanently to
> > ensure that the internal busses get their clock regardless of the main
> > G3D clock enablement status.
> 
> > ---
> > diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> > index 3a991ca1ee36..c9e5a1fb6653 100644
> > --- a/drivers/clk/samsung/clk-exynos5420.c
> > +++ b/drivers/clk/samsung/clk-exynos5420.c
> 
> > @@ -1646,6 +1647,13 @@ static void __init exynos5x_clk_init(struct device_node *np,
> >                                    exynos5x_subcmus);
> >       }
> >  
> > +     /*
> > +      * Keep top part of G3D clock path enabled permanently to ensure
> > +      * that the internal busses get their clock regardless of the
> > +      * main G3D clock enablement status.
> > +      */
> > +     clk_prepare_enable(__clk_lookup("mout_sw_aclk_g3d"));
> > +
> >       samsung_clk_of_add_provider(np, ctx);
> >  }
> 
> It's a bit unfortunate we don't store that clock in the driver internally,
> which would let us avoid the __clk_lookup() call. I can't come up with any
> simple alternative though so let's apply it for now.

Yes it would be better to not use __clk_lookup(). I'll apply it for now
but please avoid it somehow in a future patch.





[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux