On 23/11/2020 14:31, Ulf Hansson wrote: ... >>> Note that, if there is no device attached to the genpd, the >>> ->power_on() callback may not be invoked - unless there is a child >>> domain being powered on. >>> >>> From the genpd provider driver point of view - why do you need to >>> implement system suspend/resume callbacks at all? Do you have some >>> additional operations to run, besides those executed from the >>> ->power_on|off() callbacks? >> >> The provider in this case is an embedded controller, the BPMP, and it >> needs to be resumed [0] prior to calling the provider callbacks. I am >> wondering if any other providers have this requirement? > > It seems like it should be a rather common requirement for a genpd > provider - at least for those providers that need to run some > additional operations at system suspend/resume. > > I guess the reason for this problem is that the order of how the > devices end up in the dpm_list, doesn't fit well for your case. > Normally, a provider should be registered prior and the consumer, as > that would probably lead to that the provider becomes resumed first. Yes it does appear that way. The BPMP (genpd provider) is probed before the ACONNECT (consumer) but still the order in which they end up in is not what we want. > In any case, to make sure the order becomes correct, a device link > should be created between the genpd domain provider and the consumer > device. As a matter of fact, this is done "automagically" during boot > for DT based platforms, see of_link_property() in > drivers/of/property.c. > > Currently these device links are created with DL_FLAG_SYNC_STATE_ONLY, > unless the "fw_devlink" kernel command line specifies a different > option (on == DL_FLAG_AUTOPROBE_CONSUMER). I would try to play with > that and see how that turns out. OK, good to know. I will take a look at that. Thanks for the inputs. Jon -- nvpublic
