From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752769AbdBMMPg (ORCPT ); Mon, 13 Feb 2017 07:15:36 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:11602 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750975AbdBMMPd (ORCPT ); Mon, 13 Feb 2017 07:15:33 -0500 X-AuditID: cbfec7f1-f793f6d000007796-68-58a1a361ca81 Subject: Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM To: Ulf Hansson , Vinod Koul Cc: "Rafael J. Wysocki" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Lars-Peter Clausen , Arnd Bergmann , Inki Dae From: Marek Szyprowski Message-id: Date: Mon, 13 Feb 2017 13:15:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRzGe3fO2Y6rE6e56l9pwiKDQmtd4GRhBX44FUGh0Cihhh6meal2 mqVB2c1qpY2t0uy2mQ1aSTVXiS6LmW6ltpwXSmx+iBSz2UUirRy1nQV++/0v7/O8z8tLYrJG Yi6ZnX+A0+arcxViKf64ZdyboL5lUS0bOjaNmTC2SJiHFfcJ5u6lCYIx9htwxut9IGGqTTcJ xv6hh2A666+JmdHSF4ip8DaKmLZWH8G4a7YzQ2XP8PUU+/uXEbG3nEMi1m47K2b7epxitrb6 KFv92UWwju7TOFvmsCF21D5/a9QO6dpMLje7gNMuTd4tzap71ELsG15wqNufUoz8MXoURQK9 Eso7JpDAs+CN/75Yj6SkjL6NoPxHg0QoRhGMBwcwPSLDJwZqWKFvRfBzvEokFIMI3l21YiGp aHob9P7xiUMspzfDybbLYSWMvoRD3XUDERqIaSXoA/rwEkUng6f5adgBpxfCVw8bas+k06HU fhkTVmbAmMmPhziKToVhU1uYMToJBoKnCIHjoPZeAAt5AR2QwNuR9sitY8H+PIIp8LJji5A4 Gj65HRKBY6DTdA4X+AKC46eWCFyB4HWAEngNNLk7IlbTwfi4PCJJwZkSmbDCQr3ZFZHZAN0f LZE3HMSg66sVN6C4yklpKiclqJyUwIwwG5JzOj5Pw/HLE3l1Hq/L1yRm7M2zo3+/qjXo/laH vniSXIgmkWIaVVxiVskIdQFfmOdCQGIKOWW5blHJqEx1YRGn3btLq8vleBeaR+KK2ZTT3LVd RmvUB7gcjtvHaf9PRWTU3GKUfsUwNmu/b9NbzfQ9sctWfd943nERieZv7uzwJZVWpRyJH7M2 aOqkU1WLnIepG13Kov45OmlZDqMomRn78km8NHWKX3lntdEib/bwyQd5x4+RtGu13/oyg8o4 W0JTj6IXK8hoSAuuAyrtfXSCo31d94pX6Sc8I2djslwZO6+cUOB8llq5GNPy6r/W3wTeUQMA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsVy+t/xy7rJixdGGDSc1bb4O+kYu8XGGetZ LVZP/ctqMen+BBaL8+c3sFssmTyf1WLT42usFpd3zWGz+Nx7hNFixvl9TBZnTl9itTi+Ntzi Zd9+Fgdej9+/JjF6LN7zkslj06pONo871/aweWxeUu+x5M0hVo8tV9tZPPq2rGL0+LxJLoAz ys0mIzUxJbVIITUvOT8lMy/dVik0xE3XQkkhLzE31VYpQtc3JEhJoSwxpxTIMzJAAw7OAe7B Svp2CW4ZO7YeYy14rVxx9Z5LA+M9mS5GDg4JAROJZ2s9uhg5gUwxiQv31rN1MXJxCAksYZRY uaqPCcJ5zigx6+Z2VpAqYQF/iUkfIGwRAW+JljPT2KGKmCXu/j3LCOIwC0xnkXg/fQkTSBWb gKFE19suNhCbV8BO4sTRvcwgq1kEVCU+nABbLSoQI7G3/z4TRImgxI/J91hAbE6BYIkZWxeC 2cwCZhJfXh5mhbDlJTavecs8gVFgFpKWWUjKZiEpW8DIvIpRJLW0ODc9t9hIrzgxt7g0L10v OT93EyMwdrcd+7llB2PXu+BDjAIcjEo8vA1tCyKEWBPLiitzDzFKcDArifAunLswQog3JbGy KrUoP76oNCe1+BCjKdAPE5mlRJPzgWklryTe0MTQ3NLQyNjCwtzISEmcd+qHK+FCAumJJanZ qakFqUUwfUwcnFINjEpRC/XV5l4ovHGSXUtimq/UorCcuJ672+s1D7ap8Vx6u2TzHlmFuenG 3XddVnzb9vT6/O4J3w5Mk5YLEg43XrAsa96jm/H7bW84hb//s7zDNuDH77J7usLC5ibzUx1X /TCUUt7JGz8r17gls9CnYp8eT+JUu00//NrifdR9JQ9MqljWvnlLpxJLcUaioRZzUXEiAKIA JYbzAgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170213121528eucas1p22edb1c5e1f15145e9a0ca5598472613e 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: 20170209142309eucas1p2b1277d96139eafc0d1dcc14145600476 X-RootMTR: 20170209142309eucas1p2b1277d96139eafc0d1dcc14145600476 References: <1486650171-20598-1-git-send-email-m.szyprowski@samsung.com> <1486650171-20598-4-git-send-email-m.szyprowski@samsung.com> <20170210045004.GN19244@localhost> <20170213020340.GH2843@localhost> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ulf, On 2017-02-13 12:11, Ulf Hansson wrote: >>> If we could set up the device link already at device initialization, >>> it should also be possible to avoid getting -EPROBE_DEFER for dma >>> client drivers when requesting their dma channels. >> Well if we defer then driver will regiser with dmaengine after it is >> probed, so a client will either get a channel or not. IOW we won't get >> -EPROBE_DEFER. > I didn't quite get this. What do you mean by "if we defer..."? > > Defer into *what* and defer of *what*? Could you please elaborate. > > [...] > >>> Again, allow me to fill in. This issue exists for all ARM SoC which >>> has a dma controller residing in a PM domain. I think that is quite >>> many. >>> >>> Currently the only solution I have seen for this problem, but which I >>> really dislike. That is, each dma client driver requests/releases >>> their dma channel from their respective ->runtime_suspend|resume() >>> callbacks - then the dma driver can use the dma request/release hooks, >>> to do pm_runtime_get|put() which then becomes non-irq-safe. >> Yeah that is not the best way to do. But looking at it current one doesnt >> seem best fit either. >> >> So on seeing the device_link_add() I was thinking that this is some SoC >> dependent problem being solved whereas the problem statmement is non-atomic >> channel prepare. > You may be right. > > Although, I don't know of other examples, besides the runtime PM use > case, where non-atomic channel prepare/unprepare would make sense. Do > you? Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers would be also a nice present for the memory management subsystem if there is no real reason to drain atomic pools. >> As I said earlier, if we want to solve that problem a better idea is to >> actually split the prepare as we discussed in [1] >> >> This way we can get a non atomic descriptor allocate/prepare and release. >> Yes we need to redesign the APIs to solve this, but if you guys are up for >> it, I think we can do it and avoid any further round abouts :) > Adding/re-designing dma APIs is a viable option to solve the runtime PM case. > > Changes would be needed for all related dma client drivers as well, > although if that's what we need to do - let's do it. > > [...] > >>> So besides solving the irq-safe issue for dma driver, using the >>> device-links has additionally two advantages. I already mentioned the >>> -EPROBE_DEFER issue above. >>> >>> The second thing, is the runtime/system PM relations we get for free >>> by using the links. In other words, the dma driver/core don't need to >>> care about dealing with pm_runtime_get|put() as that would be managed >>> by the dma client driver. >> Yeah sorry took me a while to figure that out :), If we do a different API >> then dmaengine core can call pm_runtime_get|put() from non-atomic context. > Yes, it can and this works from runtime PM point of view. But the > following issues would remain unsolved. > > 1) > Dependencies between dma drivers and dma client drivers during system > PM. For example, a dma client driver needs the dma controller to be > operational (remain system resumed), until the dma client driver > itself becomes system suspended. > > The *only* currently available solution for this, is to try to system > suspend the dma controller later than the dma client, via using the > *late or the *noirq system PM callbacks. This works for most cases, > but it becomes a problem when the dma client also needs to be system > suspended at the *late or the *noirq phase. Clearly this solution that > doesn't scale. > > Using device links explicitly solves this problem as it allows to > specify this dependency between devices. Frankly, then creating device links has to be added to EVERY subsystem, which involves getting access to the resources provided by the other device. More or less this will apply to all kernel frameworks, which provide kind of ABC_get_XYZ(dev, ...) functions (like clk_get, phy_get, dma_chan_get, ...). Sounds like a topic for another loooong discussion. > 2) > We won't avoid dma clients from getting -EPROBE_DEFER when requesting > their dma channels in their ->probe() routines. This would be > possible, if we can set up the device links at device initialization. The question is which core (DMA engine?, kernel device subsystem?) and how to find all clients before they call dma_chan_get(). Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland