Hi, Sorry for late response.
On 11/24/2015 05:28 PM, Rafael J. Wysocki wrote: > On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote: >> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote: >>> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote: >>>> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote: >>>>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote: >>>>>> Hi Rafael, >>>>>> >>> [cut] >>> >>>>> So the operations that need to be taken care of are: >>>>> - Probe (suppliers need to be probed before consumers if the dependencies >>>>> are >>>>> known beforehand). >>>>> - System suspend/resume (suppliers need to be suspended after consumers >>>>> and >>>>> resumed before them) which may be asynchronous (so simple re-ordering >>>>> doesn't >>>>> help). >>>>> - Runtime PM (suppliers should not be suspended if the consumers are not >>>>> suspended). >>>> I though provider's frameworks are taking care of it already. For example >>>> clock provider cannot suspend until there are prepared/enabled clocks. >>>> Similar enabled regulators, phys should block provider from runtime pm >>>> suspending. >>>> >>>> Are there situations/frameworks which requires additional care? >>> Yes, there are, AFAICS. >>> >>> A somewhat extreme example of this is when an AML routine needed for power >>> management of one device uses something like a GPIO line or an I2C link >>> provided by another one. We don't even have a way to track that kind of >>> thing at the provider framework level and the only information we can get >>> from the platform firmware is "this device depends on that one". >>> >>> Plus, even if the frameworks track those things, when a device suspend is >>> requested, the question really is "Are there any devices that have to be >>> suspended before this one?" rather than "Are other devices using resources >>> provided by this one?". Of course, you may argue that answering the second >>> one will allow you to answer the first one too (that is based on the >>> assumption >>> that you can always track all cases of resource utilization which may not be >>> entirely realistic), but getting that answer in a non-racy way may be rather >>> expensive. >> In such extreme case the device itself can play a role of resource. >> But in my proposal I do not try to answer which devices/resource depends >> on which ones, we do not need such info. >> It is just matter of notifying direct consumers about change of availability >> of given resource, and this notification is necessary anyway if we want >> to support hot resource/drivers (un-)plugging. > Well, we've been supporting hotplug for quite a while without that ... > > You seem to be referring to situations in which individual resources may go > away and drivers are supposed to reconfigure themselves on the fly. > > This is not what the $subject proposal is about. Currently if you undbind some driver from the device and the driver is a provider with active consumers usually it results in crashes/oopses. So I wouldn't say that hot resources/drivers unplugging is supported. > >>>>> - System shutdown (shutdown callbacks should be executed for consumers >>>>> first). >>>>> - Driver unbind (a supplier driver cannot be unbound before any of its >>>>> consumer >>>>> drivers). >>>>> >>>>> In principle you can use resource tracking to figure out all of the >>>>> involved >>>>> dependencies, but that would require walking complicated data structures >>>>> unless >>>>> you add an intermediate "device dependency" layer which is going to be >>>>> analogous >>>>> to the one discussed here. >>>> It should be enough if provider notifies consumers that the resource >>>> will be unavailable. >>> To me, this isn't going in the right direction. You should be asking "Am I >>> allowed to suspend now?" instead of saying "I'm suspending and now you deal >>> with it" to somebody. Why is that so? Because the other end may simply be >>> unable to deal with the situation in the first place. >> No. It is just saying "I want to suspend now, please not use my resources". >> In such case consumer should unprepare clocks, disable regulators, etc. >> But if it is not able to do so it just ignores the request. Provider >> will know >> anyway that his resources are in use and will not suspend. > This goes beyond the runtime PM framework which is based on device reference > counting and for system suspend it's not practical at all, because one driver > refusing to suspend aborts the entire operation system-wide. Aren't current suspend callbacks designed that way? Documentation/power/devices.txt says clearly: "If any of these callbacks returns an error, the system won't enter the desired low-power state. Instead the PM core will unwind its actions by resuming all the devices that were suspended." > >>>>>>> My idea is to represent a supplier-consumer dependency between devices >>>>>>> (or >>>>>>> more precisely between device+driver combos) as a "link" object >>>>>>> containing >>>>>>> pointers to the devices in question, a list node for each of them and >>>>>>> some >>>>>>> additional information related to the management of those objects, ie. >>>>>>> something like: >>>>>>> >>>>>>> struct device_link { >>>>>>> struct device *supplier; >>>>>>> struct list_head supplier_node; >>>>>>> struct device *consumer; >>>>>>> struct list_head consumer_node; >>>>>>> <flags, status etc> >>>>>>> }; >>>>>>> >>>>>>> In general, there will be two lists of those things per device, one list >>>>>>> of links to consumers and one list of links to suppliers. >>>>>>> >>>>>>> In that picture, links will be created by calling, say: >>>>>>> >>>>>>> int device_add_link(struct device *me, struct device *my_supplier, >>>>>>> unsigned int flags); >>>>>>> >>>>>>> and they will be deleted by the driver core when not needed any more. >>>>>>> The >>>>>>> creation of a link should also cause dpm_list and the list used during >>>>>>> shutdown >>>>>>> to be reordered if needed. >>>>>>> >>>>>>> In principle, it seems usefult to consider two types of links, one >>>>>>> created >>>>>>> at device registration time (when registering the second device from >>>>>>> the linked >>>>>>> pair, whichever it is) and one created at probe time (of the consumer >>>>>>> device). >>>>>>> I'll refer to them as "permanent" and "probe-time" links, respectively. >>>>>>> >>>>>>> The permanent links (created at device registration time) will stay >>>>>>> around >>>>>>> until one of the linked devices is unregistered (at which time the >>>>>>> driver >>>>>>> core will drop the link along with the device going away). The >>>>>>> probe-time >>>>>>> ones will be dropped (automatically) at the consumer device driver >>>>>>> unbind time. >>>>>> What about permanent links in case provider is unregistered? Should they >>>>>> disappear? It will not make consumers happy. What if the provider will be >>>>>> re-registered. >>>>> If the device object is gone, it cannot be pointed to by any links (on >>>>> any end) >>>>> any more. That's just physically impossible. :-) >>>> So the link will disappear and the 'consumer' will have dependencies >>>> fulfilled. >>> That's why in my opinion the rule should be that all consumers are unbound >>> from >>> their drivers before the supplier is unbound from its driver. >> But the rule will not work with 'weak' dependencies. > No, it won't. Enough of them are actually hard, though, for this to be > a relevant case anyway. > > [cut] > >> Lets drop my impressions, as there is no specification to verify it. >> >> What about resources which are present in device node, but driver do >> not use for some reason? Only driver knows which ones it requires in >> the specific scenario. Real example: HDMI node can contain links >> to SPDIF/audio clocks but since kernel is compiled without audio it >> will not use them at all. How do driver core will know about it. > It won't know about then automatically. It needs to be told about > whether or not a dependency is there, either by a driver or by a bus type > or a framework of some sort And since the driver core works with device > objects in general, this is the "granularity" it can handle. > > [cut] > >> But there are cases devices can work without some resources. >> > Yes, there are. > >>> It may be a good idea to reprobe them then in case they can work without the >>> missing supplier too, or to put them into the deferred probe list in case >>> the >>> supplier appears again. All of that is sort of academic, though, unless we >>> have real use cases like that to deal with. >> Real hardware case(it is not correctly modeled in drivers): >> HDMI generates clock, which is used by Display Controller. >> Display Controller then generates new clock based on the 1st one. >> The latter is used by HDMI. >> This is real example from latest Exynos SoCs. >> How do you want to model these dependencies using devices? > I don't want to model them with devices at all and this is not the point here. > > The point (as I said once already) is to make it possible to tell the driver > core of a functional dependency between *devices* in which case it will take > that dependency into account automatically in several important situations, > so the drivers of those devices won't need to worry about their respective > ordering etc. > > You seem to be saying that this is not useful and quite honestly I'm not > really sure why. I just want to clarify behavior of the framework in different scenarios. Regards Andrzej > > Thanks, > Rafael > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/