On Thu, Oct 20, 2022 at 02:22:47PM +0300, Dmitry Baryshkov wrote: > On 20/10/2022 14:08, Johan Hovold wrote: > > On Thu, Oct 20, 2022 at 01:31:18PM +0300, Dmitry Baryshkov wrote: > >> + res->clks[0].id = "aux"; > >> + res->clks[1].id = "iface"; > >> + res->clks[2].id = "master_bus"; > >> + res->clks[3].id = "slave_bus"; > >> > >> - res->slave_bus = devm_clk_get(dev, "slave_bus"); > >> - if (IS_ERR(res->slave_bus)) > >> - return PTR_ERR(res->slave_bus); > >> + ret = devm_clk_bulk_get(dev, ARRAY_SIZE(res->clks), res->clks); > >> + if (ret < 0) > >> + return ret; > > > > Are you sure there are no dependencies between these clocks and that > > they can be enabled and disabled in any order? > > The order is enforced by the bulk API. Forward to enable, backward to > disable. Right you are. (I had it mixed up with a different API which had no such guarantees and now I can't seem to remember which it was, maybe I dreamt it.) > > Are you also convinced that they will always be enabled and disabled > > together (e.g. not controlled individually during suspend)? > > From what I see downstream, yes. They separate host and pipe clocks, > but for each of these groups all clocks are disabled and enabled in > sequence. > > For the newer platforms the only exceptions are refgen (handled by the > PHY in our kernels) and ddrss_sf_tbu (only on some platforms), which is > not touched by these patches. Sounds good. Johan
