On Tue, 19 May 2020 at 10:53, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Wolfram, > > On Tue, May 19, 2020 at 10:46 AM Wolfram Sang > <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > Can't we put it before the custom clk_enable()? And then clean up > > > > further like this to have the main clock only controlled via RPM? > > > > > > I understand what you want to achieve, but to allow that to work we > > > need to consider the below things first. > > > > > > 1. If the driver is built with CONFIG_PM unset, then runtime PM > > > doesn't work and hence the clock won't be managed by a PM domain. > > > 2. If there is a platform configuration where a PM domain (genpd) > > > isn't going to be attached, then the clock needs to be managed locally > > > in the driver. > > > > Similar to what Geert responded, for Renesas SDHI both is always true > > AFAIU. Geert? > > For Renesas SDHI, both are always false ;-) > I.e. CONFIG_PM is always set, genpd is always attached. OK, thanks for clarifying. This means dev_pm_domain_start() is needed only for the SDHI renesas variants. But on the other hand, it doesn't hurt for the others (the uniphier-sd variant doesn't even use runtime PM as confirmed by Yamada-san). I don't have a strong opinion, but it looks like we can either apply $subject patch as is, or modify it to make dev_pm_domain_start() be called only for the SDHI renesas variants. What do you prefer? Kind regards Uffe
