Message-id: <565BF7CD.9000706@samsung.com>
Date:	Mon, 30 Nov 2015 08:16:29 +0100
From:	Andrzej Hajda <a.hajda@...sung.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Brown <broonie@...nel.og>, Rob Herring <robh@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Thierry Reding <treding@...dia.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [RFD] Functional dependencies between devices

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists