[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c7508360d19fd20d398a43b62fbc2d93.sboyd@kernel.org>
Date: Thu, 26 Oct 2023 14:29:44 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Sebastian Reichel <sebastian.reichel@...labora.com>,
zhangqing <zhangqing@...k-chips.com>
Cc: conor+dt@...nel.org, heiko@...ech.de, kever.yang@...k-chips.com,
krzysztof.kozlowski+dt@...aro.org, mturquette@...libre.com,
robh+dt@...nel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
huangtao@...k-chips.com, andy.yan@...k-chips.com
Subject: Re: [PATCH v4 0/4] rockchip: add GATE_LINK
Quoting zhangqing (2023-10-25 19:25:43)
>
> 在 2023/10/26 5:40, Stephen Boyd 写道:
> > Quoting Sebastian Reichel (2023-10-25 12:48:49)
> >> Hello Stephen,
> >>
> >> On Mon, Oct 23, 2023 at 06:47:17PM -0700, Stephen Boyd wrote:
> >>> Quoting Elaine Zhang (2023-10-18 00:01:40)
> >>>> Recent Rockchip SoCs have a new hardware block called Native Interface
> >>>> Unit (NIU), which gates clocks to devices behind them. These effectively
> >>>> need two parent clocks.
> >>>> Use GATE_LINK to handle this.
> >>> Why can't pm clks be used here? The qcom clk driver has been doing that
> >>> for some time now.
> >>>
> >>> $ git grep pm_clk_add -- drivers/clk/qcom/
> >> Maybe I'm mistaken, but as far as I can tell this is adding the
> >> dependency on controller level and only works because Qualcomm
> >> has multiple separate clock controllers. In the Rockchip design
> >> there is only one platform device.
> >>
> >> Note, that the original downstream code from Rockchip actually used
> >> pm_clk infrastructure by moving these clocks to separate platform
> >> devices. I changed this when upstreaming the code, since that leaks
> >> into DT and from DT point of view there should be only one clock
> >> controller.
> >>
> > Why can't the rockchip driver bind to a single device node and make
> > sub-devices for each clk domain and register clks for those? Maybe it
> > can use the auxiliary driver infrastructure to do that?
>
> Option 1:
>
> Use the current patch to adapt the GATE_LINK type upstream.
>
> The real function of GATE_LINK is implemented。
>
> Just to improve and adapt the existing features on upstream.
>
>
> Option 2:
>
> What we use on our internal branches are:
Does this require DT changes? If so, it's a non-starter. Why can't
auxiliary devices be used?
Powered by blists - more mailing lists