From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753292AbdBCNBk (ORCPT ); Fri, 3 Feb 2017 08:01:40 -0500 Received: from mailout4.w1.samsung.com ([210.118.77.14]:39328 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753255AbdBCNBf (ORCPT ); Fri, 3 Feb 2017 08:01:35 -0500 X-AuditID: cbfec7f1-f793f6d000007796-5b-58947f29a89f Subject: Re: [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback To: linux-samsung-soc@vger.kernel.org, dmaengine@vger.kernel.org, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Lars-Peter Clausen , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , Ulf Hansson , "Rafael J. Wysocki" , Kuninori Morimoto , Mark Brown , Inki Dae , Vinod Koul From: Marek Szyprowski Message-id: <22bc3f1b-a629-482a-71b6-06a3c4df628c@samsung.com> Date: Fri, 03 Feb 2017 14:01:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-version: 1.0 In-reply-to: <49c9c23d-ff0a-268a-5edd-931e04eb98b5@samsung.com> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3YuHqfL49R608qaFJhkKREnC00KOWWQf6VIUEOPl5oXtrSM QpGsnGlec1nUoGmmM9e8lc3MOVJQXOYlCFNKybwlMUpNJrWdBf73+973fd7nfeCjMPEA4U0l p17i5KlSmYQU4q3vVsx7/bPLY/YvKQ8yw4NGAfNC1UgwFV+mSKa+wkowpRPFOGM265yY2e52 xGjKHhOMfnKUYIbaH5KMpdCEGJX5jYDp7/tAMD0N0cxMUSd+1I3VWXJJ9olhRsDq6/JJdmzU QLJNmmxWM28k2N/9JTjbPHILZ4ua6xBr0W+PEsYKj8RzsuRMTr4v9Lwwab5xBaWbfa6MtuTj OeiXlxI5U0AfgPbPLQTPm+D9eCOpREJKTFcjqFmtxfiHBYFq9hP+X/F1vNvRqEGw1jXukEwj WL41h5SIojzoWLgzkmCre9KdCDpeTdoVGL0igK7iBrshSQeBckFJ2lhEh8If67STjXF6F2hN PwQ29qLPwtwjqxM/4w7LZeO4zcCZDgOd9oKtjNEh8G0tj+DZF5q0C3YvoPMpmJpYtR8E9DbQ v8X4BMdB07ToYA+Y7Wl24nkrDJUVOFLeRZCbF8CzCsHAgojnw9DdM+jw2gilrZUYv14Et2+K eWThmTGBnw6HL5oH9o1i2iSA+gLXYuRbtS5L1boAVesCqBFWhzy5DEVKIqcIDlRIUxQZqYmB cWkpevTvl/Wt9fx8iRZ7Q4yIppDEVdQbWRYjJqSZiqwUIwIKk3iKdlwvjxGL4qVZVzl52jl5 hoxTGJEPhUs2iwzq4WgxnSi9xF3kuHRO/r8roJy9c1CEOyM9tcXiOjAW06bTtuX1jfX5Rd0P ng3b+Vy+4YTMu3BJvSwz5ZgNlw3+4WcCrw8cmopTZ5uaJr/vjvTWWfs7VF1hudWv/bT1AREV WddWR+rcgrLQb93JMHQjM6mEihWXnI4o942yVrpgsqqJ4M/z2NNAmPg4/W3mXu0xl40SXJEk DdqDyRXSv1s20OthAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsVy+t/xy7qa9VMiDO7dFLe4cvEQk8XGGetZ LaY+fMJmsXrqX1aLSfcnsFicP7+B3eLV4V2MFksmz2e12PT4GqvF5V1z2Cw+9x5htJhxfh+T xZnTl1gtjq8Nt3jZt5/Fgd9jw+cmNo/Fe14yeWxa1cnmcefaHjaPzUvqPZa8OcTq8e3MRBaP LVfbWTz6tqxi9Pi8SS6AK8rNJiM1MSW1SCE1Lzk/JTMv3VYpNMRN10JJIS8xN9VWKULXNyRI SaEsMacUyDMyQAMOzgHuwUr6dgluGW/W/2QsOC9dcW1rJ0sD41fRLkZODgkBE4lH9w4zQ9hi EhfurWfrYuTiEBJYwijxd9s9FpCEkMBzRolZ+yO7GDk4hAWiJF7NjQCpERHYzyjx4dZ1qIYj TBJNJ5vYQRxmgd9MEsu2TALrZhMwlOh628UGYvMK2En8+vucHcRmEVCVWHPkHROILSoQI/Fy zyoWiBpBiR+TQTZzcHAK2EtsWJMFEmYWMJP48vIwK4QtL7F5zVvmCYwCs5B0zEJSNgtJ2QJG 5lWMIqmlxbnpucVGesWJucWleel6yfm5mxiBsb3t2M8tOxi73gUfYhTgYFTi4T3hPTlCiDWx rLgy9xCjBAezkgivQu2UCCHelMTKqtSi/Pii0pzU4kOMpkA/TGSWEk3OB6advJJ4QxNDc0tD I2MLC3MjIyVx3qkfroQLCaQnlqRmp6YWpBbB9DFxcEo1MPbLvZryOkvM/sXzM+ZSllHWE08f nD8xJyP9+iJVg+UG0jcv9hTUsvEu+cORafbdmMEhjVfk29yeiCsHRI7UdvFdKfmdILH3vMSb LWVTQ/+XKLfcUqk6YJC0LUr8uqevYnRMqpPI6qgbE4UyxJ/Xxbv/K7S7GLNs5/Ui917D/o5v Z0uMFq3+r8RSnJFoqMVcVJwIALpqRWkDAwAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170203130129eucas1p1fe74c54b1a30d2340208ed503709fde5 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: 20170125102824eucas1p1cf027184286131ff628eb7113c3f9e60 X-RootMTR: 20170125102824eucas1p1cf027184286131ff628eb7113c3f9e60 References: <1485340088-25481-1-git-send-email-m.szyprowski@samsung.com> <1485340088-25481-3-git-send-email-m.szyprowski@samsung.com> <26397455-1237-2a66-acf8-215aacc7c9ce@metafoo.de> <49c9c23d-ff0a-268a-5edd-931e04eb98b5@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi All, On 2017-01-26 15:43, Marek Szyprowski wrote: > On 2017-01-25 14:12, Lars-Peter Clausen wrote: >> On 01/25/2017 11:28 AM, Marek Szyprowski wrote: >>> Add pointer to slave device to of_dma_xlate to let DMA engine driver >>> to know which slave device is using given DMA channel. This will be >>> later used to implement non-irq-safe runtime PM for DMA engine driver. >> of_dma_xlate() is used to translate from a OF phandle and a specifier >> to a >> DMA channel. On one hand this does not necessarily mean that the >> channel is >> actually going to be used by the slave that called the xlate function. >> Modifying the driver state when a lookup of the channel is done is a >> layering violation. And this approach is also missing a way to >> disassociate >> a slave from a DMA channel, e.g. when it is no longer used. >> >> On the other hand there are other mechanisms to translate between >> some kind >> of firmware handle to a DMA channel which are completely ignored here. >> >> So this approach does not work. This is something that needs to be >> done at >> the dmaengine level, not a the firmware resource translation level. >> And it >> needs a matching method that is called when the channel is disassociated >> from a device, when the device no longer uses the DMA channel. > > Frankly I agree that of_dma_xlate() should only return the requested > channel > to the dmaengine core and do not do any modification in the the driver > state. > > However the current dma engine design and implementation breaks this > rule. > Please check the drivers - how do they implement of_xlate callback. They > usually call dma_get_any_slave_channel, dma_get_slave_channel or > __dma_request_channel there, which in turn calls dma_chan_get, which then > calls back to device_alloc_chan_resources callback. Some of the > drivers also > do a hardware configuration or other resource allocation in of_xlate. > This is a bit messy design and leave no place in the core to set slave > device > before device_alloc_chan_resources callback, where one would expect to > have > it already set. > > The best place to add new calls to the dmaengine drivers to set slave > device > would be just before device_alloc_chan_resources(), what in turn means > that > the current dmaengine core should do in dma_chan_get(). This would > require to > forward the slave device pointer via even more layers including the > of_xlate > callback too. IMHO this is not worth the effort. > > DMA engine core and API definitely needs some cleanup. During such > cleanup > the slave device pointer might be moved out of xlate into separate > callback > when the core gets ready for such operation. > > I ignored other paths for other firmware handle to a DMA channel > translation > mechanism because for the current pl330 driver they are simply not > used. I > assume that if one needs to implement similar things for drivers > relying on > them, he will update the respective DMA engine core parts. > > Slave device assignments can be cleared in > device_chan_release_resources if > this is needed and that what existing DMA engine drivers do with the > resources > allocated in the of_xlate callback... Vinod: could you comment this patchset? Is there a chance to get it merged or at least give it a try in -next? If not, could you provide some hints what should I do? Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland