On Mon, Nov 23, 2020 at 6:57 AM Jon Hunter <jonathanh@xxxxxxxxxx> wrote: > > > 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. Ulf, thanks for adding me and pointing people to fw_devlink. > > > > 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, Let me know if you run into issues with fw_devlink. I can try to help you address them. If you hit issues, it's going to be one of these two cases below. Known issues with fw_devlink: 1. It doesn't like cycles in dependencies in DT (it does the right thing for some of them, but not all). 2. If a DT device node has a driver that "probes" it without using driver core/struct device, it blocks the probing of all its consumers. (1) is on my TODO list of things to fix (2) needs the driver to be fixed to not do this. -Saravana
