Hi Ulf,
On Fri, May 15, 2020 at 4:05 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> If the tmio device is attached to a genpd (PM domain), that genpd may have
> ->start|stop() callback assigned to it. To make sure the device is
> accessible during ->probe(), genpd's ->start() callback must be invoked,
> which is currently managed by tmio_mmc_host_probe(). This is very likely to
> be too late for some cases, as registers may be read and written way before
> that.
>
> To fix this behaviour, let's drop the call to dev_pm_domain_start() from
> tmio_mmc_host_probe() - and let the tmio clients manage this instead.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
So this moves the call to dev_pm_domain_start(). No new calls are added.
If I get it right, dev_pm_domain_start() just calls into
genpd_dev_pm_start() through a function pointer, and starts the device
through the system-specific PM Domain handler. On R-Car SoCs, that
is pm_clk_resume(), i.e. enabling the module clock through the clock
domain.
I have two questions there:
1. What if the device is already started?
There seems to be no reference counting involved.
2. Who stops the device again?
I always thought the PM Domain was powered on (if still off), and the
device started, by calling pm_runtime_get_sync().
What am I missing?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
