[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9cb3f57ed4b41fb51600610a3a1c9437.sboyd@kernel.org>
Date: Wed, 10 Jul 2024 17:04:41 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>, Michael Turquette <mturquette@...libre.com>, Rob Clark <robdclark@...il.com>, linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org, freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] clk: qocm: add qcom_cc_map_norequest
Quoting Dmitry Baryshkov (2024-07-10 16:32:18)
> On Tue, 9 Jul 2024 at 01:30, Stephen Boyd <sboyd@...nel.org> wrote:
> >
> > Quoting Dmitry Baryshkov (2024-06-27 22:20:22)
> > > The GPU clock controllers use memory region that is a part of the GMU's
> > > memory region. Add qcom_cc_map_norequest() to be used by GPUCC, so that
> > > GPU driver can use devm_ioremap_resource for GMU resources.
> >
> > Why does GMU map the gpu clk controller? Does it use those registers? We
> > don't want to allow two different drivers to map the same region because
> > then they don't coordinate and write over things.
>
> It's not that GMU maps gpu CC separately. It looks more like gpucc is
> a part of the GMU address space. I think GMU manages some of the
> clocks or GDSCs directly.
>
I imagine GMU is a collection of stuff, so the register range is large
because it's basically a subsystem unto itself. Can the range in DT be
split up, or changed so that different devices within GMU are split out?
Or maybe the gpu clk controller can be made into a child of some GMU
node, where the GMU node has a driver that populates devices that match
drivers in different subsystems.
Powered by blists - more mailing lists