On Tue, 19 May 2020 at 11:15, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > 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? And no matter what solution, can always drop to manage the "main" clock from renesas_sdhi_clk_enable|disable() as it's managed by the PM domain. Although, then we need to call dev_pm_domain_start() prior renesas_sdhi_clk_enable() during ->probe()? Kind regards Uffe
