From patchwork Thu Oct 20 10:21:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Szyprowski X-Patchwork-Id: 78473 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp700841qge; Thu, 20 Oct 2016 03:22:03 -0700 (PDT) X-Received: by 10.99.117.17 with SMTP id q17mr16616718pgc.177.1476958922981; Thu, 20 Oct 2016 03:22:02 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d76si41095587pga.220.2016.10.20.03.22.02; Thu, 20 Oct 2016 03:22:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756146AbcJTKWB (ORCPT + 14 others); Thu, 20 Oct 2016 06:22:01 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:36262 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039AbcJTKV7 (ORCPT ); Thu, 20 Oct 2016 06:21:59 -0400 Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OFC00BP0CSKVX10@mailout2.w1.samsung.com>; Thu, 20 Oct 2016 11:21:56 +0100 (BST) Received: from eusmges2.samsung.com (unknown [203.254.199.241]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20161020102155eucas1p1aa0a491b5a6dd2646dabfadbc15649a0~-Nk7zZygo0942609426eucas1p1I; Thu, 20 Oct 2016 10:21:55 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges2.samsung.com (EUCPMTA) with SMTP id 46.E3.02283.3CA98085; Thu, 20 Oct 2016 11:21:55 +0100 (BST) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20161020102154eucas1p12da13c6d9b9f842d3f49cb159920f8bc~-Nk7KIrp20950809508eucas1p1C; Thu, 20 Oct 2016 10:21:54 +0000 (GMT) X-AuditID: cbfec7f1-f79f46d0000008eb-94-58089ac34e0d Received: from eusync1.samsung.com ( [203.254.199.211]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 17.79.10494.E9A98085; Thu, 20 Oct 2016 11:21:19 +0100 (BST) Received: from [106.116.147.30] by eusync1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OFC00CYDCSHZS80@eusync1.samsung.com>; Thu, 20 Oct 2016 11:21:54 +0100 (BST) Subject: Re: [PATCH v5 0/5] Functional dependencies between devices To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Linux PM list , Greg Kroah-Hartman , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Lukas Wunner , Kevin Hilman , Ulf Hansson , "Luis R. Rodriguez" From: Marek Szyprowski Message-id: Date: Thu, 20 Oct 2016 12:21:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbv7u6Gs9v1pYNWxqCCJE0LupiIUeSN+tCL5YiiRl6c5Bub ivrJNDUVm+g0XQlqWqhbioqZKcks5xtrappgyiRtaviGFoo40l0Fv/3Oc/7nf/gfHhKjO4Qe ZGRMPKeKUUTJCAne0r1hPt2lI+VnejalTNHUNMGkv6knmJmmXwJmuO01wazmfUHMrM2TsfV2 YEzZWhHGDPQPCZn8TQvBvDAMEYzJEBbsxLZOVCG2sTabYH+OthPs5zK9iG0eycLZVxPriK1v HsHZ1cajbElWi/CG+J4kMJyLikzkVL5BjyTKmtIOFKfxTNLYv6FUtOKWg8QkUOfgX6ZOwLM7 WCbriRwkIWmqGsF43xzGF6sImoobhHsTWzXLAr7xFsHMD+vuiA3BG/szbEflQl2Cef0GscOu lDdUVY44rDDKgsGy5QPaaRCUH+Qs5DhEUioIFoxf8R3GqePQbe9yvLtR92FcO4rxmoOwXjjp 0Iip22AptTkYowLgtz1DyLMXNOkXHMuAmhOBMbNz24jcLo5AYyfGR7gMf98bduO4wLypWcTz YRguzMV51iBIy/DmuQSBeUHK8wXoMg3u7nKGgpaXGG8vheeZNC9hoX/LsGt5EUb1n0T8gd4J wDzQK8pHXrp9cXT7Iuj2RShHWC1y5RLU0RGc2t9HrYhWJ8RE+DyOjW5E25+q325aaUVLPQFG RJFI5iRVmkVyWqhIVCdHGxGQmMxVml1AymlpuCI5hVPFPlQlRHFqI/IkcdkhaXv59zCailDE c084Lo5T7XUFpNgjFRWcnCKuWT+WVhzobJsV3bylLY2VhxqxO55hufYM96vWK6kFi/gx2jk4 xfp0MLt4RZs0omlouKvVxgdKKp16zIvVpunzf1bX/Cqui8/mBffQIUZvpaCO1NUZ3GJb27Y0 SyXpcf1j1YXLtL9+zN36YFM+b2hSrjmF+KZ5nAjtk+FqpcLvFKZSK/4DBLr5+VADAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsVy+t/xy7rzZ3FEGKxezGgx9eETNovmxevZ LJ5ufsxkcXnXHDaLz71HGC1ePJe2eH5yL7PF3C9TmS3OnL7EajHh9wU2i761l9gsjq8Nd+Dx 2HF3CaPHplWdbB53ru1h89g/dw27x5ar7Swes+/+YPRYv+Uqi8fnTXIeM9q3sQZwRrnZZKQm pqQWKaTmJeenZOal2yqFhrjpWigp5CXmptoqRej6hgQpKZQl5pQCeUYGaMDBOcA9WEnfLsEt Y+XMvYwF/dIV/f/OMzYwfhTtYuTkkBAwkfi78gMThC0mceHeerYuRi4OIYEljBLXtv5mhHCe M0psfdDFCFIlLOAs8WrNTzYQW0RAW2LJoqvMEEXLmSQW9C5iBXGYBS4xS3R3v2IBqWITMJTo etsF1sErYCfx9tBRsDiLgKrEsX+HweKiAjES1589gqoRlPgx+R5YDadAsMSeXwfB7mMWMJP4 8vIwK4QtL7F5zVvmCYwCs5C0zEJSNgtJ2QJG5lWMIqmlxbnpucVGesWJucWleel6yfm5mxiB cbvt2M8tOxi73gUfYhTgYFTi4c04xx4hxJpYVlyZe4hRgoNZSYS3cxJHhBBvSmJlVWpRfnxR aU5q8SFGU6AnJjJLiSbnA1NKXkm8oYmhuaWhkbGFhbmRkZI479QPV8KFBNITS1KzU1MLUotg +pg4OKUaGBteLWB6sUBSo0Ihvjj70rL8zWq2Feyb7u94MUvm9GutzzGKXsc5fQI0vsede9rT XrXasP6z2A7xrqv7ru8NWW2TfKn6jBqr/bmG80o99Ym2SwqCLY69+fnFTW+hn0+IP7dzw9+f x14GnZjGF+g+6zDT+ty7a2Yw2rDU3sx6Ibt257LNW/v3b1ViKc5INNRiLipOBABYGLij8QIA AA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161020102154eucas1p12da13c6d9b9f842d3f49cb159920f8bc X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20161010125153eucas1p2b86325c046d3e0d0b6275abd000ea096 X-RootMTR: 20161010125153eucas1p2b86325c046d3e0d0b6275abd000ea096 References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <13957403.ZrB4mMbICz@vostro.rjw.lan> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Hi Rafael, On 2016-10-19 13:57, Rafael J. Wysocki wrote: > On Tue, Oct 18, 2016 at 12:46 PM, Marek Szyprowski > wrote: >> On 2016-10-10 14:36, Rafael J. Wysocki wrote: >>> [...] >>> >>> One more update after some conversations during LinuxCon Europe. >>> >>> The main point was to make it possible for device_link_add() to figure out >>> the >>> initial state of the link instead of expecting the caller to provide it >>> which >>> might not be reliable enough in general. >>> >>> In this version device_link_add() takes three arguments, the supplier and >>> consumer pointers and flags and it sets the correct initial state of the >>> link >>> automatically (unless invoked with the "stateless" flag, of course). The >>> cost >>> is one additional field in struct device (I moved all of the links-related >>> fields in struct device to a separate sub-structure while at it) to track >>> the "driver presence status" of the device (to be used by >>> device_link_add()). >>> >>> In addition to that, the links list walks in the core.c and dd.c code are >>> under the device links mutex now, so the iternal link spinlock is not >>> needed >>> any more and I have renamed symbols to distinguish between flags, link >>> states >>> and device "driver presence statuses". >>> >>> More information is there in the changelogs. >> Thanks for the update. This version is indeed easier to use and still works >> fine >> with my Exynos IOMMU runtime pm rework. You can keep my: >> >> Tested-by: Marek Szyprowski >> >> I will send updated version of my patchset soon. > Thanks for the testing, much appreciated! > > The series is in a new branch called "device-links-test" in my tree now: > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > device-links-test While working on integrating IOMMU deferred probing patches I found a bug, which has been introduced in v4 of device dependency patchset (v3 worked fine in this area, v5 also contains this bug). The following fixup is needed to properly create links with DL_FLAG_PM_RUNTIME flag set during consumer device probing: From: Marek Szyprowski Date: Thu, 20 Oct 2016 12:12:14 +0200 Subject: [PATCH] driver core: fix runtime pm state for DEVICE_LINK_CONSUMER_PROBE links If link is added during consumer probe with DL_FLAG_PM_RUNTIME flag set, the code will do additional pm_runtime_put() on the supplier after finishing consumer probing. This will break runtime pm operation for the supplier device. To solve this issue, enforce additional call to pm_runtime_get_sync() on the supplier device while creating such link. Signed-off-by: Marek Szyprowski --- drivers/base/core.c | 3 +++ 1 file changed, 3 insertions(+) * of dpm_list and the devices_kset list. -- 1.9.1 Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/base/core.c b/drivers/base/core.c index 48bc5a362f7d..d4cc285a1df7 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -217,6 +217,9 @@ struct device_link *device_link_add(struct device *consumer, } } + if (flags & DL_FLAG_PM_RUNTIME && status == DL_STATE_CONSUMER_PROBE) + pm_runtime_get_sync(supplier); + /* * Move the consumer and all of the devices depending on it to the end