On Thu, 11 Jul 2024 at 03:04, Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Dmitry Baryshkov (2024-07-10 16:32:18) > > On Tue, 9 Jul 2024 at 01:30, Stephen Boyd <sboyd@xxxxxxxxxx> 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? No, we have to remain compatible with existing DT. It's not a problem of a single new platform, the issue has always been present there. > 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. Well... Technically yes, but this brings another pack of issues. There is no separate GMU driver, so we will likely have a chicken-and-egg problem, as probing of the GPU driver will also create the gpucc device which is further used by the GPU. -- With best wishes Dmitry
